Ba tuần vừa qua là khoảng thời gian tiết lộ nhiều điều nhất mà tôi từng có trong lĩnh vực phát triển phần mềm hỗ trợ bởi AI.
Claude Fable đã quay trở lại, và trong cùng khoảng thời gian đó, OpenAI đã phát hành GPT-5.6 với Sol, Terra và Luna. Tín hiệu thị trường rất rõ ràng: các phòng thí nghiệm tiên phong không còn chỉ tung ra những đột phá riêng lẻ nữa, mà đang thu hẹp khoảng cách giữa năng lực, các mức giá và nhịp độ triển khai. Anthropic hiện bán Fable 5 như một mô hình tầm xa cao cấp nhất của họ với mức giá gấp đôi Opus 5, trong khi OpenAI định hình GPT-5.6 như một gia đình mô hình mở rộng từ năng lực hàng đầu xuống các công việc nhạy cảm về chi phí hơn. Trong khi đó, xAI đang định giá Grok 4.5 một cách mạnh mẽ đến mức nó phải được xem xét nghiêm túc trong bất kỳ cuộc thảo luận nào về chi phí-hiệu suất.
Nhưng điều quan trọng nhất tôi học được trong những tuần đó lại hầu như không liên quan đến các trang ra mắt hay slide điểm chuẩn.
Bước đột phá thực sự trong môi trường của tôi là sự chuẩn bị.
Chúng tôi đã có sẵn các câu chuyện. Chúng tôi đã chia nhỏ công việc thành những phần có thể thực sự được thực thi bởi các hệ thống mã hóa tác nhân (agentic coding). Khi hàng đợi đó tồn tại, thông lượng trở nên phi lý. Trong suốt quá trình sử dụng Codex, Claude, Cursor, Grok và các công cụ khác trong quy trình làm việc, hơn 2 triệu dòng mã đã được viết trong khoảng mười ngày. Con số đó nghe có vẻ cường điệu cho đến khi bạn thấy điều gì đã làm nó khả thi: không phải phép màu, không phải sự tự chủ trừu tượng, mà là một dòng chảy ổn định của các công việc có giới hạn với đủ cấu trúc để các mô hình tiếp tục tiến lên.
Đó là điều đầu tiên mà quá nhiều người vẫn còn bỏ lỡ. Sự bùng nổ đầu ra không xảy ra vì các mô hình đột nhiên trở thành những kỹ sư tự định hướng. Nó xảy ra bởi vì con người đã chuẩn bị chiến trường.
Điều thứ hai tôi học được là các lỗi xuất hiện nhanh hơn ở quy mô lớn so với những gì tiếp thị từng thừa nhận.
Codex là một ví dụ điển hình. Tài liệu của OpenAI về các công việc chạy dài cho thấy rõ rằng các luồng (thread) bền vững đi kèm với một sự đánh đổi: tính liên tục rất hữu ích, nhưng các luồng chạy dài cũng có thể trở nên đắt đỏ hơn và khó quản lý hơn so với việc bắt đầu lại từ đầu. Tính năng Goals được thiết kế chính xác để giữ một luồng gắn liền với một mục tiêu có giới hạn, thay vì biến mọi nhiệm vụ khó khăn thành một prompt ngày càng phình to. Trong thực tế, điều đó phù hợp với những gì tôi đã thấy. Nếu một quy trình chạy quá lâu, cách tốt hơn thường là dừng nó lại, yêu cầu bàn giao rõ ràng, khởi động lại phiên và tiếp tục với một mục tiêu mới. Đó không chỉ là một sự tiện lợi. Nó thường là vệ sinh vận hành.
Cũng có một vấn đề Codex cụ thể hơn hiện đã có dấu vết công khai rõ ràng: các vấn đề bùng nổ về tác nhân con (subagent) và trạng thái cục bộ (local state).
Vấn đề mở #34061 ghi lại một trường hợp trong đó một luồng cha được tiếp tục đã tạo ra hàng nghìn tệp nhật ký JSONL con và hàng trăm gigabyte lịch sử phiên được lưu trữ. Một vấn đề khác cảnh báo rõ ràng rằng fork_context=true có thể khiến lịch sử cha lớn được snapshot vào các tác nhân con, làm tăng cả rủi ro về tính đúng đắn và tiêu thụ token. Một báo cáo công khai khác cho thấy rằng khởi động nguội (cold start) của Codex có thể xuống cấp thành thời gian chờ 1-5 phút khi ~/.codex tích lũy các tệp nhật ký SQLite và trạng thái phiên lớn. Tổng hợp lại, những báo cáo đó mô tả một chế độ thất bại mà nhiều người dùng cao cấp sẽ ngay lập tức nhận ra: một khi lớp siêu dữ liệu cục bộ đủ lớn, sự bền vững của phiên trở thành một phần quan trọng của trải nghiệm sản phẩm.
Điều này quan trọng bởi vì mã hóa đa tác nhân (multi-agent coding) luôn trông đẹp hơn trong các bản demo so với trên một máy phát triển đang bị căng thẳng.
Lời hứa rất rõ ràng. Tài liệu đa tác nhân của OpenAI mô tả lý do tại sao các tác nhân con song song có thể tăng tốc các luồng công việc độc lập, và lời hứa đó là có thật. Nhưng các tài liệu tương tự cũng cảnh báo rằng các tác nhân con làm tăng mức sử dụng token và có thể không phù hợp với các tác vụ liên quan đến việc ghi thường xuyên vào trạng thái có thể thay đổi được chia sẻ. Hướng dẫn về tác nhân song song trên ChatGPT Learn thậm chí còn rõ ràng hơn: bắt đầu với các công việc nặng về đọc như khám phá, kiểm thử, phân loại và tóm tắt; thận trọng hơn với các luồng công việc nặng về ghi vì xung đột và chi phí phối hợp tăng nhanh. Cảnh báo đó không phải là lý thuyết. Bất kỳ ai đã từng chứng kiến một đội quân tác nhân đồng loạt lao vào một bộ kiểm thử đầy đủ cùng một lúc đều hiểu chính xác điều đó có nghĩa là gì.
Trong thiết lập của riêng tôi, đây hiện là một trong những vấn đề vận hành xác định của toàn bộ thể loại này.
Vấn đề không phải là liệu các mô hình có đủ thông minh để song song hóa hay không. Rõ ràng là chúng có. Vấn đề là chúng vẫn cần các ranh giới điều phối (orchestration boundaries) tốt hơn nhiều, bởi vì "đủ thông minh để ủy quyền" không giống với "đủ thông minh để bảo toàn sức khỏe máy, ưu tiên cục bộ và kỷ luật chi phí khi có sự tranh chấp."
Sự không khớp tương tự đó cũng thể hiện trong định giá.
Cursor minh họa vấn đề một cách rõ ràng. Cấu trúc giá hiện tại của nó rất minh bạch: có hai nhóm sử dụng hàng tháng, một cho các mô hình riêng của Cursor và một cho "Mô hình khác" của bên thứ ba. Nó cũng cho thấy rằng Auto không phải là một thứ duy nhất. Auto Cost sử dụng định giá token phẳng, nhưng Balance và Intelligence tính phí theo tỷ lệ của mô hình được định tuyến, và bộ định tuyến có thể chọn giữa các mô hình như Composer, GPT-5.6, Claude hoặc Grok. Đối với những người thỉnh thoảng làm công việc tương tác, sự linh hoạt đó rất hấp dẫn. Đối với các khối lượng công việc công nghiệp, bùng nổ, nó có thể trở thành một cái bẫy. Ngân sách cao cấp của một tháng có thể biến mất trong vài ngày làm việc rất hiệu quả.
Tôi đã kiểm tra chính xác chế độ thất bại đó trong một kịch bản nặng về đánh giá.
Một dự án đã tiếp nhận khoảng 500 nghìn dòng mã mới. Hệ thống đánh giá của chúng tôi đã gắn cờ khoảng 1.500 vấn đề trong phần delta đó, bao gồm cả các vấn đề trùng lặp và dương tính giả. Cursor CLI được giao nhiệm vụ xử lý chúng. Khối lượng token thô rất lớn. Đầu ra rất hữu ích. Nhưng kinh tế học lại không phù hợp với trường hợp sử dụng của tôi. Khi công việc đánh giá và sửa chữa chuyên sâu có thể tiêu thụ hết hạn mức hàng tháng trong một tuần, công cụ có thể vẫn tốt, nhưng gói đăng ký không còn hợp lý nữa.
Sự căng thẳng đó hiện đang ở khắp mọi nơi.
Claude vẫn là hệ thống tôi thích làm việc nhất. Nhưng nó cũng là hệ thống khiến tôi ý thức nhất về chi phí. Codex, đặc biệt là trong hệ sinh thái GPT-5.6 rộng lớn hơn, thường có thể mang lại thông lượng lớn hơn nhiều so với những gì các nhà phê bình thừa nhận. Grok 4.5 không phải là chuyện đùa; định giá công khai và định vị của nó khiến nó trở thành một đối thủ hợp pháp. Cấu trúc giá của chính Anthropic làm cho sự đánh đổi giữa Fable và Opus trở nên đủ rõ ràng để gần như tự viết bài xã luận cho bạn: năng lực tiên phong là có thật, nhưng hóa đơn cũng vậy.
Và rồi có vấn đề khó khăn nhất, vấn đề mà không có sự kiện ra mắt nào thực sự giải quyết được.
Trong hầu hết mọi mô hình mã hóa tiên phong mà tôi sử dụng, vẫn có một khoảng cách khó chịu giữa thiếu năng lực (underpowered) và thiết kế quá mức (overengineered).
Sự lựa chọn quá thường xuyên là giữa một mô hình không suy nghĩ đủ kỹ và một mô hình suy nghĩ quá kỹ cho nhiệm vụ trước mắt. Hướng dẫn của chính Anthropic cho Fable 5 thực sự thừa nhận điều này. Nó nói rằng nỗ lực cao hơn có thể dẫn đến lập kế hoạch quá mức, rằng công việc thông thường có thể được hưởng lợi từ nỗ lực thấp hơn và các hướng dẫn ngắn gọn thường hoạt động tốt hơn các cấu trúc phức tạp. OpenAI nói điều gì đó tương tự trong hướng dẫn GPT-5.6 của mình: khi di chuyển từ các mô hình cũ hơn, hãy bắt đầu với cùng mức độ suy luận và sau đó kiểm tra một mức thấp hơn, bởi vì các mô hình mới hơn thường có thể duy trì hoặc cải thiện chất lượng với ít token hơn. Đó là một cách diễn đạt kỹ thuật cho điều mà nhiều người trong chúng ta đang khám phá theo kinh nghiệm: nút điều chỉnh nỗ lực (effort dial) vẫn quá dễ để vượt quá.
Có lẽ một phần vẫn là do chúng ta.
Có lẽ các tệp hướng dẫn quá dài. Có lẽ một số cấu trúc hỗ trợ hiện đang chống lại các mô hình thay vì giúp đỡ chúng. Lý thuyết đó ít nhất là phù hợp với hướng dẫn về kỹ thuật ngữ cảnh (context engineering) của chính Anthropic, trong đó nói rằng ngữ cảnh nên có tính thông tin nhưng chặt chẽ. Có một khả năng thực sự rằng một số sự phức tạp quá mức mà chúng ta đổ lỗi cho các mô hình đang được khuếch đại bởi cơ sở hạ tầng prompt phát triển quá mức.
Nhưng ngay cả sau khi tính đến điều đó, kết luận rộng hơn vẫn không thay đổi.
Các mô hình đang mắc ít lỗi rõ ràng hơn trước. Nhưng những lỗi chúng vẫn mắc phải thường nguy hiểm hơn chính xác bởi vì chúng khó phát hiện hơn. Chúng ẩn náu bên trong mã mà nếu không thì trông có vẻ bóng bẩy, có chủ đích và chuyên nghiệp. Việc triển khai càng trông tốt từ xa, tôi càng học được cách trở nên nghi ngờ hơn.
Đó là lý do tại sao tôi vẫn hoài nghi về làn sóng chủ nghĩa thắng lợi của AI-mã hóa hiện tại.
Tôi hiểu sự thổi phồng đến từ đâu. Nếu bạn chưa sống trong các hệ thống này hàng ngày, chỉ riêng thông lượng đã có thể cảm thấy kỳ diệu. Và một số điều đó thực sự là như vậy. Nhưng việc sử dụng thực tế hàng ngày cũng phơi bày mặt trái: sự không chắc chắn về hóa đơn, thất bại trong điều phối, sự mong manh của phiên dài, xu hướng đơn giản hóa nông cạn hoặc thiết kế quá mức cầu kỳ, và nhu cầu dai dẳng về sự đóng gói, đánh giá và phán xét của con người.
Chúng ta vẫn còn rất xa một thế giới mã hóa LLM lý tưởng.
Sự thổi phồng không hoàn toàn sai. Nhưng nó vẫn kém trung thực hơn nhiều so với thực tế vận hành.
