Cơ chế bánh cóc về độ phức tạp của AI agent: Vì sao cần 90% độ bao phủ kiểm thử

Cơ chế bánh cóc về độ phức tạp trong thời đại lập trình bằng AI (Complexity Ratchet) - Tóm tắt bài luận của Garry Tan

Đây là bài viết tổng hợp từ một bài luận dài được Garry Tan (CEO của Y Combinator) chia sẻ trên X, tóm lược kinh nghiệm trong 1 năm qua khi ông xây dựng hai dự án mã nguồn mở cùng với các AI agent (Claude Code, Codex, v.v.). Theo đó, phần lớn trong khoảng 970.000 dòng mã và 665 tệp kiểm thử đều do AI viết, đồng thời ông vận hành 15 phiên agent cùng lúc. Thông qua quá trình này, ông cho rằng mệnh đề lâu nay của kỹ nghệ phần mềm rằng “tốc độ và chất lượng là hai lựa chọn loại trừ nhau” đã bị phá vỡ, và đưa ra khái niệm Complexity Ratchet như cơ chế cốt lõi.

Các khái niệm chính

• Ratchet là gì: Đây là một phép ẩn dụ chỉ cơ cấu bánh răng chỉ chuyển động theo một chiều, mang nghĩa tạo ra một cấu trúc khiến chất lượng codebase chỉ có thể tiến lên mà không lùi lại.
• Ba lớp tích lũy: Trong mỗi phiên lập trình với agent, có ba thứ được tích lũy vào codebase: kiểm thử (điều gì là đúng), tài liệu (vì sao lại đưa ra quyết định đó), và kết quả đánh giá (đường chuẩn chất lượng).
• Cách tận dụng context window: Ở phiên sau, AI agent sẽ đọc cả ba lớp này trước khi làm việc, nên khó có thể phá vỡ kiểm thử, phớt lờ tài liệu hoặc làm giảm điểm đánh giá.

Điểm khác biệt so với cách làm truyền thống

• Thay đổi mô hình lỗi: Trong 50 năm qua, kỹ nghệ phần mềm xây dựng các quy trình phức tạp như code review, QA, staging dựa trên tiền đề “lỗi là chí mạng nên phải phòng ngừa”. Nhưng nay phần lớn lỗi có thể được agent chẩn đoán và sửa ngay ở lượt tiếp theo.
• Mở rộng giới hạn độ phức tạp: Trần trên của độ phức tạp hệ thống đã được mở rộng từ “lượng mà một nhóm có thể giữ trong đầu” sang “một cá nhân cùng các agent đã nạp toàn bộ codebase vào ngữ cảnh”.
• Tính bền vững của ký ức thể chế: Con người có thể rời đi vì nghỉ việc hoặc kiệt sức, nhưng tri thức được lưu lại trong kiểm thử và tài liệu thì có thể được gọi lại ở bất kỳ thời điểm nào, bởi bất kỳ mô hình nào.

Ý nghĩa của 90% độ bao phủ kiểm thử

• Đường cong chất lượng phi tuyến: Theo nghiên cứu hơn 10.000 dự án của Capers Jones, khi độ bao phủ dưới 70%, tỷ lệ loại bỏ lỗi chỉ đạt 65~75%, nhưng ở mức 85~95% thì tăng vọt lên 92~97%, tức tồn tại một “điểm gãy” rõ rệt.
• Tiền lệ từ ngành hàng không: Chuẩn phần mềm hàng không DO-178C bắt buộc MC/DC coverage đối với hệ thống Level A (mức chí mạng), nhằm đạt tỷ lệ loại bỏ lỗi trên 99%.
• AI phá vỡ rào cản chi phí: Công việc lấp nốt 20% độ bao phủ cuối cùng vốn nhàm chán và tốn kém với con người, nhưng agent không biết mệt nên có thể viết test cho edge case không ngừng, kể cả lúc rạng sáng.

Các ví dụ thực tế được tác giả đưa ra

• Cải thiện độ chính xác trích xuất của GBrain: Trong hơn 100.000 lượt trích xuất niềm tin, có vấn đề nhầm lẫn 35% về việc “ai là người đưa ra tuyên bố đó”. Tác giả đã cố định vấn đề này bằng 17 bài kiểm thử, để mọi phiên bản về sau không thể tụt xuống dưới mức đó.
• Kiểm thử TTY của Superpowers: AI agent từng bỏ qua bước review tương tác, nên tác giả dùng trực tiếp tính năng pseudo terminal của Bun để giám sát và chặn hành vi đó, biến cả yêu cầu phi truyền thống như “AI có thực sự đối thoại hay không” thành thứ có thể kiểm thử.

Ưu điểm và giới hạn

• Ưu điểm: Người đóng góp từ bên ngoài không cần hiểu toàn bộ hệ thống; chỉ cần vượt qua kiểm thử là có thể merge PR an toàn, giúp hạ thấp rào cản cộng tác.
• Giới hạn: Những lỗi mang tính phá hủy trạng thái (DB migration sai, xâm phạm bảo mật, rò rỉ quyền riêng tư) vẫn cực kỳ nghiêm trọng, và khoảng 10% các điểm tích hợp cùng hạ tầng về bản chất vẫn khó kiểm thử.
• Trả lời phản biện: Trước ý kiến cho rằng “người viết test giỏi thì vốn cũng sẽ thiết kế kiến trúc giỏi”, tác giả nhấn mạnh cốt lõi của bánh cóc không nằm ở con người mà ở lưới an toàn cho lượt tiếp theo.

Thông điệp cốt lõi mà tác giả muốn truyền tải là giá trị thực sự của lập trình bằng AI không phải là “viết nhanh hơn”, mà là biến mức độ xác minh vốn trước đây quá đắt nên bị từ bỏ thành thứ gần như miễn phí. Mức 90% độ bao phủ kiểm thử, từng là đặc quyền của ngành hàng không và y tế suốt 50 năm qua, nay có thể trở thành điều bình thường với một cá nhân. Kéo theo đó là trần độ phức tạp của phần mềm mà một lập trình viên có thể tạo ra được nâng lên đáng kể. Dù vậy, bản thân bài viết cũng đồng thời mang tính quảng bá cho các dự án mã nguồn mở của tác giả (Superpowers, GBrain), và một số trích dẫn thống kê trong đó (ví dụ: GPT-5.5) vẫn cần được kiểm chứng, nên đây cũng là văn bản đòi hỏi cách đọc có phê phán.