Bánh cóc độ phức tạp trong thời đại lập trình bằng AI: Vì sao cần độ bao phủ kiểm thử 90%

Đây là một bài tiểu luận dài mà Garry Tan (CEO của Y Combinator) chia sẻ trên X, tổng kết trải nghiệm trong một năm qua khi xây dựng hai dự án mã nguồn mở cùng với các tác nhân AI (Claude Code, Codex, v.v.). Ông cho biết AI đã viết phần lớn trong khoảng 970.000 dòng mã và 665 tệp kiểm thử, đồng thời ông vận hành 15 phiên tác nhân cùng lúc. Thông qua quá trình này, ông lập luận 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” nay đã bị phá vỡ, và đưa ra khái niệm Complexity Ratchet như cơ chế cốt lõi.

Tóm tắt các khái niệm chính

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

• Sự thay đổi của 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 giả định rằng “lỗi là chí mạng nên phải ngăn ngừa”, nhưng giờ đây phần lớn lỗi có thể được tác nhân chẩn đoán và sửa ở lượt kế tiếp.
• Mở rộng giới hạn độ phức tạp: Trần độ phức tạp của hệ thống đã mở rộng từ “lượng mà một nhóm có thể giữ trong đầu” sang “một người cùng các tác nhân đã nạp toàn bộ codebase vào ngữ cảnh”.
• Tính bền vững của ký ức tổ chức: Con người có thể rời đi vì nghỉ việc hay kiệt sức, nhưng tri thức được lưu lại trong kiểm thử và tài liệu có thể được bất kỳ mô hình nào ở bất kỳ thời điểm nào gọi lại.

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

• Đường cong chất lượng phi tuyến: Theo nghiên cứu hơn 10.000 dự án của Capers Jones, dưới 70% độ bao phủ thì tỷ lệ loại bỏ lỗi chỉ ở mức 65–75%, nhưng ở ngưỡng 85–95% lại tăng vọt lên 92–97%, tồn tại một “điểm gối” rõ rệt.
• Tiền lệ từ ngành hàng không: Tiêu chuẩn phần mềm hàng không DO-178C bắt buộc độ bao phủ MC/DC cho hệ thống Level A (mức nghiêm trọng 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 rất tẻ nhạt và tốn kém với con người, nhưng tác nhân không biết mệt nên có thể viết vô hạn các bài kiểm thử edge case ngay cả lúc rạng sáng.

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

• Cải thiện độ chính xác trích xuất của GBrain: Với hơn 100.000 lượt trích xuất niềm tin, vấn đề nhận nhầm “ai là người đưa ra phát biểu đó” ở mức 35% đã được cố định bằng 17 bài kiểm thử, khiến mọi phiên bản về sau không thể tụt xuống dưới mức này.
• Kiểm thử TTY của Superpowers: Tác nhân AI có xu hướ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 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 một cách an toàn, từ đó hạ thấp rào cản tham gia cộng tác.
• Giới hạn: Những lỗi mang tính phá hủy trạng thái (migration DB 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 rất khó kiểm thử.
• Trả lời phản biện: Trước ý kiến cho rằng “người viết kiểm thử tốt vốn cũng là người thiết kế kiến trúc tốt”, tác giả nhấn mạnh cốt lõi của ratchet không nằm ở con người mà ở lớp 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ật sự của lập trình bằng AI không phải ở chỗ “viết nhanh hơn”, mà ở chỗ nó biến “mức độ kiểm chứng trước đây quá đắt nên phải từ bỏ” thành thứ gần như miễn phí. Độ bao phủ kiểm thử 90% vốn là đặc quyền suốt 50 năm của các lĩnh vực như hàng không và y tế nay có thể trở thành việc thường nhật của một cá nhân, và theo đó 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ũng tăng vọt. Tuy 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 ông (Superpowers, GBrain), và một số thống kê được trích dẫn (ví dụ: GPT-5.5) vẫn cần được kiểm chứng, nên đây cũng là văn bản cần được đọc với thái độ phản biện.

[skymer]

https://www.youtube.com/watch?v=mJ2GZRV63TE
Người đã tạo một blog RoR với số dòng mã nhiều gấp 4 lần so với sqlite...