hoặc: dây cương là chưa đủ
Cập nhật – phiên bản talkshow của bài viết này đã có trên youtube: https://www.youtube.com/watch?v=Ib5GBkD555M
tôi đoán là chúng ta đang làm vòng lặp đây
Tất cả chúng ta đều đang chạy đua để đưa AI coding vào sản xuất. Đã có rất nhiều điều được nói về kỹ thuật vòng lặp, và quan điểm phổ biến hiện nay là chúng ta nên viết nhiều vòng lặp hơn.
StrongDM đã viết về nhà máy phần mềm không đèn (lights-off software factory) của họ nơi không có con người đọc code và không có con người viết code.
Câu chuyện thường diễn ra như thế này:
- Bạn là nút thắt cổ chai.
- Các mô hình đã đủ tốt.
- Code là miễn phí.
- Cứ liên tục ship hàng thôi.
Ryan Lopopolo của OpenAI đã viết về điều này vào tháng Hai và đã có một bài nói chuyện vào tháng Tư về nhà máy phần mềm của OpenAI, Symphony.
Những người này đều thực sự rất thông minh và tôi vô cùng kính trọng họ. Nhưng cách nhìn hoài nghi nhất ở đây có thể coi đây chỉ là một cái cớ khác để bơm thêm tiền VC vào cái máy bơm rác (slop cannon).
nó thì... uh... nó đang chạy
Người bạn Mario của chúng tôi đã đứng lên tại AI Engineer Europe và cầu xin chúng tôi hãy chậm lại -- bởi vì những công ty không có lý do gì để bị gián đoạn dịch vụ do sự cố từ coding-agent, thì, ờ... đang bị gián đoạn dịch vụ do sự cố từ coding-agent.
Như Matt Pocock đã nói, các codebase đang đổ vỡ nhanh hơn bao giờ hết.
Tôi chưa thể tìm thấy bất kỳ dữ liệu/phát hiện chắc chắn nào từ StrongDM về việc nhà máy không đèn đó đã diễn ra như thế nào. Bản tin thời tiết (weather-report) có một vài cập nhật thưa thớt từ tháng Hai đến tháng Sáu năm nay. chỉnh sửa - có một số cuộc trò chuyện với nhóm trên hacker news vào ngày 23 tháng Bảy - nghe có vẻ như chúng ta có thể sớm nhận được một bản cập nhật chính thức hơn!
Những người ở Faros AI đã đưa ra một báo cáo: kể từ khi chúng ta2 tất cả đều sử dụng các công cụ AI coding này vào tháng Giêng và tháng Hai, chất lượng đánh giá pull-request đã giảm đáng kể.
- Nhiều bình luận hơn, bình luận dài hơn, và vô số PR được merge mà không có bất kỳ đánh giá nào.
- Sự cố gia tăng đáng kể.
- Lỗi trên mỗi nhà phát triển gia tăng đáng kể.
Báo cáo này thiên về một tín hiệu tương quan hơn là một bằng chứng xác thực (vâng tôi cố tình chọn từ đó, đừng làm tôi bắt đầu về văn phong của claude), và toàn bộ mục đích của bài viết này là để cảnh giác với dữ liệu rác, nhưng nó cảm thấy có giá trị định hướng dựa trên những gì tôi đã thấy.
"Bạn đang cầm nó sai cách rồi" (không phải đâu)
Rất nhiều người sẽ nói với bạn rằng đây là vấn đề kỹ năng -- rằng nếu bạn không nhận được kết quả tốt, đó là lỗi của bạn.
Nhưng dù bạn đang chọn cách... ờ... cầm nó như thế nào, tôi đảm bảo bạn sẽ bị nói rằng nếu việc tối đa hóa token (token-maxxing) không hiệu quả với bạn, thì đó là vấn đề kỹ năng. Bạn chỉ cần tiêu nhiều token hơn. Hãy từ bỏ việc đọc code. Và nếu bạn chỉ mới bắt đầu, tôi hứa đó là một phần của quá trình phát triển. Tôi cũng đã nghĩ như vậy vào mùa hè năm ngoái.
Thật không may cho cái tôi của tôi, một số điều ngớ ngẩn tôi đã quyết định nói về "làm thế nào để cầm nó tốt hơn" đã được ghi lại và hiện có khoảng một triệu lượt xem trên YouTube. Tôi không cố khoe khoang ở đây, tôi chỉ chia sẻ điều này để khẳng định rằng tôi đã đi sâu vào những cách tốt nhất để sử dụng coding agent trong một thời gian dài và đã khám phá ra một số điều mà nhiều người khác thấy thực sự hữu ích.
- Advanced Context Engineering for Coding Agents
- No Vibes Allowed -- Solving Hard Problems in Complex Codebases
- Everything We Got Wrong About RPI
Dù sao đi nữa, Lời hứa của tất cả những lời "chỉ cần token mạnh hơn" trên mạng mà chúng ta buộc phải chịu đựng, một cách ngắn gọn, là: với đủ kỹ thuật dây cương (harness engineering), chúng ta có thể có được những điều tốt nhất của cả hai thế giới:
- Nhanh hơn 10 đến 100 lần,
- chất lượng cao, và
- không ai phải làm cái việc mà tất cả chúng ta đều ghét gọi là code review
Tất cả những gì chúng ta cần làm là cấu hình thêm nhiều linters và rắc một vài từ thần kỳ như "đánh giá đối kháng (adversarial review)" vào đủ nhiều bot đánh giá PR, và phần mềm của chúng ta sẽ tự xây dựng một cách hạnh phúc mà không có sự cố.
Đây không phải là vấn đề kỹ năng
Điều tôi sẽ cố gắng thuyết phục bạn là không có lượng kỹ thuật dây cương hay vòng lặp tối đa nào có thể giải quyết được một vấn đề cốt lõi là vấn đề huấn luyện mô hình.
Để giải quyết vấn đề này, tôi đã phải đi sâu vào cách các mô hình coding thực sự được huấn luyện và đánh giá - liên quan đến cả RLVR và khía cạnh benchmark.
Trong bài viết này, tôi sẽ đi qua:
- Các nhà máy phần mềm có từ năm 1968, chúng đã phát triển như thế nào, và AI đã thay đổi chúng ra sao
- Tại sao các mô hình có thể tạo ra núi rác mặc dù đạt điểm cao trong các benchmark (thậm chí là các benchmark "tiên tiến" mới toanh)
- Bất chấp điều này, bạn vẫn có thể di chuyển khá nhanh mà không cần đốt cháy codebase của mình
Tôi sẽ cố gắng cắt qua sự cường điệu của mọi plugin kỹ năng mới nổi hàng ngày và đại dịch lời khuyên về tâm lý-AI-tối-đa-hóa-token, và nói một cách tổng quát về các loại thứ hiệu quả mà không đề cập đến bất kỳ kỹ năng hay framework cụ thể nào.
Phiên bản Video: bài viết này dựa trên (và mở rộng từ) bài phát biểu quan trọng của tôi tại AI Engineer World's Fair 2026.
Cảm ơn @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, và @jeffreyhuber vì những phản hồi cho bài viết này.
Một điểm phụ: điều này không liên quan gì đến vibe coding
Addy Osmani đã gỡ rối một điều đáng được nhấn mạnh:
Một nhà phát triển đang vibe-code một dự án phụ mà chỉ có vài chục người sẽ chạy, và một nhóm đang duy trì một hệ thống doanh nghiệp mười năm tuổi cho một quý khác, hầu như không chia sẻ bất kỳ ràng buộc nào đáng kể, và hầu hết các lời khuyên đang lưu hành thực sự là một trong hai người đó bảo người kia cách sống.
Nếu bạn yêu thích vibe coding, xin hãy tiếp tục rung động. Tôi vẫn vibe code rất nhiều thứ, tôi chỉ cũng duy trì rất nhiều phần mềm sản xuất (và thông qua HumanLayer, giúp hàng nghìn kỹ sư khác làm điều tương tự), vì vậy phần còn lại của bài viết này nhắm đến những người giải quyết các vấn đề khó khăn trong các codebase phức tạp.
Tôi nghe từ brownfield rất nhiều để nói về sự phân chia này. Trong lịch sử, điều đó có nghĩa là một thứ Java mười năm tuổi nào đó, nhưng với tốc độ chúng ta có thể ship hàng bây giờ, có vẻ như một codebase do agent xây dựng bắt đầu gặp khó khăn sau khoảng ba đến sáu tháng -- bạn bắt đầu chậm lại, và cách bạn tiếp cận việc thêm những thứ mới phải thay đổi.
Lịch sử tóm tắt của nhà máy phần mềm
Tôi đã xây dựng và nghiên cứu các nhà máy phần mềm trong suốt sự nghiệp của mình, nhưng tôi chỉ mới biết được điều này gần đây: thuật ngữ này bắt nguồn từ một hội nghị NATO năm 1968 -- cũng chính là hội nghị đã cho chúng ta "kỹ thuật phần mềm (software engineering)".
Điều duy nhất khác tôi thấy cực kỳ thú vị kể từ đó là Bộ Quốc phòng Hoa Kỳ đã viết một bản PDF dài 31 trang về việc DoD cần bắt đầu sử dụng jenkins tốt hơn hay gì đó.
Nhà máy phần mềm năm 2022
Hãy đặt định nghĩa "nhà máy phần mềm" của chúng ta vào khoảng năm 2022, ngay trước thời AI. Trong một nhà máy phần mềm điển hình:
- Mọi người quyết định xây dựng cái gì -- kỹ sư, PM, lãnh đạo định hướng tầm nhìn
- Nó được đưa vào một hệ thống theo dõi -- Linear, Jira, bất cứ thứ gì: một máy trạng thái của những việc cần làm
- Ai đó nhận một ticket và xây dựng nó -- có thể làm một số kiểm tra thủ công/tự động trong khi làm
- Pull request -- các kiểm tra tự động, một người đánh giá code, có thể ai đó kéo nó xuống để kiểm tra
- Có gì sai không? Quay lại bước "ai đó xây dựng thứ đó"
- Ship lên prod -- và nó tiếp xúc với người dùng
- Thêm giám sát -- có cả một ngành công nghiệp xây dựng xung quanh việc gọi kỹ sư dậy lúc 3 giờ sáng khi có thứ gì đó hỏng
- Người dùng phàn nàn -- yêu cầu mọi thứ, tìm lỗi, gửi yêu cầu tính năng → quay lại nhóm để thêm vào hệ thống theo dõi
Và cứ thế tiếp diễn. Chúng ta thậm chí còn chưa chạm đến AI, và đã có một số vòng lặp trong bức tranh này.
tải trước sự liên kết (front-loading alignment)
Có một điều mà các nhóm đã phát hiện ra từ nhiều thập kỷ trước: việc xây dựng mất hàng giờ hoặc hàng ngày, và việc đánh giá cũng vậy.
Vì vậy, chúng tôi tải trước công việc -- lập kế hoạch, đề xuất kiến trúc, lập kế hoạch sprint -- cùng nhau, như một nhóm. Điều đó có nghĩa là:
- ít làm lại hơn, bởi vì chúng tôi đã thống nhất trước khi bất kỳ ai viết code
- ít thời gian đánh giá từng dòng hơn, nếu bạn đã từng đọc một PR dài nhưng được thực hiện tốt, bạn sẽ biết việc đánh giá diễn ra nhanh như thế nào khi nó gần như hoàn hảo
Chúng ta sẽ quay lại vấn đề này sau -- hãy xem điều gì xảy ra khi bạn đưa agentic coding vào bức tranh.
Nhà máy phần mềm agentic
Bây giờ mọi công ty và mẹ của họ --
đã dành phần lớn năm nay để giải thích cách họ xây dựng một nhà máy agent ship hàng với tỷ lệ khoảng 75% code của họ.
Nhà máy agentic trông hầu hết giống như việc thay thế "ai đó xây dựng thứ đó" → "một agent xây dựng thứ đó" -- có một số thứ ở đây như điều phối, dây cương, sandbox, mô hình, sử dụng máy tính, v.v. Tôi sẽ không đi sâu vào những chi tiết đó vì thành thật mà nói tôi phát ngán khi đọc về chúng và tôi chắc bạn cũng vậy.
Khi agent xây dựng thứ đó:
- Việc xây dựng giảm từ hàng giờ hoặc hàng ngày xuống còn hàng phút hoặc hàng giờ.
- Đánh giá vẫn mất hàng giờ hoặc hàng ngày. Một người vẫn phải đọc code và kiểm tra thay đổi. Vì vậy, đánh giá bây giờ là nút thắt cổ chai.
Vì vậy, bạn cũng tăng tốc đánh giá:
- Đánh giá code agentic, để bắt lỗi phong cách, lỗi, bảo mật.
- Kiểm tra hồi quy agentic, để chọc phá nó từ bên ngoài bằng trình duyệt và sử dụng máy tính và có thể gửi cho bạn một video dễ thương khi nó hoàn thành
Đánh giá bây giờ nhanh hơn, nhưng nó có thể vẫn là nút thắt cổ chai. Nhưng chúng ta có thể thực hiện nhiều vòng lặp hơn.
Tiếp theo, bạn có thể chuyển các sự cố vào nhà máy. Thay vì gọi ai đó lúc 3 giờ sáng, họ thức dậy và thấy một PR có thể đã sửa nó.
Chúng ta cũng có thể chuyển phản hồi của người dùng vào nhà máy. Mọi người yêu cầu thứ gì đó, nó được xây dựng.
Lúc này công việc chỉ còn hai câu hỏi: bạn có thể nhồi bao nhiêu thứ vào hàng đợi, và bạn có thể đánh giá và kiểm tra những gì ra nhanh đến đâu?
Điều này đưa chúng ta đến nhà máy phần mềm không đèn.
Nhà máy phần mềm không đèn (The lights-off software factory)
Dan Shapiro đã đặt ra thuật ngữ này và Simon Willison đã viết về cách triển khai của StrongDM -- nơi chúng ta không còn đọc code nữa.
Bạn nhìn vào nhà máy phần mềm xinh đẹp của mình. Nó bị hủy hoại bởi bước code review khó chịu đó và bạn nói: bạn biết không, cái thứ mà một người đọc mọi thay đổi đó? Không, cảm ơn.
Vì vậy, bạn bỏ nó, và bạn đặt nỗ lực vào chỗ khác:
- Đầu tư vào kiểm thử và để agent tự kiểm tra công việc của nó
- Đầu tư vào sandbox và điều phối
- Đầu tư vào đánh giá tự động
- Đầu tư vào giám sát
- Đầu tư vào triển khai
- Đầu tư vào việc thu thập tín hiệu phản hồi từ người dùng
Và bây giờ công việc thực sự chỉ còn một câu hỏi: chúng ta có thể yêu cầu agent xây dựng bao nhiêu thứ? Chúng ta muốn đun sôi bao nhiêu phần đại dương?
Điều này sẽ diễn ra rất tuyệt vời (không phải đâu)
Tôi sẽ đưa ra một giả định có khả năng gây tranh cãi: nhà máy không đèn không hoạt động.
Hãy cùng tìm hiểu lý do tại sao các nhà máy phần mềm thất bại.
Chúng tôi đã thử điều này
Vào tháng Bảy năm 2025, chúng tôi đã chuyển sang chế độ không đèn hoàn toàn. Chỉ đọc spec và ticket, các agent nền cho tất cả những thứ nhỏ/vừa, toàn bộ.
Nếu bạn đã thử điều này một cách nghiêm túc trong vài tháng, bạn đã biết kết cục là gì. Bạn sẽ tìm thấy ít nhất một vấn đề đủ phức tạp đến nỗi agent không thể giải quyết nó -- ngay cả với những prompt và quy trình làm việc tiên tiến nhất của bạn.
- Bạn thực hiện nghiên cứu sâu về ngữ cảnh, tổng hợp tất cả các phần phù hợp vào vùng thông minh để mô hình phân tích
- Bạn yêu cầu agent thử tái tạo theo 10 cách khác nhau
Cuối cùng bạn phải chấp nhận và đi đào sâu vào codebase mà bạn đã ngừng đọc ba tháng trước, cố gắng tìm ra cái gì bị hỏng.
Và trong lúc đó:
- Trang web của bạn đã bị sập.
- Người dùng của bạn đã tức giận.
- Và bạn, nếu bạn giống tôi, đã rất khốn khổ -- đọc tất cả code rác mà bạn đã để lọt vào hệ thống của mình.
Lần đầu tiên điều này xảy ra với chúng tôi, tôi đã phủi sạch. Mặc dù tôi vừa dành gần hai tuần để đào bới qua mớ spaghetti của claude, "rủi ro giảm sút là xứng đáng với tốc độ". Đến khoảng lần thứ ba vào tháng Mười Một, chúng tôi quyết định sẽ dễ dàng hơn nếu viết lại từ đầu, và đồng sáng lập của tôi đã dành hai tuần trong VS Code (thậm chí không phải cursor) để mò mẫm xây dựng lại tất cả các pattern bằng tay.
các mô hình làm giảm chất lượng codebase theo thời gian
Điều tôi muốn nói đến là thế này: các mô hình có một thiếu sót. Chúng không thể duy trì và cải thiện chất lượng codebase theo thời gian -- nếu không có một lượng đáng kể sự điều khiển của con người.4
Khi tôi nói về khả năng bảo trì (maintainability), tôi muốn nói đến điều cụ thể khi nó trở nên thực sự, thực sự khó để thay đổi một phần của codebase mà không làm hỏng phần khác. Đây là shotgun surgery của Martin Fowler.
Tôi sẽ không nói nhiều hơn về khả năng bảo trì. Có một loạt sách bạn có thể đọc về nó
- A Philosophy of Software Design của John Ousterhout
- Clean Code của Robert C. Martin
- Refactoring của Martin Fowler
Vậy, tại sao các mô hình không thể làm được việc bảo trì phần mềm?
"Nhưng chắc chắn các mô hình đã tốt hơn nhiều kể từ đó"
Lúc này bạn có thể đang muốn nói: nhưng Dex, chắc chắn các mô hình đã tốt hơn nhiều kể từ tháng Bảy
Chúng đã tốt hơn -- theo một số cách. Ở những cách khác, chúng vẫn như cũ.
- Giải quyết các vấn đề một lần, hoặc vibe-code một trang web tiếp thị mới? Có. Tốt hơn nhiều.
- Cải thiện chất lượng codebase theo thời gian? Không tốt hơn nhiều, theo như tôi có thể thấy.
Tôi không thể chứng minh điều này. Bạn cũng không thể chứng minh nó. Không có benchmark nào tốt cho khả năng của một mô hình trong việc duy trì chất lượng codebase. (Sẽ nói thêm về hướng đi đó sau.)
KHÔNG CÓ BENCHMARK NÀO TỐT cho khả năng duy trì chất lượng codebase của một mô hình
Nhưng nếu bạn đã làm việc với coding agent trong một thời gian -- và rất nhiều người đang đăng về chính xác điều này -- có lẽ bạn đã có cảm giác đó rồi: chúng có xu hướng làm mọi thứ tồi tệ hơn theo thời gian, và làm cho codebase khó làm việc hơn.
Vì vậy, để tìm ra tại sao điều này xảy ra, tôi muốn phóng to ra agent coding vĩ đại đầu tiên.
Claude Code đã thắng nhờ Học Tăng Cường (Reinforcement Learning) bên trong dây cương
Claude Code đã đi từ con số không lên ~$4B -- bây giờ là khoảng ~$9B -- doanh thu trong vòng chưa đầy một năm.
Điều này hơi điên rồ, bởi vì đã có những CLI agent tuyệt vời. aider, cline, codebuff -- tất cả đều có trước Claude Code, tất cả đều có kỹ thuật ngữ cảnh thực sự tốt được tích hợp sẵn, tất cả đều có cùng bộ công cụ mà bạn có thể gán cho claude code: đọc, ghi, chỉnh sửa, grep, bash. Tôi đã sử dụng chúng. Chúng rất tốt. Nhưng cũng có lúc, việc sử dụng công cụ sẽ... thất bại -- bạn sẽ thấy nó loay hoay với cùng một lần chỉnh sửa ba lần và mở lại editor của mình để tự làm.
Bài báo SWE-Agent từ năm 2024 phác thảo cách những thay đổi nhỏ trong hình dạng công cụ tạo ra sự khác biệt đáng chú ý, ví dụ: bao gồm số dòng trong kết quả ReadFile, hoặc thay đổi công cụ Edit từ tìm/thay thế sang chỉnh sửa theo phạm vi dòng.
Sau đó, Claude Code ra mắt và tăng trưởng theo chiều dọc khá nhanh chóng. Bạn có thể bỏ qua điều này như là vấn đề phân phối, nhưng lời giải thích được chấp nhận chính thức là claude code đã thắng vì nó tốt hơn, và nó tốt hơn vì Anthropic đã RL mô hình bên trong dây cương -- lần đầu tiên một phòng thí nghiệm huấn luyện một mô hình dựa trên các công cụ chính xác mà chúng sẽ được ship cùng. Và nó đã trở nên thực sự, thực sự giỏi trong việc gọi các công cụ đó trong một vòng lặp agentic.
Một chuyện là mày mò với các định nghĩa công cụ và evals cho đến khi bạn tìm thấy hình dạng mà mô hình thích nhất -- tôi đã dành hàng tuần để làm điều này cho các trường hợp sử dụng khác nhau. Đó là một trò chơi khác khi bạn sở hữu các trọng số và có thể sửa đổi chính mô hình để nó tốt hơn với một bộ công cụ cụ thể.
Nhóm OpenAI đã có một bài nói chuyện vào tháng Mười Một đã diễn đạt điều này khá hay: nếu bạn xây dựng một dây cương nhưng bạn không sở hữu các trọng số và không thể RL mô hình bên trong nó, bạn sẽ luôn ở thế bất lợi so với một nhóm sở hữu cả hai.
RL của Coding Agent trong 60 giây
Tôi đã thực hiện một loạt nghiên cứu về chủ đề này và nấu ra một loạt hình ảnh trực quan để cố gắng giải thích các phần quan trọng, nhưng tôi thấy rằng Calvin French-Owen (MTS trong nhóm codex, người sáng lập Segment) đã có một bài nói chuyện tại AI Council đã làm tốt hơn và sạch sẽ hơn nhiều, vì vậy tôi sẽ thả hoạt ảnh này ở đây lấy cảm hứng từ slide của anh ấy:
Để làm cho một mô hình giỏi coding hơn, bạn sẽ:
- tạo ra một số dấu vết (traces) của coding agent để giải quyết một vấn đề (ví dụ: sửa lỗi bài kiểm tra của tôi)
- chấm điểm các dấu vết dựa trên một số tiêu chí (bộ xác minh - verifier)
- cập nhật trọng số mô hình để làm cho các dấu vết tốt có nhiều khả năng xảy ra hơn và các dấu vết xấu ít khả năng xảy ra hơn
Và sau đó bạn làm điều này hàng triệu lần trong suốt nhiều tuần hoặc nhiều tháng.
Tuy nhiên, phần "chấm điểm" của những thứ này có xu hướng trở nên một chiều một cách kỳ quặc.
Không có hình phạt cho thiết kế tồi
Hãy lấy SWE-bench Multilingual làm ví dụ. Các nhiệm vụ nhỏ -- mỗi nhiệm vụ khoảng mười lăm phút làm việc -- được thu thập từ các kho mã nguồn mở như Redis, jq, và Django. Phần thưởng là một hoặc không dựa trên:
- FAIL_TO_PASS - bạn đã sửa thứ bạn được yêu cầu sửa chưa?
- PASS_TO_PASS - bạn đã làm điều đó mà không làm hỏng thứ gì khác chưa?
Đây là một ví dụ thực tế, fastlane__fastlane-19304, từ fastlane -- một dự án Ruby. Hành động zip của nó lấy hai tham số tùy chọn và gọi .empty? trên chúng ngay lập tức, vì vậy ngay khi bạn bỏ qua include và exclude, nó sẽ thất bại:
Bản sửa lỗi của con người đã đóng vấn đề cụ thể này là hai dòng (đặt nil mặc định thành mảng rỗng):
Trong quá trình đánh giá, mô hình
- bắt đầu từ một commit cơ sở -- kho mã được checkout đến thời điểm ngay trước khi bản sửa lỗi đó được áp dụng
- báo cáo lỗi - trong trường hợp này là 'zip_command': undefined method 'empty?' for nil:NilClass
Agent đi và viết một số code dựa trên vấn đề. Nó không nhìn thấy bản vá vàng (golden patch) hoặc bản vá kiểm thử đóng vai trò là người chấm điểm:
Sau đó:
- Chúng tôi giữ lại bất kỳ bản vá nào nó đã tạo ra, sau đó
- Loại bỏ bất kỳ chỉnh sửa nào nó đã thực hiện đối với các tệp kiểm thử (chúng tôi đã bắt gặp một mô hình lặng lẽ comment-out bài kiểm tra thất bại hoặc chèn một mock làm cho bài kiểm tra trở nên vô dụng)
- Áp dụng bản vá kiểm thử của benchmark lên trên, và
- Chạy toàn bộ bộ kiểm thử: các bài kiểm tra zip hiện có (PASS_TO_PASS) cộng với bài kiểm tra mới (FAIL_TO_PASS) để xem liệu chúng có vượt qua không
Ngoài lề - Benchmarks không phải là bộ xác minh - trên thực tế, chúng phải được tách riêng với nhau (đừng huấn luyện trên bài kiểm tra, v.v.) - tôi chủ yếu muốn truyền đạt hình dạng của "đánh giá chất lượng của một dấu vết coding agent" và những hạn chế của nó.
Cách mô hình đạt được câu trả lời đúng không quan trọng. Nếu các bài kiểm tra vượt qua, chúng ta thắng, nhưng không có hình phạt nào cho việc xói mòn khả năng bảo trì codebase.
không có hình phạt cho việc xói mòn khả năng bảo trì codebase
Đó là cách bạn có try catch xung quanh mọi thứ:
Việc xác minh chất lượng khó hơn "các bài kiểm tra có vượt qua không" nhiều bậc
Chạy các bài kiểm tra giúp bạn có kết quả đậu hoặc rớt rõ ràng trong ~giây. Đó là lý do tại sao RL có thể chạy hàng triệu vòng lặp để tối ưu hóa từng thế hệ mô hình.
Nhưng hàm chi phí của kiến trúc tồi được đo bằng tuần, tháng, thậm chí có thể là năm. Nó xảy ra lần đầu tiên ai đó mở một tệp để thay đổi một dòng và nhận ra rằng họ không thể thực hiện nó trong một dòng -- ai đó đã vibe-code thứ này hơi quá mạnh, và bây giờ chúng ta phải thực hiện cùng một chỉnh sửa ở mười một nơi và hy vọng không có gì lặng lẽ làm hỏng ba tệp ở phía xa.
Các bài kiểm tra cho bạn phản hồi trong vài giây, nhưng hàm chi phí của kiến trúc tồi được đo bằng tuần, tháng, thậm chí có thể là năm
Thiết kế tồi là thứ duy nhất mà các benchmark ngày nay không thể đánh giá. Và tôi biết, tôi biết, RL != Benchmarks, nhưng nếu điều này đã được giải quyết trong RL, tôi khá chắc chắn nó sẽ bắt đầu xuất hiện trong cách các benchmark của chúng ta được thiết kế.
Trong mọi trường hợp, cá nhân tôi không tin tưởng bất kỳ cải tiến nào trên các benchmark hiện tại như một dấu hiệu cho thấy các mô hình đột nhiên giỏi trong việc không làm rác codebase của bạn.
Tiên phong đang tiến bộ, nhưng chậm
Tất nhiên, rất nhiều người thông minh đang làm việc về vấn đề này. Quan điểm của tôi không phải là nó không thể làm được, mà là sự cường điệu đang vượt xa kỷ luật.
Một vài nỗ lực mà tôi nghĩ đang đi đúng hướng:
- SWE-Marathon (Abundant AI): các nhiệm vụ ~400 giờ như "clone toàn bộ Excel, mọi tính năng" -- với một kênh phần thưởng tổng hợp thay vì một bit đậu/rớt duy nhất
- DeepSWE (Datacurve): các nhiệm vụ lớn trên các kho OSS chưa bao giờ thực sự được xây dựng trong thế giới thực, vì vậy về mặt cấu trúc, chúng không thể đã nằm trong tập huấn luyện (giải quyết vấn đề nhiễm, nhưng không giải quyết chất lượng)
- Frontier Code (Cognition): các nhiệm vụ nhiều PR, và một bước đi thông minh đánh giá chất lượng một cách xác định -- nó phạt mô hình vì viết các bài kiểm tra không thất bại trên code trước khi vá (nếu bạn chưa bao giờ nghe về kiểm thử đột biến (mutation testing), bạn sắp có một cuộc vui đây5). Nó cũng chạy một mô hình giám khảo trên diff để kiểm tra các quy tắc chất lượng code.
Nhưng một mô hình đánh giá chất lượng chỉ có thể đi được đến một mức độ nhất định.
Trên thực tế, không khó để tưởng tượng rằng nếu một mô hình có thể phân biệt đáng tin cậy giữa code tốt và code xấu, thì nó có thể đã viết ra phiên bản tốt ngay từ đầu. RL cần một oracle nhanh và đáng tin cậy, và chúng ta vẫn chưa có một oracle nào cho tính bảo trì
nếu một mô hình có thể phân biệt đáng tin cậy giữa code tốt và code xấu, thì nó có thể đã viết ra phiên bản tốt ngay từ đầu, nhưng tính bảo trì không có oracle nhanh, vì vậy chúng ta không thể thưởng cho nó trong quá trình RL
Tất nhiên, nhiều agent đánh giá hơn và nhiều token hơn sẽ giúp ích -- chúng nâng cao sàn, bắt được những thứ ngớ ngẩn.
Nhưng chúng không nâng cao trần nhà, bởi vì trần nhà là bất cứ thứ gì chúng ta quản lý để dạy cho mô hình trong RL, và thiết kế tốt là thứ mà chúng ta vẫn chưa biết cách dạy nó.
Vì vậy, tôi vẫn sẽ không đặt cược codebase của mình vào bất kỳ cái nào trong số này. Nhưng chúng là những bài đánh giá đầu tiên tôi thấy thậm chí cố gắng chấm điểm tính bảo trì thay vì chỉ dừng lại ở đỗ/trượt.
Ngoài lề Có thể một mô hình trong tương lai sẽ hiểu được điều này và chúng ta có thể dừng lại. Nếu bạn muốn yolo các prompt cho đến khi GPT-7 ra mắt và tìm hiểu, cứ tự nhiên -- nhưng bài học cay đắng có chết đi nữa, chúng ta có những vấn đề cần giải quyết ngay bây giờ, và tôi sẽ đi qua cách chúng ta làm điều đó.
Bật đèn trở lại
Hôm nay tôi biết được rằng Twitter Articles có một "giới hạn phương tiện" có nghĩa là phần còn lại của bài viết này sẽ được chuyển sang bài viết Phần II - hãy theo dõi nhé
