- Tác động năng suất của các coding agent không đồng đều mà phân hóa theo dạng chữ K; chỉ số cốt lõi không phải là số dòng code mỗi giờ mà là liệu tốc độ cải thiện sản phẩm trên mỗi kỹ sư có thực sự tăng lên hay không
- Dax, Karri Saarinen, David Cramer không phải là người bài xích AI, nhưng họ vẫn chưa có được niềm tin rằng coding agent đang làm tăng rõ rệt tốc độ cải thiện sản phẩm; Cramer cho rằng LLM làm tăng độ phức tạp và phình to khiến tốc độ dài hạn chậm lại
- Nếu Claude Code đã mang lại lợi thế độc quyền nội bộ cho Anthropic trong 7 tháng, thì khoảng cách với đối thủ lẽ ra phải nới rộng theo lãi kép; nhưng Codex, Cursor, Cognition và Factory vẫn đang cạnh tranh, cho thấy nút thắt có thể không nằm ở năng lực tạo code
- Văn hóa kỹ thuật tốt xem số dòng code không phải là tài sản mà là chi phí; khi tính năng và tích hợp tăng lên, bề mặt lỗi, phụ thuộc và các tính năng xung quanh cũng tăng theo, khiến độ phức tạp tăng không tuyến tính mà theo lãi kép
- Ở tiền tuyến của chất lượng sản phẩm, gu, khả năng nén, xóa bỏ và từ chối quan trọng hơn việc viết code thật nhanh; Claude Code hữu ích để đi từ con số 0 đến mức Camry, nhưng không khiến những nghệ nhân Ferrari làm ra chiếc Ferrari nhanh hơn
Đường cong năng suất hình chữ K
- Mức tăng năng suất của coding agent không đồng đều mà phân hóa theo hình chữ K
- Kỹ sư senior cho thấy mức tăng đầu ra có thể đo được kể từ điểm bẻ cong LLM năm 2023
- Đầu ra của kỹ sư junior gần như đi ngang hoặc giảm xuống
- Chỉ số quan trọng không phải là số dòng code mỗi giờ, mà là liệu tốc độ cải thiện sản phẩm trên mỗi kỹ sư có thực sự tăng hay không
- Coding kiểu agent giúp rút ngắn thời gian tạo Pull Request trong một số loại công việc nhất định
- Những tuyên bố như “xử lý xong 6 năm backlog trong một quý”, “dùng Cursor làm backend trong 3 ngày”, “Claude Code được viết hoàn toàn bằng Claude” liên tục xuất hiện
- Tuy vậy, việc tốc độ tạo code có đồng nghĩa với cải thiện chất lượng sản phẩm hay không vẫn là một câu hỏi khác
Tín hiệu cảnh báo từ các kỹ sư giỏi trong việc tạo ra sản phẩm tốt
- Dax, Karri Saarinen và David Cramer đều không phải người phản đối AI, nhưng vẫn chưa tin chắc rằng coding agent đang làm tăng rõ rệt tốc độ cải thiện sản phẩm
- Dax đang xây dựng opencode.ai
- Karri Saarinen là CEO của Linear
- David Cramer là người xây dựng Sentry từ đầu và phát triển nó lên quy mô doanh thu 10 triệu USD mỗi tháng
- David Cramer cho rằng hiện tại LLM chưa tạo ra mức tăng năng suất ròng
- Chúng làm giảm rào cản khởi đầu, nhưng tạo ra phần mềm phức tạp khó bảo trì
- Chúng có vẻ làm chậm tốc độ dài hạn
- Ông chỉ ra các vấn đề gồm “hiệu năng phát triển lặp trong môi trường phức tạp yếu”, “thiếu khả năng đơn giản hóa thực sự và tạo giao diện mang tính thành ngữ”, và “kỹ thuật sinh test cẩu thả” của LLM
- Kết luận cuối cùng là phần lớn chỉ là phình to (bloat)
- Dax nói rằng ông vẫn chưa tìm ra rõ ràng cách tận dụng coding agent tốt nhất
- Trong khi đó bên ngoài có rất nhiều tuyên bố như “mọi PR đều do AI tạo”, “tốc độ chưa từng có”, “xử lý xong 6 năm backlog”
- Nhưng tất cả họ đều đang gặp khó khăn trong việc thực sự nâng tốc độ cải thiện sản phẩm
Lợi thế độc quyền của Claude Code không thể hiện thành khoảng cách
- Nếu Claude Code thực sự được viết hoàn toàn bằng Claude, thì tốc độ cải thiện sản phẩm lẽ ra phải tăng tốc
- Chỉ cần dùng Claude Code giúp tăng tốc độ cải thiện sản phẩm lên 1,5 lần, thì đội dùng nó ngay từ đầu theo thời gian phải nới rộng khoảng cách với đối thủ
- Năng suất kỹ thuật là một hàm lãi kép, nên khoảng cách theo từng quý phải ngày càng lớn
- Tình hình thực tế trên thị trường không cho thấy khoảng cách lãi kép đó
- Codex ra mắt muộn hơn Claude Code vài tháng nhưng đã có thể cạnh tranh về tính năng
- Đà giao dịch của Cursor vẫn mạnh
- Cognition và Factory vẫn tiếp tục giành được các hợp đồng enterprise quan trọng
- Mọi người vẫn còn tranh luận công cụ nào tốt hơn
- Phản chứng cốt lõi là: nếu Anthropic đã có độc quyền Claude Code trong 7 tháng, thì nếu thật sự tồn tại lợi thế tốc độ sản phẩm, khoảng cách với đối thủ lẽ ra phải lớn đến mức không thể bắt kịp
- Codex lẽ ra đã trở nên vô nghĩa, nhưng thực tế không phải vậy
- Nếu không thấy lợi thế lãi kép, nhiều khả năng nút thắt của chất lượng sản phẩm chưa bao giờ là code
- Các phản biện khả dĩ cũng chỉ củng cố cùng một kết luận
- Ngay cả khi có lợi ích, nợ độ phức tạp có thể đã nuốt trọn nó
- Đội kỹ thuật của Anthropic có thể quá lớn khiến lợi ích cận biên trên mỗi kỹ sư bị pha loãng
- Nhưng kể cả vậy, nút thắt cũng không phải là năng lực tạo code mà là một yếu tố khác khó hơn
Số dòng code không phải tài sản mà là chi phí
- Văn hóa kỹ thuật tốt xem số dòng code không phải là sản lượng mà là chi tiêu
- Với tính năng quan trọng thì viết code, còn tính năng không quan trọng thì không viết
- Codebase không phải tài sản trên bảng cân đối kế toán mà gần với nợ phải trả hơn
- Công ty phần mềm con tinychat của comma.ai từng đặt cảnh báo khi codebase vượt quá một kích thước nhất định và ăn mừng khi code bị xóa
- Mỗi dòng code đều là một bề mặt lỗi
- Mỗi hàm đều trở thành phụ thuộc của hàm tiếp theo
- Mỗi tính năng đều sinh ra các tính năng xung quanh
- Bề mặt sản phẩm mở rộng như fractal
- Thêm tích hợp Slack thì sẽ cần tích hợp Teams và một đường dự phòng qua email
- Thêm thông báo thì phải làm lại cho mobile, SMS và các chính sách MDM của enterprise
- Thêm hỗ trợ MFA thì phải tương thích với Duo, Okta và SAML
- Độ phức tạp tăng không tuyến tính mà theo lãi kép
- Linear có 178 người, 6 năm hoạt động, ARR 100 triệu USD
- Jira lớn hơn Linear 56 lần về tổng nỗ lực kỹ thuật tích lũy, nhưng điểm chất lượng cảm nhận từ người dùng lại thấp hơn 6 điểm
- Điểm mấu chốt là chất lượng không đồng nghĩa với khối lượng codebase
- Ở quy mô như Facebook, khả năng sản xuất nhanh code giao diện không phải nút thắt
- Một kỹ sư giỏi có thể làm mockup News Feed của Facebook trong một ngày
- Ràng buộc thực tế là giảm số dòng code cần thiết để chuyển tải trải nghiệm đó tới hàng tỷ người với uptime được duy trì dưới mọi mức tải và độ trễ
- Hàm phần thưởng không phải là sản xuất mà là nén
- Với loại công việc này, coding agent không thể đánh giá các đánh đổi dài hạn và không có một lý thuyết về hệ thống
Nút thắt thật sự là khả năng đẩy tiền tuyến của ý tưởng sản phẩm tốt
- Việc cải thiện chất lượng sản phẩm ở tiền tuyến không bị giới hạn bởi tốc độ viết code, mà bởi tốc độ nghĩ ra những ý tưởng đủ tốt để đẩy được tiền tuyến đó
- Khác biệt giữa Jira và Linear không nằm ở việc vẽ hộp tốt hơn
- Linear có một tầm nhìn sáng tạo cụ thể về cảm giác mà phần mềm quản lý dự án nên mang lại, và thực thi nó một cách tiết chế trong nhiều năm
- Chất lượng kiểu này không đến từ thông lượng token mà đến từ gu và quyết định làm ít đi
- Tuyên bố “xử lý xong 6 năm backlog” không ấn tượng như vẻ bề ngoài
- Backlog đầy các tính năng CRUD và công cụ nội bộ rất phù hợp với loại công việc mà coding agent tăng tốc
- Đồng thời, đó lại không phải loại công việc đẩy tiền tuyến của sản phẩm
- Phát hành nhanh hơn không tự động làm sản phẩm tốt hơn; sản phẩm chỉ tốt hơn khi thứ được phát hành khiến người dùng quan tâm hơn
- AI coding agent giúp các sản phẩm đi từ 0 đến 1 chạm tới tiền tuyến chất lượng nhanh hơn
- Chúng rút ngắn thời gian tới phiên bản đầu tiên có thể chạy được
- Mức tăng tốc ở giai đoạn đầu là có thật
- Nhưng cũng có cái giá phải trả
- Codebase phình nhanh hơn chất lượng
- Technical debt tích lũy theo lãi kép
- Tốc độ có được hôm nay là thứ được mua bằng chi phí phải trả sau này
Camry cho tất cả mọi người, Ferrari cho không ai cả
- Với các đội đang ở tiền tuyến, nút thắt không phải là coding agent mà là những con người có gu
- Khả năng “trở nên xuất sắc nhờ biết lược bỏ” như Linear và Sentry nằm trong những cá nhân nhất định
- Nan Yu của Linear và Kelly Johnson của Skunk Works được nêu làm ví dụ
- Đội ngũ tuyển chọn của Kelly Johnson đã tạo ra SR-71, và đến 60 năm sau SR-71 vẫn được nhắc tới là máy bay có người lái dùng động cơ hút khí nhanh nhất
- Blackbird nhanh không phải vì họ tạo ra nhiều bản thiết kế hơn, mà vì Johnson có một lý thuyết về việc nên bỏ lại điều gì
- Gu để xóa bớt, nén và từ chối không nằm trong bất kỳ roadmap frontier model nào, và khi mặt bằng chung tăng lên thì nó lại càng có giá trị hơn
- Nếu đã ở tiền tuyến, vẫn chưa rõ việc tăng gấp đôi chi phí R&D bằng cách tiêu token có tạo ra giá trị kinh tế hay không
- Các kỹ sư của Ramp nói rằng trong năm qua họ về thực chất đã tăng gấp đôi lương thông qua chi tiêu token
- Nhưng rất khó xác nhận liệu sản phẩm của Ramp có thực sự tốt hơn hay không
- Nếu bạn đã đứng số 1, tỷ lệ thắng gần như cố định, và việc “đứng số 1 với cách biệt lớn hơn” là thứ khó đo lường
- Muốn thay đổi phán đoán thì cần dữ liệu về tỷ lệ thắng hoặc lợi nhuận/thua lỗ của Ramp
- Với tư cách khách hàng của Ramp, tác giả nói rằng không cảm nhận được khác biệt giữa hiện tại và năm ngoái
- Claude Code có thể giúp bất kỳ ai tạo ra một sản phẩm cạnh tranh cấp Camry, nhưng không giúp những nghệ nhân Ferrari tạo ra chiếc Ferrari nhanh hơn
- Nó cực kỳ hữu ích để đi từ con số 0 lên mức Camry
- Chi phí sản xuất phần mềm không ở đẳng cấp hàng đầu có khả năng giảm mạnh
- Đổi lại, rất nhiều hỗn loạn và nợ sẽ tích tụ trên xà nhà của nhà máy, và cuối cùng sẽ có ai đó phải dọn dẹp
1 bình luận
Ý kiến trên Lobste.rs
Độ phức tạp tăng theo cấp số nhân, thậm chí có thể còn nhanh hơn. Vì vậy, điều mà những người lo sợ điểm kỳ dị AGI cũng thường bỏ qua là dù con người, mô hình hay tác tử có thông minh đến đâu, khi ý tưởng, hệ thống, dự án, codebase hay tập tính năng phình to lên thì cuối cùng vẫn sẽ đâm vào bức tường độ phức tạp tăng vọt đó
Mọi dự án phần mềm lúc đầu đều tương đối suôn sẻ, nhưng đến một thời điểm nào đó, mức tăng theo cấp số nhân của độ phức tạp sẽ lấn át tất cả. Kiến trúc, thiết kế và chất lượng tốt chỉ giúp trì hoãn thời điểm đó; nếu người giỏi thiết kế tốt và giữ chất lượng ổn định thì có thể chịu được quy mô, tính năng, hiệu năng và yếu tố “wow” lớn hơn khoảng 10 lần, nhưng cuối cùng vẫn chạm tường
Sự hỗ trợ của LLM giúp tạo ra tính năng và code ở mức chất lượng nhất định, thường là mức trung bình, nhanh hơn rất nhiều. Nghĩa là cũng chạm đến bức tường đó nhanh hơn rất nhiều. Nó tốt cho tăng trưởng, thử nghiệm và các công việc độ phức tạp thấp vốn tương đối dễ nhưng tốn thời gian, chứ không khiến bạn làm ra được những thứ chưa từng có hay các dự án lớn và phức tạp. Điều cần ở đó là những cải tiến giúp kiềm chế độ phức tạp, và LLM hiện tại chưa thực sự cung cấp được điều đó
http://bastiat.org/en/twisatwins.html
Chi phí của việc dùng code agent không hiện ra trực tiếp, mà chủ yếu đến từ sự mất mát hiểu biết tập thể về cách hệ thống vận hành
Một hệ thống vững chắc phải chịu được va đập và có khả năng tự thích nghi, nên từng phần phải có thể hỏng độc lập và thiệt hại phải được cô lập cục bộ. Nếu tổ chức hệ thống thành các hệ con lồng nhau, ta sẽ có những đơn vị giống như tế bào giao tiếp với nhau để xử lý công việc. Các đơn vị này hoạt động như những mô-đun ổn định mà không cần biết quá trình nội bộ của các “tế bào” khác
Mỗi tầng không bị níu chân bởi những gì đang diễn ra ở nơi khác, nên có thể tự tổ chức trong phạm vi của mình và duy trì khả năng phục hồi. Về bản chất, đây là cách đóng gói độ phức tạp ngẫu nhiên phía sau interface và tạo ra abstraction mà interface đó mang ý nghĩa. Nên xem các tầng như mô liên kết nối các thành phần của một hệ thống lớn
Erlang OTP là một ví dụ tốt trong phần mềm cho cách tiếp cận này, khi xây dựng hệ thống lớn từ các process cách ly giao tiếp với nhau bằng message. Việc một process riêng lẻ chết hoặc lỗi sẽ không làm sập cả hệ thống
Nếu bạn yêu cầu ai đó triển khai một thứ gì đó, họ có thể trả lời như “quá phức tạp”, “một năm nữa nó sẽ nổ tung”, “không tương thích với thứ mà team Y đang làm”, hoặc “không có đủ người để triển khai”. Câu cuối có thể là sự thật, hoặc cũng có thể là cách gián tiếp để nói “không được”
Khả năng LLM trả lời như vậy là rất thấp, nhất là vì chúng được tinh chỉnh để lạc quan và lịch sự. Hơn nữa, vì xu hướng đó cũng cần thiết để tăng mức độ tương tác, nên có vẻ cũng khó mà được tinh chỉnh theo hướng khác
Vấn đề này trông giống với chuyện LLM giúp người dùng tự sát. Dù khá rõ ràng, LLM vẫn đã làm điều đó nhiều lần. Việc một dự án chết vì độ phức tạp không được kiểm soát thì còn kém rõ ràng hơn nhiều, nên khó kỳ vọng LLM sẽ sớm làm tốt hơn trong việc này
Kiểu suy luận rằng “nếu dùng Claude Code tạo ra lợi thế tốc độ phát triển sản phẩm thực sự, và Anthropic đã độc quyền nó trong 7 tháng, thì khoảng cách giữa Claude Code và mọi đối thủ phải là không thể san lấp. Codex phải trở nên vô nghĩa. Nhưng mọi người vẫn đang tranh luận rất sôi nổi xem bên nào tốt hơn” nghe không thật sự vững
Claude Code là phần mềm tốt, nhưng không phải thứ phép màu AGI kỳ lạ đến mức khiến cạnh tranh trở nên bất khả thi
Claude Code không phải ngay từ đầu đã có một roadmap hoàn chỉnh, và rào cản chính cũng không phải là tốc độ viết code. Rào cản cốt lõi là ý tưởng. Mọi người đều đang vừa làm vừa tìm ra nó
Tôi chỉ lướt qua bài viết nói chung nên khó nhận xét sâu, nhưng bỏ qua cả vấn đề viết hoa đầu câu thì phần lớn trông giống văn xuôi do LLM viết, nên tôi cũng không muốn đọc lắm
Cho đến nay, sai lầm của agent có xu hướng tích lũy theo kiểu nhân lên
Nếu nó tạo ra một API về mặt kỹ thuật là chạy được nhưng khi dùng lại cần thêm một chút code phụ, thì kết quả là code ngày càng nhiều lên, số chỗ có thể phát sinh trùng lặp, phân nhánh và bug cũng tăng theo. Rồi theo kiểu fractal, lại có thêm nhiều đoạn code không mấy tốt được viết ra
Có lần một agent thiết kế một struct mà trường
idlà tùy chọn. Trường đó chỉ cần thiết vì chính một constructor mà nó đã viết. Rồi nó không biết mệt mà viết hai bộ code cho trường hợp cóidvà không cóid, thậm chí còn tạo cả các đường xử lý thay thế gượng ép cho trường hợp không có. Dĩ nhiên những đường thay thế đó rất phức tạp và mong manh. Gần như mọi chỗ dùng struct đó, cùng cả những phần phụ thuộc vào nó, đều bị lây nhiễm, trong khi constructor không cóidthì chẳng bao giờ được dùng. Một nửa codebase lẽ ra có thể xóa đi dễ dàngTôi thật sự không biết liệu chỉ cần nhồi đủ chỉ dẫn kiểu “nếu đang làm điều ngớ ngẩn thì hãy dừng đào sâu lại” là có thể sửa được và việc coding chỉ còn cách “được giải quyết” vài cú hack nữa thôi, hay đây là vấn đề dài hạn của một con vẹt xác suất, nơi chi phí tăng theo cấp số nhân vẫn sẽ liên tục cần thiết để đổi lấy cải thiện tuyến tính. Chừng nào sai lầm còn cộng dồn theo lãi kép, thì tăng trưởng kép cuối cùng sẽ cản chân bạn
Đôi khi điều đó còn bao gồm cả business process. Một lập trình viên hiểu rõ domain có thể thay vì dành vài tháng triển khai giải pháp kỹ thuật sẽ hỏi “sao không đổi luôn quy trình thay vì cứ tiếp tục đào sâu?”, và đôi khi câu trả lời là “tất nhiên rồi, cái đó dễ mà”
Tôi nghĩ rồi LLM cũng sẽ giỏi hơn ở điểm này. Ngay bây giờ, nếu hỏi trực tiếp kiểu “cách tiếp cận này có vẻ không ổn, có thể nghĩ đến phương án khác không?” thì khá thường xuyên nó cũng tìm ra được. Chỉ là hiện tại mức độ thành công và thất bại còn rất thất thường, và một khi nó đã làm điều ngớ ngẩn đó rồi thì khả năng tự nhận ra khi đang làm một việc không liên quan là thấp
Ở đây cũng có đánh đổi. Mọi người đã than phiền rằng model suy nghĩ quá nhiều và đốt token. Nếu có kinh nghiệm và trực giác về việc code giải một vấn đề cụ thể “nên trông như thế nào”, lập trình viên sẽ tự nhiên biết lúc nào cần dừng lại nhìn lại. Có thể agent rồi cũng sẽ có được trực giác đó nhờ huấn luyện tốt hơn
Tôi muốn thấy bản cập nhật với dữ liệu sau bước ngoặt tháng 11 năm 2025