Duyệt code do AI viết: danh sách kiểm 15 điểm cho người đọc diff

Dành cho người duyệt code, kể cả người mới làm quen. Từ kỹ thuật nào cũng có giải thích ngắn.

Số liệu lấy từ báo cáo và nghiên cứu công khai ở cuối bài. Nhiều số do hãng công nghệ công bố nên cần đọc thận trọng. Ví dụ ghi là "minh họa" được dựng lại cho dễ hình dung, không thuộc vụ việc cụ thể nào.

---

Tóm tắt nhanh#

• Khi AI viết code nhanh, nút thắt dời sang khâu duyệt. Nhóm dùng AI nhiều gộp thêm nhiều thay đổi, nhưng mỗi thay đổi tốn thời gian duyệt hơn.
• Code do AI viết trông gọn và chạy được, điều này làm người duyệt dễ chủ quan. Hãy dùng một danh sách cố định thay vì đọc theo cảm giác.
• Danh sách này có 15 điểm, chia bốn nhóm: hiểu đúng việc (3), đúng và an toàn (5), kiểm thử có giá trị (3), dễ bảo trì (4).
• Ba điểm hay bị bỏ sót nhất: thư viện có thật không, đầu vào có bị tin quá không, test có thất bại khi code sai không.
• AI có thể duyệt lượt đầu, nhưng người vẫn chịu trách nhiệm. Hỏi AI "tìm lỗi", đừng hỏi "có đúng không".
• Một mô tả PR tốt ghi rõ phần AI viết, phần người đã kiểm, và cách đã kiểm.

---

Từ khó, nói dễ#

---

1. Vì sao phải duyệt kỹ hơn#

Có ba loại bằng chứng, đều cần đọc thận trọng.

• Nút thắt đã dời. Báo cáo "AI Productivity Paradox" của Faros AI (7/2025, hơn 10.000 lập trình viên ở 1.255 nhóm) ghi nhận nhóm dùng AI nhiều gộp thêm khoảng 98% thay đổi, nhưng thời gian duyệt mỗi thay đổi tăng khoảng 91% và kích thước thay đổi tăng khoảng 154%. Đây là dữ liệu của hãng bán công cụ đo lường, là tương quan chứ chưa chắc nhân quả, và mình mới đọc các bài tóm tắt.
• Lỗi bảo mật. Báo cáo GenAI Code Security 2025 của Veracode (80 tác vụ, hơn 100 mô hình) thấy mã do AI tạo ra có lỗ hổng ở khoảng 45% tác vụ. Với lỗi XSS và ghi log không an toàn, mô hình không bảo vệ đúng ở khoảng 86% và 88% trường hợp. Trước đó, nghiên cứu của Pearce và cộng sự (2021) thấy khoảng 40% trong 1.689 chương trình do Copilot viết có lỗ hổng. Đây là số liệu đo trên tác vụ thử nghiệm, không phải trên mã đang chạy thật.
• Niềm tin quá mức. Nghiên cứu của Perry và cộng sự (Stanford, 2022) thấy người dùng trợ lý AI viết code kém an toàn hơn ở bốn trên năm bài nhưng tin hơn rằng code của mình an toàn. Nhóm nhỏ, mô hình đời cũ, nên đọc như một dấu hiệu.

Các bằng chứng này nối với bài vì sao không nên tin AI tuyệt đối và bài làm việc nhóm IT thời AI: kết quả trông hoàn chỉnh nên khó thấy lỗi, và nút thắt giờ nằm ở chỗ đọc.

Hướng dẫn duyệt code công khai của Google (eng-practices) có ba câu hỏi nền đáng nhớ: thiết kế có hợp với hệ thống không, hành vi có đúng ý và tốt cho người dùng không, và code có thể đơn giản hơn không. Danh sách dưới đây cụ thể hóa ba câu đó cho trường hợp code do AI viết.

---

2. Danh sách kiểm 15 điểm#

Mức độ: Cao là có thể gây sự cố hoặc mất dữ liệu, Vừa là gây nợ kỹ thuật hoặc lỗi nhỏ.

Nhóm A. Hiểu đúng việc#

Nhóm B. Đúng và an toàn#

Nhóm C. Kiểm thử có giá trị#

Nhóm D. Dễ bảo trì#

Hai điểm cần nói thêm về bằng chứng:

• Điểm 4 nối với nghiên cứu về tên thư viện bịa (Virginia Tech và cộng sự, 2025): cỡ một trên năm gợi ý thư viện không tồn tại, và khoảng 43% tên bịa lặp lại ở mọi lần hỏi, nên kẻ tấn công có thể đăng ký trước tên đó (slopsquatting).
• Điểm 12 nối với phân tích của GitClear (2025, hơn 211 triệu dòng thay đổi): các bài tóm tắt nêu số khối code trùng lặp tăng mạnh và tỷ lệ dòng được tái cấu trúc giảm trong năm 2024. Đây là dữ liệu của một hãng bán công cụ phân tích, là tương quan, và mình mới đọc các bài tóm tắt.

---

3. Thứ tự đọc một PR trong 15 phút#

1. Đọc mô tả và mô tả việc gốc (2 phút). Nếu mô tả không nói rõ, dừng lại và hỏi. Điểm 1, 2, 3.
2. Đọc test trước code (3 phút). Test cho biết tác giả hiểu việc ra sao. Điểm 9, 10.
3. Quét các điểm rủi ro cao trong diff (6 phút). Đầu vào, bí mật, xóa và ghi đè, thư viện mới. Điểm 4, 5, 6, 7, 8.
4. Chạy thử (3 phút). Chạy test, chạy tính năng, thử một trường hợp xấu. Điểm 10, 11.
5. Đọc phần còn lại để bảo trì (1 phút trở lên). Trùng lặp, độ phức tạp, quy ước. Điểm 12 đến 15.

Nếu mục 3 phát hiện vấn đề, đừng đọc tiếp để "gom đủ lỗi". Trả lại sớm để tác giả sửa, vì mỗi vòng đều tốn thời gian.

---

4. Mẫu mô tả PR cho code có AI tham gia#

Một mô tả tốt giúp người duyệt biết nên nhìn đâu.

Việc: thêm nút hủy đơn trên trang đơn hàng
Xong là: có test, hoàn tiền được xử lý, có ảnh chụp màn hình

AI viết: giao diện nút, hàm gọi API hủy, test cho trường hợp thường
Người đã kiểm: đọc toàn bộ diff, chạy test, thử hủy đơn đã giao
Người đã sửa: bỏ một thư viện không cần, thêm xử lý khi API lỗi

Cách kiểm lại: chạy npm test, mở trang đơn hàng, bấm hủy một đơn thử
Điều chưa chắc: hoàn tiền với đơn trả góp, cần người hiểu nghiệp vụ xem

Khi người duyệt thấy dòng "Điều chưa chắc", họ biết nên dồn sức vào đâu. Mô tả này cũng ép tác giả tự đọc lại diff trước khi gửi.

---

5. Dùng AI để duyệt hộ thì sao#

AI duyệt giúp được ở lượt đầu: tìm lỗi nhỏ, nhắc điểm quên, đọc nhanh phần dài. Nhưng đừng coi nó là người duyệt cuối, vì ba lý do:

• Xu hướng chiều ý. Nghiên cứu của Anthropic về sycophancy (Sharma và cộng sự, 2024) thấy nhiều trợ lý AI hay nhận một lỗi không có thật khi bị chất vấn, và dễ đồng tình với người hỏi. Một AI được hỏi "code này đúng không" dễ trả lời "đúng".
• Cùng một nguồn lỗi. AI duyệt có thể mắc đúng kiểu lỗi mà AI viết đã mắc.
• Không chịu trách nhiệm. Người ký tên mới chịu trách nhiệm.

Cách dùng đỡ rủi ro hơn là yêu cầu cụ thể:

Đọc diff này như một người duyệt khó tính.
Tìm ba chỗ có thể sai và nói vì sao.
Liệt kê mọi thư viện, hàm và tham số mới, và nói bạn chắc chắn tới đâu.
Chỉ ra đầu vào nào chưa được kiểm tra.
Nếu không tìm thấy lỗi, hãy nói rõ bạn đã xem những gì.

Rồi người đọc lại những chỗ AI chỉ ra, và đọc cả chỗ nó không nhắc tới.

---

6. Ba tình huống minh họa#

Dựng lại từ lỗi thường gặp, không thuộc vụ việc cụ thể nào.

Thư viện "nghe rất thật". AI thêm pip install fastparse-utils để đọc một định dạng file. Mọi thứ trông hợp lý, nhưng người duyệt kiểm tra trang của gói (điểm 4): gói mới đăng ký tuần trước, chỉ một người duy trì. Gói thay thế phổ biến đã có sẵn trong dự án.

Test luôn xanh. AI viết test cho hàm tính phí, nhưng test dùng mock trả về đúng con số mà test mong chờ (điểm 9). Người duyệt làm hỏng công thức một dòng (điểm 10), test vẫn qua. Họ yêu cầu viết lại test với số liệu thật.

Diff quá lớn. Một PR gộp đổi tên, tái cấu trúc và tính năng mới, hơn một nghìn dòng. Người duyệt trả lại và yêu cầu chia ba (điểm 15). Ba PR nhỏ được duyệt xong nhanh hơn một PR lớn đang chờ.

---

7. Nhìn cân bằng#

Danh sách này không có nghĩa là code do AI viết kém hơn code do người viết. Con người cũng quên kiểm tra đầu vào và viết test yếu. Điểm khác là tốc độ và vẻ ngoài: AI tạo ra nhiều code nhanh hơn, và code trông gọn gàng nên lỗi khó lộ. Danh sách này vì thế có ích cho cả code của người.

Số liệu về lỗi bảo mật đo trên các tác vụ thử nghiệm của một hãng bảo mật và có thể đã khác ở các mô hình mới. Số liệu Faros và GitClear là tương quan. Điều chắc chắn hơn là cấu trúc: chi phí viết một bản nháp giảm, chi phí kiểm chứng thì không giảm theo. Đầu tư vào quy trình duyệt, kiểm thử tự động và sổ tay chung thường có lợi hơn thêm người duyệt.

---

8. Mười lăm điểm trong một trang#

Tóm tắt để in ra.

---

9. Kết luận#

Khi AI làm cho việc viết code rẻ đi, việc duyệt trở thành khâu quyết định chất lượng. Một danh sách cố định giúp người duyệt không phải dựa vào cảm giác, và một mô tả PR trung thực giúp họ biết nên nhìn đâu. AI có thể đọc lượt đầu, nhưng người ký tên mới là người chịu trách nhiệm.

Bắt đầu nhỏ: lấy ba điểm hay bị bỏ sót nhất (4, 5, 10), áp dụng cho PR tiếp theo, và ghi lại điều bạn bắt được. Một tuần sau, thêm những điểm còn lại theo lỗi mà nhóm thực sự gặp.

---

Nguồn tham khảo#

Số liệu lấy từ nguồn công khai tính đến tháng 10/2026. Nhiều nguồn là báo cáo của các hãng hoặc bài tóm tắt, và một số con số được thuật lại hơi khác nhau, nên hãy mở nguồn gốc để kiểm tra trước khi trích dẫn.

• Faros AI, AI Productivity Paradox (7/2025): bài tóm tắt của Faros và bài tóm tắt của Software Seni (chưa đọc bản gốc)
• Veracode, GenAI Code Security Report 2025: thông cáo của Veracode và Help Net Security
• Pearce và cộng sự, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (2021)
• Perry và cộng sự, Do Users Write More Insecure Code with AI Assistants? (Stanford, 2022)
• Nghiên cứu về slopsquatting: Dark Reading và Infosecurity Magazine
• GitClear, AI Copilot Code Quality 2025: bài phân tích của LeadDev (bài tóm tắt, chưa đọc bản gốc)
• Sharma và cộng sự, Towards Understanding Sycophancy in Language Models (ICLR 2024)
• Google, Engineering Practices: The Code Reviewer's Guide