Tôi đã lập trình với AI suốt năm qua. Không chỉ đơn thuần là prompting – mà là xây dựng phần mềm thực thụ. Hai dự án mã nguồn mở: GStack, giúp các tác nhân lập trình AI hoạt động tốt hơn, và GBrain, biến mọi thứ bạn đọc và viết thành một cơ sở tri thức có thể tìm kiếm mà AI của bạn có thể sử dụng. Giữa hai dự án, có khoảng 970.000 dòng mã và 665 tệp kiểm thử. Hầu như tất cả đều được viết bởi Claude Code và Codex theo chỉ đạo của tôi (thường xuyên chạy 15 phiên Conductor đồng thời).
Tuần trước tôi đã hợp nhất mười bốn pull request trong 72 giờ. Gần 29.000 dòng mã mới. Mỗi bản phát hành đều được kiểm thử tốt hơn bản trước.
Điều đó được cho là bất khả thi. Tốc độ và chất lượng được cho là phải đánh đổi. Giao hàng nhanh, phá vỡ mọi thứ. Di chuyển chậm, giao hàng đúng. Hãy chọn một.
Bạn không cần phải chọn nữa. Chìa khóa là 90% độ phủ kiểm thử – và các tác nhân AI đã giúp việc đạt được điều đó trở nên miễn phí. Trong năm mươi năm, mức độ xác minh đó đã tiêu tốn quá nhiều ý chí của con người để duy trì. Giờ đây, tác nhân viết các bài kiểm thử cùng với mã. Kết quả là thứ tôi gọi là bánh cóc độ phức tạp: một hệ thống chỉ có thể trở nên tốt hơn, không bao giờ tệ hơn.
(Đây là bài thứ bảy trong loạt bài về xây dựng với AI: 1 2 3 4 5 6
Phần mềm từng rất mong manh
Trong năm mươi năm, toàn bộ kỷ luật kỹ thuật phần mềm được tổ chức xoay quanh một ý tưởng: ngăn ngừa lỗi, bởi vì lỗi là thảm họa.
Bạn phải viết mã đúng ngay từ đầu. Bỏ sót một trường hợp ngoại lệ và bạn sẽ gặp sự cố trong sản xuất. Triển khai một lần di chuyển cơ sở dữ liệu tồi và bạn sẽ mất dữ liệu khách hàng. Viết một hàm làm điều gì đó tinh vi, và khi người duy nhất hiểu nó nghỉ việc, không ai biết tại sao nó hoạt động. Toàn bộ hệ thống phụ thuộc vào việc con người phải cẩn thận, và con người thì không cẩn thận. Vì vậy, chúng tôi đã xây dựng các quy trình phức tạp – đánh giá mã, môi trường staging, nhóm QA, chuỗi phát hành – tất cả đều được thiết kế để bắt lỗi trước khi chúng đến tay người dùng.
Nó đại khái là hiệu quả. Nhưng nó rất chậm. Và nó có nghĩa là độ phức tạp của bất kỳ hệ thống phần mềm nào cũng có một giới hạn cứng: số lượng thứ mà một nhóm có thể nắm giữ trong đầu cùng một lúc.
Giờ đây phần mềm rất dẻo dai
Tôi không có ý nói là cẩu thả. Tôi muốn nói là có khả năng phục hồi theo một cách mà trước đây không thể.
Khi tôi nói "các mô hình đã ở đây", ý tôi là các tác nhân lập trình AI – Claude, GPT, Codex và hệ sinh thái đang phát triển xung quanh chúng – giờ đây có thể đọc mã, hiểu ngữ cảnh, chẩn đoán lỗi và viết bản sửa lỗi. Không hoàn hảo. Nhưng đủ tốt để mô hình lỗi cho phần mềm đã thay đổi.
Việc di chuyển bị hỏng? Tác nhân đọc thông báo lỗi, hiểu lịch sử lược đồ cơ sở dữ liệu qua 45 phiên bản, viết bản sửa lỗi, viết bài kiểm thử. Đồng bộ tệp bị treo trên một triệu symlink? Tác nhân chẩn đoán trình phân tích cú pháp bị timeout, giới hạn nó ở 30 giây, gửi bản sửa lỗi kèm các bài kiểm thử. Một đường ống trích xuất có lỗi ghi công? Một đánh giá chéo mô hình bắt được nó, prompt được lặp lại, việc thực thi được thêm vào lớp cơ sở dữ liệu.
Đối với hầu hết các lỗi cấp mã – lỗi logic, lỗi phân tích cú pháp, các trường hợp ngoại lệ bị hỏng – các tác nhân giờ đây có thể chẩn đoán và sửa chúng trong lượt tiếp theo. Điều đó thực sự mới mẻ. Các lỗi vẫn còn mang tính thảm họa là những lỗi phá hủy trạng thái: các lần di chuyển tồi trên dữ liệu sản xuất, lỗ hổng bảo mật bị khai thác trước khi phát hiện, rò rỉ quyền riêng tư không thể rút lại. Bánh cóc cũng giúp ích ở đây (các bài kiểm thử tốt bắt được hầu hết những lỗi này trước khi đưa vào sản xuất) nhưng sự thay đổi thực sự là phần lớn các lỗi trong một cơ sở mã đều thuộc loại có thể sửa được.
Đây là một sự thay đổi pha cho cách phần mềm được xây dựng. Nhưng nó chỉ hoạt động nếu bạn có bánh cóc.
Bánh cóc độ phức tạp của tác nhân
Bánh cóc là một cơ chế cho phép chuyển động chỉ theo một hướng. Một cờ lê ổ quay vặn một bu-lông về phía trước và ngăn nó quay ngược lại. Đó là phép ẩn dụ.
Trong phần mềm được viết mã bởi tác nhân, mỗi phiên lập trình với một tác nhân AI sẽ thêm ba thứ vào cơ sở mã:
- Các bài kiểm thử mã hóa "đúng" nghĩa là gì – các kiểm tra tự động chạy mỗi khi ai đó thay đổi mã và thất bại ầm ĩ nếu thay đổi làm hỏng thứ gì đó
- Tài liệu ghi lại lý do tại sao các quyết định được đưa ra – không chỉ mã làm gì, mà còn cả lý do và sự đánh đổi đằng sau nó
- Kết quả đánh giá thiết lập các ngưỡng chất lượng – các đánh giá có cấu trúc về chất lượng đầu ra với điểm số, để bạn biết liệu phiên bản tiếp theo có tốt hơn hay tệ hơn không
Lần tiếp theo một tác nhân làm việc trên cơ sở mã, nó tải cả ba thứ vào cửa sổ ngữ cảnh của nó (văn bản mà AI có thể nhìn thấy và suy luận). Nó không thể thoái lui xuống dưới bộ kiểm thử – các bài kiểm thử sẽ thất bại. Nó không thể bỏ qua tài liệu – nó ở ngay trong ngữ cảnh. Nó không thể gửi chất lượng dưới mức cơ sở đánh giá – điểm số đã được ghi lại.
Sàn chất lượng tăng lên sau mỗi lượt. Chuyển động chỉ về phía trước. Đó là bánh cóc.
Điều này trông như thế nào trong thực tế
Tôi sẽ làm cho điều này cụ thể. GBrain là một hệ thống tri thức tôi đang xây dựng – nó cung cấp cho các tác nhân AI bộ nhớ dài hạn bằng cách lưu trữ, lập chỉ mục và tìm kiếm thông qua các ghi chú, cuộc họp, cuộc trò chuyện và nghiên cứu của một người. Hãy nghĩ về nó như một bộ não thứ hai mà trợ lý AI của bạn thực sự có thể đọc được.
Một trong những tính năng của nó là trích xuất nhận thức luận: nó đọc qua hàng nghìn trang và trích xuất ai tin điều gì, với mức độ tin cậy nào, theo thời gian. "Garry nghĩ Bitcoin sẽ đạt 300.000 đô la (mức độ tin cậy: 0,45)." "Jared nghĩ startup này có tỷ lệ giữ chân mạnh (mức độ tin cậy: 0,80)." Đại loại như vậy, nhưng trên 28.000 trang.
Lần chạy trích xuất đầu tiên đã kéo được 100.720 tuyên bố. Tôi đã sử dụng một đánh giá chéo mô hình để chấm điểm chất lượng – tôi đã cho GPT-5.5 và Claude độc lập chấm điểm đầu ra. Tổng thể: 6,8 trên 10.
Vấn đề lớn nhất? Một thứ tôi gọi là nhầm lẫn chủ thể. Lấy tuyên bố "AI sẽ thay thế 80% kỹ sư phần mềm vào năm 2027". Ai giữ niềm tin đó? Có phải là người đã viết nó? Có phải là người mà họ đang trích dẫn? Hay đó là công cụ phân tích của hệ thống, đã suy luận nó từ một bản ghi podcast? Phiên bản 1 đã sai sự khác biệt này 35% thời gian. Điều đó quan trọng – nếu bạn đang xây dựng một hệ thống theo dõi những gì mọi người tin tưởng, bạn cần biết AI tin điều đó.
Vì vậy, kết quả đánh giá đã được ghi lại. Sáu chế độ thất bại cụ thể đã được xác định. Prompt phiên bản 2 đã giải quyết cả sáu. Việc làm tròn trọng số (điểm tin cậy) đã được thực thi ở lớp cơ sở dữ liệu – không còn độ chính xác giả như 0,74 khi 0,75 là câu trả lời trung thực. Mười bảy bài kiểm thử đã khóa chặt hợp đồng.
Giờ đây, không có phiên bản trích xuất nào trong tương lai có thể được gửi mà không vượt qua 17 bài kiểm thử đó. Không ai phải nhớ tại sao việc làm tròn trọng số lại quan trọng hoặc nhầm lẫn chủ thể là gì. Các bài kiểm thử sẽ nhớ.
Sàn chất lượng đã tăng lên vĩnh viễn. Đó là một vòng quay của bánh cóc.
Tại sao hầu hết các dự án vibecode đều chết
"Vibecoding" là thuật ngữ của Andrej Karpathy để chỉ việc lập trình với AI bằng cách mô tả những gì bạn muốn bằng ngôn ngữ tự nhiên và để mô hình tạo ra mã. Nó mạnh mẽ và đó là cách tôi xây dựng. Nhưng từ những gì tôi thấy qua các đơn đăng ký YC và kho lưu trữ mã nguồn mở, hầu hết các dự án vibecode bỏ qua các bài kiểm thử bắt đầu tan rã khi chúng đạt đến độ phức tạp vừa phải – vài nghìn dòng, một số ít tính năng tương tác.
Chúng bỏ qua bánh cóc. Không có bài kiểm thử, không có tài liệu, không có đánh giá. Tác nhân thêm độ phức tạp nhưng không có gì ngăn chặn sự thoái lui. Mỗi tính năng mới đều có khả năng phá vỡ một tính năng cũ, và nếu không có bài kiểm thử, bạn sẽ không phát hiện ra cho đến khi người dùng báo cáo. Đến phiên bản 0.5, cơ sở mã là một ngôi nhà ma ám, nơi mọi thay đổi đều phá vỡ điều gì đó bất ngờ. Sau đó, nhà phát triển viết một bài blog về việc lập trình AI không hiệu quả.
Lập trình AI hiệu quả. Họ chỉ không xây dựng bánh cóc.
Bạn có thể tranh luận rằng loại người viết bài kiểm thử cũng là loại người viết kiến trúc tốt ngay từ đầu. Công bằng. Nhưng cơ chế bánh cóc không phải về con người – nó về những gì xảy ra trong lượt tiếp theo. Khi một người đóng góp mới mở một PR, hoặc khi một phiên bản mô hình thay đổi, hoặc khi bạn đang lập trình lúc 2 giờ sáng và khả năng phán đoán của bạn bị suy giảm, các bài kiểm thử bắt các lỗi thoái lui bất kể ai đã viết chúng. Bánh cóc hoạt động ngay cả khi con người không ở trạng thái tốt nhất. Đó là vấn đề.
Nếu không có bài kiểm thử, cải tiến là một quá trình ồn ào – các tác nhân cố gắng làm cho mọi thứ tốt hơn, nhưng nếu không có tín hiệu thoái lui, những thay đổi tốt và xấu đều vô hình như nhau. Với một bộ kiểm thử dày đặc, bạn có được một bánh cóc trên bề mặt được kiểm thử: chất lượng chỉ có thể tăng lên đối với các hành vi bạn đã mã hóa. Đó là hầu hết hệ thống, không phải tất cả. Nhưng nó đủ để duy trì chuyển động về phía trước với tốc độ.
Các bài kiểm thử như bộ nhớ thể chế
Trong các công ty phần mềm truyền thống, bộ nhớ thể chế sống trong con người. Kỹ sư cấp cao, người biết tại sao lớp bộ nhớ đệm đó tồn tại. Kiến trúc sư, người nhớ lần di chuyển suýt phá hủy cơ sở dữ liệu. Trưởng nhóm kỹ thuật, người có thể giải thích trường hợp ngoại lệ kỳ lạ trong hệ thống thanh toán.
Con người rời đi. Họ nghỉ hưu, họ bị săn đón, họ kiệt sức. Khi họ rời đi, kiến thức đi theo họ. Mọi công ty phần mềm đều đã có trải nghiệm mở một tệp quan trọng và tìm thấy một bình luận viết // ĐỪNG THAY ĐỔI CÁI NÀY – hãy hỏi Dave và Dave đã nghỉ việc ba năm trước.
Cửa sổ ngữ cảnh của tác nhân không bỏ cuộc. Nó không bị săn đón. Nó không quên. Khi bộ kiểm thử mã hóa "việc làm tròn trọng số phải sử dụng bước tăng 0,05" và tài liệu giải thích "bởi vì đánh giá chéo mô hình cho thấy độ chính xác giả làm giảm độ tin cậy vào điểm tin cậy", kiến thức đó là bền vững. Bất kỳ tác nhân nào, bất kỳ mô hình nào, bất kỳ lúc nào cũng có thể tải ngữ cảnh đó và hiểu ràng buộc.
Các bài kiểm thử là bộ nhớ thể chế tồn tại qua sự thay đổi nhân viên. Đối với một dự án một người, chúng thậm chí còn quan trọng hơn – chúng là bộ nhớ thể chế duy nhất bạn có.
Mọi thứ có thể khai thác đều có thể kiểm thử được
Bánh cóc không chỉ hoạt động cho mã truyền thống. Nó hoạt động cho bất cứ thứ gì máy tính có thể quan sát.
Hãy nghĩ về các lớp của một hệ thống hiện đại. Hệ điều hành cung cấp cho bạn cây tiến trình, trạng thái hệ thống tệp, socket mạng, lịch trình cron. Terminal cung cấp cho bạn mọi lần gõ phím, mọi dòng đầu ra, mọi lời nhắc tương tác. Trình duyệt cung cấp cho bạn các trang đã kết xuất, trạng thái nút, sự kiện điều hướng. API cung cấp cho bạn các phản hồi có cấu trúc mà bạn có thể phân tích cú pháp và xác thực. Và các tác nhân AI cung cấp cho bạn hành vi có thể quan sát – chúng nói gì, chúng gọi công cụ nào, chúng làm mọi thứ theo thứ tự nào, liệu chúng có hỏi trước khi hành động không.
Tất cả những điều này đều có thể khai thác được. Và nếu bạn có thể khai thác nó, bạn có thể quan sát nó. Nếu bạn có thể quan sát nó, bạn có thể khẳng định về nó. Nếu bạn có thể khẳng định về nó, bạn có thể tạo bánh cóc cho nó.
Đây là một diện tích bề mặt lớn hơn nhiều so với các bài kiểm thử đơn vị truyền thống. Hãy để tôi chỉ cho bạn.
GStack là framework tác nhân lập trình mã nguồn mở của tôi – 93.000 sao GitHub, 701.000 dòng mã, 46 kỹ năng. Một trong những tính năng cốt lõi của nó là đánh giá kế hoạch tương tác: bạn yêu cầu nó xem xét kiến trúc của bạn, và nó đi qua kế hoạch từng phần, đặt câu hỏi, thăm dò các trường hợp ngoại lệ, thách thức các giả định của bạn. Giống như có một người quản lý kỹ thuật thực sự đọc mã.
Vấn đề: Claude Code đôi khi sẽ bỏ qua toàn bộ phần tương tác. Nó sẽ đọc tệp kế hoạch, đổ tất cả các phát hiện trong một lần và thoát – mà không hỏi người dùng một câu hỏi nào. Toàn bộ điểm của việc đánh giá là cuộc đối thoại qua lại. Bỏ qua nó phản tác dụng.
Làm thế nào bạn thậm chí kiểm thử điều đó? Bạn không thể kiểm thử đơn vị "AI đã có một cuộc trò chuyện". Không có framework kiểm thử truyền thống nào bao gồm điều này.
Vì vậy, tôi đã sử dụng chức năng TTY của Bun để xây dựng một harness kiểm thử (PR #1354) mà theo nghĩa đen sinh ra Claude Code bên trong một pseudo-terminal, cung cấp cho nó một kịch bản kho lưu trữ cụ thể, kích hoạt kỹ năng đánh giá và xem đầu ra terminal trong thời gian thực. Bài kiểm thử quan sát liệu tác nhân có kích hoạt một câu hỏi tương tác trước khi kết thúc hay không. Nếu nó đổ các phát hiện và thoát mà không hỏi bất cứ điều gì, bài kiểm thử thất bại.
Đó không phải là kiểm thử mã. Đó là kiểm thử xem một tác nhân AI có tuân theo một hợp đồng hành vi hay không. Ở cấp độ TTY. Bằng cách theo nghĩa đen xem nó làm việc.
Phản ứng bánh cóc là ba lớp:
- Cổng DỪNG trong hướng dẫn kỹ năng – các quy tắc rõ ràng nói "bạn PHẢI hỏi người dùng trước khi tiếp tục đến phần tiếp theo", với các điều khoản chống lý luận hóa đặt tên cho chế độ thất bại cụ thể để mô hình không thể nói chuyện để bỏ qua
- Điều khoản chống lối tắt – "tệp kế hoạch là ĐẦU RA của đánh giá tương tác, không phải là sự thay thế cho nó." Một câu đóng chính xác lỗ hổng mà mô hình tiếp tục khai thác.
- Các bài kiểm thử sàn cấp cổng – các bài kiểm thử harness TTY sinh ra Claude Code trong các kịch bản được kiểm soát và thất bại nếu tác nhân không hỏi ít nhất một câu hỏi tương tác
Giờ đây, khi Anthropic gửi một phiên bản mô hình mới, hoặc khi tôi thay đổi một prompt kỹ năng, bộ kiểm thử bắt bất kỳ sự thoái lui nào trong hợp đồng tương tác. Tác nhân không thể âm thầm ngừng đặt câu hỏi. Bài kiểm thử xem terminal và kiểm tra.
Hoặc lấy PR #880, đã gửi một plugin OpenClaw mới. Bài kiểm thử không chỉ kiểm tra mã có biên dịch hay không. Nó xây dựng plugin từ mã nguồn, sinh ra một phiên bản OpenClaw thực trong một hồ sơ biệt lập, cài đặt plugin qua CLI, chạy plugins inspect để xác minh runtime đã tải nó, đặt khe cấu hình, xác thực cấu hình và chạy plugins doctor để xác nhận không có chẩn đoán nào. Một vòng tròn đầy đủ từ đầu đến cuối qua hai chương trình riêng biệt. 359 dòng mã kiểm thử. Loại bài kiểm thử mà một người hầu như sẽ không bao giờ viết bằng tay vì việc thiết lập quá tẻ nhạt. Claude đã viết nó trong khoảng năm phút. Đó là bức tường nỗ lực biến mất trong thời gian thực.
Nguyên tắc tổng quát hóa. Bạn có thể kiểm thử ở cấp độ hệ điều hành: việc di chuyển có tạo đúng bảng không, công việc cron có kích hoạt không, tiến trình còn sống không? Ở cấp độ trình duyệt: trang có kết xuất không, tác nhân có điền đúng biểu mẫu không. Ở cấp độ API: mô hình có trả về JSON hợp lệ với lược đồ đúng không. Ở cấp độ hành vi: tác nhân có tuân theo giao thức không, nó có hỏi trước khi xóa không, nó có dừng lại khi được yêu cầu dừng không.
Toàn bộ ngăn xếp đều có thể kiểm thử được. Bánh cóc áp dụng cho tất cả. Hầu hết mọi người chưa nhận ra điều này bởi vì họ vẫn đang nghĩ về độ phủ kiểm thử như "hàm của tôi có trả về đúng số không". Bề mặt kiểm thử thực sự là mọi thứ máy tính có thể nhìn thấy.
Con số 90%
Vậy 90% độ phủ kiểm thử thực sự mang lại cho bạn điều gì?
Capers Jones đã nghiên cứu hơn 10.000 dự án phần mềm và đo lường hiệu quả loại bỏ lỗi (DRE) – tỷ lệ phần trăm lỗi bị bắt trước khi chúng đến tay người dùng. Dữ liệu của ông từ Applied Software Measurement cho thấy một đường cong phi tuyến tính: dưới 70% độ phủ, DRE nằm trong khoảng 65-75%. Ở 85-95% độ phủ, DRE nhảy vọt lên 92-97%. Mối quan hệ không phải là tuyến tính. Có một điểm gấp khúc trong đường cong khoảng 85% nơi các lỗi thoát ra giảm mạnh.
Ngành công nghiệp điện tử hàng không đã tìm ra điều này từ nhiều thập kỷ trước. DO-178C, tiêu chuẩn FAA cho phần mềm quan trọng đối với chuyến bay, yêu cầu độ phủ quyết định/điều kiện sửa đổi (MC/DC) cho các hệ thống Cấp A – những hệ thống mà một lỗi có nghĩa là một vụ tai nạn máy bay. Chỉ riêng độ phủ nhánh đã bỏ lỡ 10-20% lỗi. MC/DC, nghiêm ngặt hơn độ phủ dòng, đạt được >99% DRE. Họ không bắt buộc điều này bởi vì các quan chức thích thủ tục giấy tờ. Họ bắt buộc nó bởi vì dữ liệu cho thấy rằng dưới các ngưỡng độ phủ nhất định, các lỗi nghiêm trọng thoát ra với tỷ lệ không tương thích với việc không giết người.
Sự tương đồng với kỹ thuật độ tin cậy là rõ ràng. Các nhà máy sử dụng một hệ thống gọi là Six Sigma để đo lường chất lượng. Ý tưởng: đếm xem bạn nhận được bao nhiêu lỗi trên một triệu đơn vị sản xuất, sau đó thể hiện điều đó dưới dạng "mức sigma" – sigma cao hơn có nghĩa là ít lỗi hơn. Một quy trình 3-sigma tạo ra khoảng 67.000 lỗi trên một triệu (khá tệ). Một quy trình 4-sigma tạo ra khoảng 6.200 (tốt hơn mười lần). Một quy trình 5-sigma tạo ra 233 (tốt hơn 27 lần nữa). Bước nhảy từ 4 lên 5 sigma không phải là cải tiến gia tăng. Đó là một sự thay đổi pha.
Độ phủ kiểm thử tuân theo cùng một đường cong. Đi từ 70% lên 90% độ phủ không phải là tốt hơn 30%. Đó là một mức độ lớn hơn về số lượng lỗi thoát ra ít hơn. Các lỗi lọt qua ở 70% đang ẩn náu trong 30% mã chưa được kiểm thử. Ở 90%, các nơi ẩn náu thu hẹp xuống còn 10% và hầu hết các đường dẫn nguy hiểm đã bị khóa chặt.
Bây giờ, tôi nên thành thật về những gì nghiên cứu cũng cho thấy. Mockus, Nagappan và Dinh-Trong đã nghiên cứu Windows Vista và phát hiện ra rằng mặc dù độ phủ tương quan với ít lỗi sau phát hành hơn, nhưng nỗ lực để đạt 90%+ tăng mạnh. 20% độ phủ cuối cùng mất nhiều công sức hơn một cách không tương xứng so với 70% đầu tiên. Điều này đã đúng trong nhiều thập kỷ. Đó là lý do tại sao hầu hết các nhóm dừng lại ở 70-80% và gọi nó là đủ tốt.
Nhưng có điều gì đó đã thay đổi: Các tác nhân lập trình AI không cảm thấy nỗ lực.
Chúng không cảm thấy chán khi viết bài kiểm thử trường hợp ngoại lệ thứ mười bốn. Chúng không cắt góc lúc 5 giờ chiều thứ Sáu. Chúng không nhìn vào một bài kiểm thử tích hợp khó nhằn và nghĩ "Tôi sẽ quay lại sau." Đường cong nỗ lực đã ngăn các nhóm người ở mức 70% không áp dụng cho các tác nhân. Bạn có thể yêu cầu Claude viết các bài kiểm thử cho mọi trường hợp ngoại lệ trong một mô-đun và nó sẽ làm điều đó một cách vui vẻ, kỹ lưỡng, lúc 2 giờ sáng, mà không phàn nàn. 20% cuối cùng tàn bạo đã làm cho 90% độ phủ trở nên không thực tế đối với các nhóm người chính xác là loại công việc mà các tác nhân AI giỏi nhất.
Đây là sự mở khóa thực sự. Không phải là AI cho phép bạn viết mã nhanh hơn. Nhiều người đã nhận thấy điều đó. Đó là AI cho phép bạn xác minh ở một mức độ mà trước đây quá đắt để duy trì. Ngưỡng 90% mà dữ liệu nói là kỳ diệu? Nó từng tiêu tốn quá nhiều ý chí của con người để đạt được. Giờ đây nó miễn phí.
Đó là sự khác biệt chính. Bánh cóc không phải về độ phủ dòng như một thước đo phù phiếm. Nó về các bài kiểm thử mã hóa các hợp đồng hành vi – bài kiểm thử nhầm lẫn chủ thể, bài kiểm thử làm tròn trọng số, cổng đánh giá tương tác. Mỗi bài kiểm thử khóa chặt một bài học cụ thể đã học được. Độ phủ là proxy cho bạn biết có bao nhiêu hành vi của hệ thống đang được hợp đồng hóa. Ở 90%, hầu như mọi thay đổi hành vi đều kích hoạt một tín hiệu kiểm thử. Tác nhân hoặc vượt qua (an toàn để gửi) hoặc phá vỡ một bài kiểm thử (bị bắt ngay lập tức).
10% còn lại là các điểm tích hợp, đường ống cơ sở hạ tầng và các trường hợp ngoại lệ thực sự khó kiểm thử. Điều đó ổn. 90% là thứ biến hỗn loạn thành một bánh cóc.
Đạt 90% từng là một nỗ lực anh hùng. Giờ đây nó là một ngày thứ Ba. Đó là sự thay đổi cuộc chơi.
Bằng chứng về khái niệm
Tôi đã bắt đầu cả hai dự án một mình. Chúng không còn là một mình nữa.
GStack hiện có 37 người đóng góp. v1.30 đã kết hợp 21 PR cộng đồng trong một bản phát hành duy nhất. GBrain có 25 người đóng góp. v0.31.1.1 đã hạ cánh 22 bản sửa lỗi cộng đồng trong một PR – luồng xác thực, khởi tạo lược đồ, đồng bộ hóa, quyền riêng tư.
Bánh cóc là thứ làm cho điều này an toàn. Mọi PR bên ngoài đều phải vượt qua bộ kiểm thử hiện có. Một người đóng góp mới không cần phải hiểu toàn bộ hệ thống. Họ cần làm cho các bài kiểm thử vượt qua.
Các bản phát hành GBrain tuần trước kể câu chuyện:
- v0.31.0: một bảng dữ kiện mới cho bộ nhớ thời gian thực, cộng với một giai đoạn hợp nhất giấc mơ thúc đẩy ký ức ngắn hạn thành kiến thức dài hạn
- v0.31.1: đã sửa 25 lệnh CLI đang âm thầm định tuyến đến một cơ sở dữ liệu cục bộ trống thay vì bộ não thực tế của người dùng
- v0.31.1.1: hai mươi hai bản sửa lỗi do cộng đồng báo cáo trong một PR
- v0.31.2: đã sửa lỗi đồng bộ mã bị treo vĩnh viễn trên các kho lưu trữ lớn có symlink bằng cách thêm timeout 30 giây
Mỗi bản phát hành đều được gửi với nhiều bài kiểm thử hơn bản trước. Tác nhân viết các bài kiểm thử cùng với mã. Độ phủ không bị trượt bởi vì nỗ lực để duy trì nó không còn là gánh nặng của con người.
Giới hạn độ phức tạp mới
Giới hạn độ phức tạp cho phần mềm vừa trở nên cao hơn nhiều.
Nó từng bị giới hạn bởi khả năng của một nhóm để nắm giữ hệ thống trong đầu họ. Giờ đây nó bị giới hạn bởi một người cộng với các tác nhân có thể tải toàn bộ cơ sở mã, lịch sử lược đồ, bộ kiểm thử và tài liệu vào ngữ cảnh.
Đó là một con số lớn hơn nhiều. Và nó tiếp tục phát triển khi các cửa sổ ngữ cảnh lớn hơn và các mô hình giỏi hơn trong việc suy luận về mã.
Mọi công ty phần mềm không áp dụng mô hình này – các tác nhân cộng với gu thẩm mỹ cộng với một bộ kiểm thử chỉ tăng lên – đã và đang giao hàng chậm hơn và với chất lượng kém hơn so với một người có nó.
Các công cụ đã ở đây. Mã là nguồn mở. Các bài kiểm thử là bánh cóc. 90% độ phủ, mọi PR, không có ngoại lệ.
Trong năm mươi năm, 90% độ phủ là một thứ xa xỉ dành riêng cho điện tử hàng không và thiết bị y tế – các nhóm có ngân sách để ném giờ công của con người vào bức tường nỗ lực. Các tác nhân AI đã phá hủy bức tường đó. Ngưỡng độ phủ làm cho phần mềm đáng tin cậy không còn đắt đỏ nữa. Nó chỉ là một cài đặt. Câu hỏi không phải là liệu bạn có đủ khả năng chi trả cho 90% hay không. Đó là liệu bạn có đủ khả năng để không làm điều đó hay không.
Bánh cóc, các kỹ năng và toàn bộ hệ thống tri thức là mã nguồn mở và miễn phí trên GitHub. Hãy đi xây dựng.
Các dự án mã nguồn mở được cấp phép MIT của tôi:
- GStack – làm cho Claude Code tốt hơn đáng kể. 93K sao. Miễn phí.
- GBrain – bộ não thứ hai của bạn cho các tác nhân AI. 14K sao. Miễn phí.
Loạt bài Giải thích về AI:
- Kỹ năng béo, Mã béo, Dây cương mỏng – kiến trúc
- Bộ phân giải – bảng định tuyến cho trí thông minh
- Cuộc tranh cãi về LOC – 600K dòng thực sự đã tạo ra gì
- Các mô hình trần trụi thì ngu ngốc hơn – mô hình là động cơ, không phải là xe hơi
- Tuyên ngôn Skillify – mọi quy trình làm việc đều trở thành một kỹ năng có thể kiểm thử
- Meta-Meta-Prompting – các kỹ năng kết hợp tạo ra khả năng nổi trội
- Bánh cóc độ phức tạp của tác nhân – bạn đang ở đây
https://x.com/garrytan/status/2054055071017538028
https://x.com/garrytan/status/2042925773300908103
https://x.com/garrytan/status/2044479509874020852
https://x.com/garrytan/status/2045404377226285538
https://x.com/garrytan/status/2045798603059548364
https://x.com/garrytan/status/2046876981711769720
