Điểm mù trong phát hiện lỗi của AI lập trình: Thách thức không nằm ở độ khó mà ở thông tin thiếu hụt

28 thí nghiệm gỡ lỗi được thực hiện trên ba lỗi thực tế từ các thư viện mã nguồn mở phổ biến đã hé lộ một sự thật bất ngờ: AI lập trình không gặp khó khăn với những lỗi phức tạp về mặt thuật toán, mà thất bại thảm hại trước những lỗi đòi hỏi hiểu biết về hợp đồng API không được ghi chú. Kết quả cho thấy vấn đề lớn nhất không nằm ở sức mạnh của mô hình hay quy trình làm việc, mà ở khả năng nhận biết khi nào thông tin không đủ để đưa ra giải pháp đúng đắn.

Thí nghiệm: Ba lỗi thực tế, ba cấp độ khó khác nhau

Để kiểm tra khả năng gỡ lỗi của AI, tác giả đã chọn ba lỗi thực tế từ ba thư viện JavaScript phổ biến: ky (HTTP client), immer (thư viện immutability cho Redux Toolkit) và decimal.js (thư viện số học chính xác cao). Cả ba lỗi đều được sửa trong tháng 7/2026, sau thời điểm cắt dữ liệu huấn luyện của các mô hình, đảm bảo AI chưa từng thấy lời giải trước đó.

Ba lỗi được chọn để trải rộng từ dễ đến khó:

• ky #867: Lỗi nhìn có vẻ đơn giản - số lần thử lại (retry) bị mất khi dùng .extend()
• immer #1255: Lỗi phức tạp - state gốc bị biến đổi sau reverse()/sort() với plugin array-methods
• decimal.js #260: Lỗi số học tinh vi - hàm asin() mất độ chính xác khi x gần bằng 1

Hình 1: AI thực sự gặp khó với một lỗi dễ, không phải lỗi khó

Kết quả đảo ngược mọi dự đoán ban đầu

Lỗi khó: 16/16 lần thành công

Điều bất ngờ nhất là kết quả hoàn toàn trái ngược với giả thuyết ban đầu. Hai lỗi được đánh giá là "khó" - một lỗi chôn sâu trong proxy internals của immer và một lỗi số học tinh vi trong decimal.js - đều được AI giải quyết thành công trong toàn bộ 16 lần chạy trên nhiều mô hình và quy trình khác nhau.

Đối với lỗi decimal.js, không lần chạy nào đi theo hướng "tăng độ chính xác" - giải pháp hấp dẫn nhưng không đầy đủ. Thay vào đó, 6/8 lần chạy độc lập tái khám phá ra công thức toán học tương tự như bản vá chính thức của maintainer, trong khi 2 lần còn lại sử dụng cách tiếp cận thích ứng cũng vượt qua được bài kiểm tra ẩn.

Hình 2: Vấn đề của decimal.js nằm ở công thức toán, không phải độ chính xác

Lỗi "dễ": 0/12 lần thành công - và mọi bản vá đều làm hỏng dữ liệu người dùng

Lỗi ky #867 - tưởng chừng đơn giản nhất - lại trở thành thất bại toàn diện. Mặc dù tất cả 12 lần chạy đều xác định đúng nguyên nhân gốc (logic deep-merge không hiểu cú pháp rút gọn retry: 3), nhưng không một lần chạy nào đưa ra được giải pháp đúng đắn.

Vấn đề nằm ở chỗ: giải pháp "hiển nhiên" là chuẩn hóa giá trị số thành { limit: 3 } trước khi merge. Nhưng hàm deep-merge này cũng xử lý payload JSON của người dùng. Nếu payload chứa trường retry, bản vá này sẽ âm thầm biến dữ liệu người dùng thành cấu hình retry - làm hỏng dữ liệu thật sự.

Mọi lần chạy đều tạo ra bản vá "sửa lỗi" vượt qua toàn bộ 84 bài kiểm tra retry hiện có, nhưng làm hỏng dữ liệu payload. Vấn đề nghiêm trọng hơn: nếu đội ngũ phát triển merge bản vá của AI vì CI xanh, đây chính là loại lỗi lọt qua khe cửa.

Vấn đề không nằm ở mô hình hay quy trình

Sức mạnh mô hình không tạo khác biệt

Ba cấp độ mô hình Claude - Haiku 4.5, Sonnet 5 và Opus 4.8 - đều rơi vào cùng một cái bẫy. Mô hình rẻ nhất và mạnh nhất tạo ra cùng một loại lỗi hỏng dữ liệu. Điều này phủ nhận giả thuyết rằng vấn đề nằm ở năng lực mô hình.

Quy trình phức tạp hơn không giúp ích

Tác giả thử nghiệm ba quy trình: agent đơn lẻ, quy trình gstack có bước liệt kê tác động phụ, và pipeline song song với hai agent chẩn đoán độc lập, một agent triển khai và một reviewer có quyền sửa mã. Tất cả đều thất bại.

Phát hiện đau lòng: Reviewer phát hiện lỗi nhưng vẫn phê duyệt

Trong một lần chạy với pipeline song song, reviewer agent đã xác định chính xác rằng bản vá sẽ làm hỏng dữ liệu người dùng, viết ra phân tích chi tiết và... vẫn phê duyệt merge. Lý do: nó cho rằng khả năng xảy ra thấp và đây là lớp vấn đề đã tồn tại từ trước. Thất bại không nằm ở khâu phát hiện mà ở khâu ra quyết định.

Bài học quan trọng: Phân loại ticket theo thông tin, không theo độ khó

Kết quả từ 28 thí nghiệm này mang lại một nguyên tắc định tuyến mới cho các team phát triển:

Hãy hỏi: "Mọi thứ cần thiết để tạo ra bản vá đúng có nằm trong code và ticket không, hay sự đúng đắn phụ thuộc vào cách hệ thống được sử dụng thực tế?"

Khi câu trả lời là "tất cả đều trong repository" - một invariant, một thuật toán, một điều kiện đua - AI là công cụ gỡ lỗi tốt hơn nhiều so với danh tiếng của nó. Nhưng khi giải pháp phụ thuộc vào hợp đồng không được nêu rõ - ai gọi hàm này, dữ liệu gì chảy qua nó - bức tranh hoàn toàn thay đổi. Không một mô hình hay quy trình nào giải quyết được vấn đề này một cách đáng tin cậy.

Hình 3: Câu hỏi định tuyến - lỗi khó nhưng có thể khám phá là lãnh địa của AI

Hai điểm đòn bẩy thực sự

Đầu tiên, cải thiện ticket: Mỗi hợp đồng bạn làm rõ sẽ cung cấp cho agent thông tin mà nó không thể suy ra từ code. Một câu bổ sung có thể đáng giá hơn cả việc nâng cấp mô hình.

Thứ hai, thiết lập cổng chặn (blocking gate): Nếu một reviewer AI phát hiện rủi ro tác dụng phụ hoặc hỏng dữ liệu, phát hiện đó phải tự động chặn merge - không cân nhắc xác suất, không tùy ý quyết định. Trong thí nghiệm, khi reviewer phát hiện vấn đề nhưng workflow vẫn bỏ qua, đó chính là điểm hỏng của cả quy trình.

Kết luận

Thí nghiệm này không chỉ ra rằng AI lập trình kém cỏi - ngược lại, nó cho thấy AI vượt trội với những lỗi phức tạp mà thông tin có thể khám phá từ codebase. Nhưng nó cũng phơi bày một điểm mù nghiêm trọng: khi sự đúng đắn phụ thuộc vào kiến thức về cách người dùng thực tế sử dụng thư viện - thông tin không tồn tại trong code - AI tạo ra những bản vá tưởng chừng đúng nhưng thực chất phá hủy dữ liệu.

Với các kỹ sư và tech lead tại Việt Nam đang ngày càng phụ thuộc vào AI để viết mã sản xuất, bài học quan trọng nhất là: đừng tin vào CI xanh. Hãy kiểm tra kỹ các bản vá AI, đặc biệt khi chúng đụng đến dữ liệu người dùng, và thiết lập quy trình phê duyệt có cổng chặn tự động cho các phát hiện rủi ro. Một câu hợp đồng rõ ràng trong ticket có thể đáng giá hơn một mô hình mạnh hơn.

Hạn chế của nghiên cứu: Nhãn "khó/dễ" dựa trên trực giác tác giả, kết quả về hợp đồng không được nêu rõ dựa trên một lỗi duy nhất, và cỡ mẫu nhỏ nên cần xem là định hướng hơn là kết luận cuối cùng.