Tóm tắt: Review code do AI viết cần người kiểm tra những chỗ AI review dễ bỏ qua: quy tắc nghiệp vụ, phân quyền, xử lý dữ liệu, thư viện hoặc API không có thật và bài test không kiểm tra gì. VAON kết hợp cổng tự động, AI rà soát và người review theo quy trình 7 bước, rồi lưu hồ sơ review và test để khách hàng xem được.
Mục lục
- Vì sao code do AI viết vẫn cần người review?
- Người review nên kiểm tra những góc nhìn nào?
- Làm sao nhận ra bài test vô nghĩa và thư viện không có thật?
- Công cụ tự động, AI và người chia việc thế nào?
- Quy trình 7 bước của VAON để lại hồ sơ gì?
- Khi nào cách làm này chưa đủ?
- Câu hỏi thường gặp
1. Vì sao code do AI viết vẫn cần người review?
Code do AI viết vẫn cần người review, vì AI trả lời câu hỏi "code này có chạy không" tốt hơn nhiều so với câu hỏi "code này có đúng với công ty của khách hàng không". Đoạn code đẹp, có comment, có test đi kèm vẫn có thể làm sai một quy định mà chỉ người trong nghiệp vụ mới biết.
Khách hàng của VAON hỏi thẳng chuyện này. "Code AI viết thì ai kiểm tra" là một trong ba câu họ hỏi nhiều nhất trong năm 2026. Câu trả lời tốt không phải "chúng tôi tin AI" hay "chúng tôi không dùng AI", mà là danh sách việc người làm, kèm bằng chứng là họ đã làm. Rủi ro tổng quan của code do AI sinh đã có ở bài Shadow AI và code do AI sinh, nên bài này chỉ đi vào người review nhìn vào đâu và hồ sơ nào được lưu.
2. Người review nên kiểm tra những góc nhìn nào?
Người review code do AI viết nên kiểm tra tám góc nhìn sau, vì đây là những chỗ công cụ quét và AI review thường không biết đủ ngữ cảnh để kết luận.
| Góc nhìn | Lỗi hay gặp | Câu hỏi của người review |
|---|---|---|
| Quy tắc nghiệp vụ | Code làm đúng theo cách AI đoán, không theo quy định thật (cách làm tròn, ngày chốt sổ, ngoại lệ cho khách đặc biệt) | Quy tắc này lấy từ mục nào của tài liệu yêu cầu? Ai đã xác nhận? |
| Phân quyền | Giao diện ẩn nút, nhưng API vẫn trả dữ liệu cho người không có quyền | Nếu người này gọi thẳng API thì sao? |
| Xử lý dữ liệu | Dữ liệu cá nhân bị ghi vào log, truy vấn thiếu điều kiện lọc theo người dùng hoặc đơn vị, trả thừa trường | Dữ liệu nào đi ra khỏi hệ thống hoặc vào log? |
| Thư viện, API không có thật | Tên package, tên hàm hoặc tham số do AI bịa, hoặc lấy từ phiên bản cũ | Package có trên kho chính thức không? Hàm có trong phiên bản đang dùng không? |
| Bài test vô nghĩa | Test không có phép so sánh, so sánh điều hiển nhiên, hoặc mock luôn trả đúng thứ test mong đợi | Cố ý làm code sai thì test có đỏ không? |
| Xử lý lỗi và ca biên | Nuốt lỗi rồi trả giá trị mặc định trong im lặng, không tính đến dữ liệu rỗng, trùng, truy cập đồng thời | Dữ liệu rỗng, trùng hoặc quá lớn thì chuyện gì xảy ra? |
| Thay đổi ngoài yêu cầu | AI sửa lan sang file không liên quan, đổi tên hàng loạt, xoá đoạn "thừa" mà thực ra đang được dùng | Mỗi dòng đổi có thuộc yêu cầu của thay đổi này không? |
| Khoá và cấu hình | Khoá hoặc địa chỉ môi trường thật nằm trong code mẫu và test | Có giá trị nào chỉ đúng trên máy của một người không? |
Quy tắc nghiệp vụ và phân quyền là hai nơi người review không nhường được cho máy. Công cụ quét không biết "đơn trên một mức tiền phải có quản lý duyệt" là quy định của khách hay chi tiết ngẫu nhiên. Chỉ người đọc tài liệu yêu cầu mới trả lời được.
3. Làm sao nhận ra bài test vô nghĩa và thư viện không có thật?
Người review nhận ra bài test vô nghĩa bằng cách phá code một cách cố ý, và nhận ra thư viện không có thật bằng cách tra lại tên trên kho chính thức, không tin vào lời đề xuất của AI.
Với bài test. AI thường viết test cho khớp với code vừa sinh ra, nên code sai thì test cũng chấp nhận cái sai đó. Cách kiểm tra rẻ nhất: đổi một dấu so sánh, bỏ một điều kiện, rồi chạy lại. Test vẫn xanh nghĩa là test không bảo vệ được gì. Cách phòng tốt hơn là viết kịch bản kiểm thử từ yêu cầu, thay vì để test chỉ bám vào code.
Với thư viện và API. Khi pull request thêm một package, người review mở kho chính thức xem tên có tồn tại không, ai duy trì, cập nhật lần cuối khi nào. Một tên nghe rất hợp lý vẫn có thể do AI tự nghĩ ra, và kẻ tấn công có thể đăng ký sẵn tên đó. Với hàm hoặc tham số lạ, người review mở tài liệu đúng phiên bản đang dùng, hoặc chạy thử. Đọc bằng mắt thôi chưa đủ, vì đoạn code bịa thường trông rất tự nhiên.
4. Công cụ tự động, AI và người chia việc thế nào?
Ở các dự án của VAON, công cụ tự động chặn lỗi có dấu hiệu rõ, AI rà thêm phần thay đổi, còn người quyết định phần cần hiểu ngữ cảnh. Mỗi lớp bổ sung cho lớp kia, không lớp nào thay được lớp nào.
| Lớp | Việc làm | Giới hạn |
|---|---|---|
| Cổng tự động trên mỗi pull request | Quét khoá bí mật, quét thành phần phụ thuộc, phân tích tĩnh (SAST). Nhánh chính bị khoá, chưa review thì không gộp được | Chỉ thấy lỗi có mẫu nhận dạng, không biết quy tắc nghiệp vụ |
| AI rà bảo mật phần thay đổi | Đọc phần diff và nêu điểm đáng ngờ | Có cảnh báo sai, bỏ sót có thể xảy ra |
| Người review | Đọc kết quả của hai lớp trên, rồi kiểm tra tám góc nhìn ở mục 2 | Phụ thuộc thời gian và chuyên môn của người đọc |
Hai điểm cần nói rõ. Thứ nhất, AI rà bảo mật bổ sung cho người, không thay người. Cảnh báo sai là chuyện thường, nên luôn có người đọc kết quả và quyết định. Thứ hai, khi khách hàng chưa cho phép đưa mã nguồn vào công cụ AI, bước AI rà không chạy. Dự án khi đó chỉ còn cổng tự động và người review. Quy trình bảo mật của VAON lấy khung NIST SSDF (SP 800-218) làm tài liệu tham chiếu.
5. Quy trình 7 bước của VAON để lại hồ sơ gì?
Quy trình 7 bước của VAON để lại ít nhất một dấu vết ở mỗi bước, và mọi dự án đều lưu hồ sơ review và test để khách hàng xem được. Với mỗi thay đổi, đội đi qua:
- Lập kế hoạch. Dấu vết: mô tả thay đổi và phạm vi.
- Người khác phản biện. Dấu vết: ý kiến phản biện về kế hoạch, trước khi viết dòng code nào.
- Xác nhận. Dấu vết: quyết định đi tiếp hay chỉnh lại kế hoạch.
- Xây dựng. AI hỗ trợ, người kiểm tra. Dấu vết: pull request kèm lý do thay đổi.
- Kiểm tra chéo và trưởng nhóm duyệt. Dấu vết: nhận xét review, tên người duyệt, kết quả của cổng tự động.
- Test trên môi trường riêng. Dấu vết: kịch bản kiểm thử và kết quả chạy.
- Phát hành. Dấu vết: ghi chú phát hành và tag.
Kỹ sư VAON dùng Claude Code và GitHub Copilot hằng ngày. AI đọc lại mã, sinh test và đồng bộ tài liệu, còn người kiểm tra trước khi phát hành. Bước khiến khách ngạc nhiên nhất là bước 2: phản biện diễn ra trước khi xây dựng, không phải sau, vì sửa một kế hoạch sai rẻ hơn nhiều so với sửa một pull request đã viết xong.
Với khách hàng, hồ sơ này trả lời trực tiếp câu "ai kiểm tra code AI viết": ai đã đọc thay đổi nào, test nào đã chạy, bản phát hành nào mang tag nào. Định dạng hồ sơ có thể khác nhau giữa các dự án, nên nếu khách có yêu cầu riêng về cách lưu, hãy nêu từ giai đoạn khởi động. Vòng lặp kiểm chứng khi AI tham gia kiểm thử được trình bày ở bài quy trình dùng AI trong kiểm thử.
6. Khi nào cách làm này chưa đủ?
Review của người, dù kỹ, không bắt được mọi lỗi, và có ba tình huống cần biết trước.
- Người review quá tải. AI làm lượng code tăng nhanh, còn thời gian đọc của người thì không. Pull request càng lớn, người đọc càng lướt. Cách giảm: chia nhỏ thay đổi, làm theo phần ngắn chạy được, để mỗi lần review đọc trọn vẹn.
- Người review thiếu nghiệp vụ. Yêu cầu chưa chốt bằng văn bản thì người review không có gì để đối chiếu, và hai góc nhìn đầu của mục 2 mất tác dụng.
- Bản thử bỏ đi sau vài ngày. Quy trình đầy đủ là quá nặng cho trường hợp này. Chỉ cần nói rõ đây là bản thử và không đưa lên môi trường thật.
7. Câu hỏi thường gặp
Dùng AI để review code do AI viết có đủ không? Chưa đủ. AI review hữu ích để thấy điểm đáng ngờ, nhưng có cảnh báo sai và có thể bỏ sót, nhất là các lỗi liên quan đến quy tắc nghiệp vụ và phân quyền. VAON dùng AI như một lớp bổ sung và để người đọc kết quả, rồi quyết định.
Khách hàng có xem được hồ sơ review và test không? Có. Mọi dự án của VAON đều lưu hồ sơ review và test, và khách hàng xem được. Nên thống nhất ngay từ giai đoạn khởi động nơi lưu và cách khách truy cập, để không phải tìm lại khi cần.
Nếu khách chưa cho đưa mã nguồn vào công cụ AI thì sao? Dự án vẫn chạy được, chỉ khác ở một lớp. Bước AI rà không chạy, còn quét khoá bí mật, quét thành phần phụ thuộc, phân tích tĩnh trên mỗi pull request và review của người vẫn giữ nguyên.
Người review nên bắt đầu từ đâu khi nhận một pull request lớn do AI viết? Từ mô tả thay đổi và yêu cầu liên quan, rồi đọc phần phân quyền và dữ liệu trước phần giao diện. Nếu quá lớn để đọc trọn, hãy yêu cầu chia nhỏ thay vì duyệt lướt.
Test tự động đã tốt thì có thể bỏ review của người không? Không. Test chỉ kiểm tra những gì người viết test nghĩ tới, và test do AI sinh có thể được viết cho khớp với code sai. Test và review kiểm tra hai thứ khác nhau.
Bạn đang muốn biết quy trình review của một đội phát triển có AI trông như thế nào trước khi giao việc? VAON trình bày quy trình và cho xem mẫu hồ sơ review, test trong buổi trao đổi 60 phút có CEO tham dự, không cần chuẩn bị tài liệu và không ràng buộc. Đặt lịch trao đổi 60 phút miễn phí
Đọc thêm: 12 điều cần xác nhận trước khi giao phát triển hướng AI và bảo mật AI coding theo văn bản của chính phủ Nhật.
Tài liệu tham khảo
- NIST, Secure Software Development Framework (SSDF) Version 1.1, SP 800-218, tháng 02/2022: https://csrc.nist.gov/pubs/sp/800/218/final (mở kiểm tra 17/10/2026)
