AI Code Review: Đừng để AI vừa viết code vừa tự chấm mình đúng

Có một tình huống khá thú vị khi lập trình với AI.

Chúng ta giao cho AI viết một chức năng. AI phân tích, tạo mã nguồn, chạy kiểm thử rồi thông báo: "Đã hoàn thành thành công".

Hỏi thêm một câu: "Code có lỗi gì không?"

AI xem lại và trả lời: "Mọi thứ ổn, mã nguồn tuân thủ các yêu cầu".

Nghe cũng yên tâm.

Nhưng chú Nha 27 tuổi lại có một câu hỏi khác: Nếu AI đã hiểu sai yêu cầu từ đầu, việc chính AI đó xem lại mã nguồn có phát hiện được sự hiểu sai ấy không?

Có thể có. Nhưng không có gì bảo đảm.

Đôi khi, vấn đề không nằm ở một dòng code sai cú pháp. Vấn đề nằm ở một quy tắc nghiệp vụ chưa được triển khai, một đường dẫn kiểm tra phân quyền bị bỏ sót hoặc một tình huống lỗi chưa bao giờ được đưa vào test.

Hơn 10 năm làm việc với phần mềm khiến tôi khá thận trọng với những câu khẳng định như "Đã kiểm tra, mọi thứ đều ổn".

Tôi muốn biết đã kiểm tra những gì, dựa trên yêu cầu nào, test nào đã thực sự chạy và có bằng chứng gì.

Trong các bài trước của series lập trình với AI, chúng ta đã nói về Vibe Coding, Context Engineering, AGENTS.md, Task Specification và Acceptance Criteria.

Bài này đi tiếp đến bước Review.

Chúng ta sẽ tìm hiểu cách dùng AI để kiểm tra mã nguồn, khi nào nên sử dụng một hoặc nhiều AI, cách phân biệt lỗi thật với cảnh báo sai, cách kiểm soát chi phí và điều kiện để một pull request được phép merge.

1. AI Code Review là gì?

AI Code Review là việc sử dụng mô hình AI để hỗ trợ phân tích mã nguồn hoặc những thay đổi mã nguồn, nhằm phát hiện lỗi, rủi ro và các điểm chưa phù hợp với yêu cầu của dự án.

AI có thể hỗ trợ kiểm tra:

• Logic nghiệp vụ.
• Những trường hợp ngoại lệ.
• Authentication và Authorization.
• Bảo mật dữ liệu.
• Race condition và concurrency.
• Transaction và tính toàn vẹn dữ liệu.
• API compatibility.
• Regression risks.
• Những bài kiểm thử còn thiếu.
• Những thay đổi ngoài phạm vi nhiệm vụ.

Điểm quan trọng là AI Code Review không đồng nghĩa với việc mọi kết luận của AI đều chính xác.

AI có thể bỏ sót lỗi. AI cũng có thể phát hiện nhầm một đoạn code hoàn toàn hợp lệ là vấn đề.

Vì vậy, kết quả review nên được xem là các phát hiện cần xác minh, không phải phán quyết cuối cùng.

2. Vì sao không nên chỉ để AI tự review code của mình?

Khi AI viết code, nó có thể sử dụng những giả định đã hình thành trong quá trình phân tích yêu cầu.

Nếu một giả định sai, mã nguồn có thể được xây dựng nhất quán theo giả định ấy.

Ví dụ, một AI Coding Agent được yêu cầu xử lý thanh toán cọc.

Nó tự giả định rằng khi cổng thanh toán trả về trang thành công, đơn hàng có thể chuyển sang trạng thái đã thanh toán.

Sau đó, agent viết code và test theo đúng cách hiểu này.

Khi yêu cầu chính agent đó kiểm tra lại, nó có thể tiếp tục đánh giá dựa trên giả định ban đầu.

Kết quả là code nhất quán với cách hiểu của AI, nhưng chưa chắc nhất quán với nghiệp vụ thực tế.

Đó là lý do tôi đề xuất tách hai vai trò:

• AI Coding Agent: Thực hiện nhiệm vụ theo yêu cầu được phê duyệt.
• AI Reviewer: Kiểm tra kết quả triển khai, độc lập đối chiếu với yêu cầu và tìm kiếm những trường hợp có thể gây lỗi.

Reviewer có thể là một agent riêng, một phiên làm việc độc lập hoặc một mô hình khác.

Không bắt buộc phải sử dụng hai nhà cung cấp AI.

Điều quan trọng hơn là reviewer có nhiệm vụ rõ ràng, có thể truy cập tài liệu chính thức và không chỉ dựa vào lời tóm tắt của agent đã viết code.

3. Hai AI đồng ý với nhau chưa chắc đã đúng

Đây là một điều rất dễ bỏ sót.

Chúng ta có thể yêu cầu AI thứ nhất viết code, AI thứ hai review rồi AI thứ ba xác nhận.

Nhưng nếu cả ba cùng nhận một bản mô tả nghiệp vụ thiếu rõ ràng, chúng có thể đưa ra kết luận tương tự nhau.

Ba ý kiến đồng ý không tự động trở thành ba bằng chứng độc lập.

Để tăng tính độc lập của review, tôi đề xuất:

• Reviewer đọc SRS, business rules và acceptance criteria đã được phê duyệt.
• Reviewer kiểm tra diff và phần mã nguồn có liên quan.
• Reviewer không mặc định tin rằng báo cáo hoàn thành của AI Coding Agent là chính xác.
• Reviewer được yêu cầu chủ động tìm các tình huống làm chức năng thất bại.
• Mỗi phát hiện cần có bằng chứng hoặc phương pháp kiểm chứng.
• Những phát hiện quan trọng phải được xác minh bằng code, test hoặc kiểm tra chuyên môn.

Một mô hình khác có thể đem lại góc nhìn khác. Nhưng sự độc lập nằm nhiều ở nguồn thông tin, nhiệm vụ và cách kiểm chứng hơn là tên nhà cung cấp.

4. Review theo Pull Request, đừng yêu cầu AI kiểm tra lại toàn bộ dự án

Một trong những cách làm dễ lãng phí token là đưa cả repository cho AI rồi yêu cầu "Kiểm tra toàn bộ code xem có lỗi gì không".

Với repository lớn, yêu cầu này vừa rộng vừa khó có tiêu chí kết thúc rõ ràng.

Trong quy trình phát triển thường ngày, tôi ưu tiên review theo Pull Request hoặc Merge Request.

Reviewer cần biết:

• Mục tiêu của thay đổi.
• Task ID và yêu cầu liên quan.
• Branch hoặc commit được kiểm tra.
• Những file đã thay đổi.
• Business rules có ảnh hưởng.
• Acceptance criteria.
• Test đã chạy và kết quả.

Reviewer bắt đầu từ diff, sau đó mở rộng sang những phần mã nguồn liên quan khi cần.

Chẳng hạn, nếu một API thay đổi cách kiểm tra quyền, cần đọc middleware, authorization policy hoặc các service đang gọi API đó.

Không nên chỉ nhìn vài dòng diff rồi kết luận không có vấn đề.

Nhưng cũng không cần đọc những module hoàn toàn không liên quan nếu không có dấu hiệu phụ thuộc.

5. Quy trình AI Code Review gồm sáu bước

Tôi đề xuất một quy trình sáu bước, có thể áp dụng với GitHub, GitLab hoặc repository nội bộ.

Bước 1 - Coding Agent hoàn thành task

Agent triển khai code theo Task Specification và tạo báo cáo thay đổi.

Báo cáo cần nêu rõ những test đã chạy, kết quả và những phần chưa kiểm chứng.

Bước 2 - CI thực hiện kiểm tra tự động

Hệ thống CI chạy build, lint, static analysis, unit tests và những kiểm tra có thể tự động hóa.

Không nên giao cho AI làm lại những công việc mà công cụ kiểm tra xác định có thể thực hiện nhanh và ổn định hơn.

Bước 3 - AI Reviewer kiểm tra diff và yêu cầu

Reviewer đọc Task Specification, Acceptance Criteria và những phần mã nguồn liên quan.

Trọng tâm là tính đúng đắn, bảo mật, toàn vẹn dữ liệu và ảnh hưởng đến hành vi hiện tại.

Bước 4 - Xác minh các phát hiện

Mỗi cảnh báo cần được xem xét.

Nếu reviewer phát hiện một tình huống có thể gây lỗi, hãy kiểm tra điều kiện xảy ra và cố gắng tạo test có khả năng tái hiện vấn đề.

Bước 5 - Coding Agent sửa những lỗi đã xác nhận

Không nên đưa toàn bộ nhận xét của AI Reviewer trở lại cho Coding Agent rồi yêu cầu "Sửa hết" mà chưa phân loại.

Chỉ những phát hiện hợp lệ, phù hợp phạm vi và đã được xác nhận theo quy trình mới nên trở thành yêu cầu sửa.

Bước 6 - Human Review và quyết định merge

Người có thẩm quyền kiểm tra những thay đổi cuối cùng, kết quả CI, vấn đề còn tồn đọng và điều kiện nghiệm thu.

Với hệ thống quan trọng, quyền merge vẫn cần tuân thủ branch protection và quy trình phê duyệt.

APPROVED TASK       |       v AI CODING AGENT       |       v PULL REQUEST       |       v CI / STATIC ANALYSIS / TESTS       |       v AI CODE REVIEW       |       v VERIFY FINDINGS       |       +---- Invalid Finding       |          |       |          v       |       Document       |       +---- Confirmed Bug                  |                  v               FIX CODE                  |                  v            RE-RUN TESTS                  |                  v            HUMAN REVIEW                  |                  v            MERGE / NO MERGE

6. Năm nhóm rủi ro nên ưu tiên khi review

Nhóm 1 - Business Logic

Đây là nhóm tôi muốn đặt lên trước, nhất là với phần mềm xử lý nghiệp vụ.

Reviewer cần tìm những tình huống chức năng hoạt động khác với quy tắc được phê duyệt.

Ví dụ:

• Thanh toán thành công được ghi nhận sai thời điểm.
• Giảm giá được áp dụng sai thứ tự.
• Đơn hàng bị hủy vẫn có thể giao dịch.
• Nhân viên có thể phê duyệt giao dịch của chính mình trái quy định.

Nhóm 2 - Security

Kiểm tra những rủi ro như kiểm soát truy cập sai, injection, dữ liệu nhạy cảm bị lộ hoặc cấu hình không an toàn.

Đặc biệt chú ý các đường dẫn API mới, chức năng quản trị, xử lý file và tích hợp bên ngoài.

Nhóm 3 - Data Integrity

Kiểm tra transaction, idempotency, ràng buộc dữ liệu, xử lý đồng thời và các tình huống cập nhật thất bại.

Đối với hệ thống thanh toán, nhóm này có thể ảnh hưởng trực tiếp đến tiền và dữ liệu khách hàng.

Nhóm 4 - Regression

Kiểm tra xem thay đổi mới có làm hỏng một hành vi đang hoạt động đúng hay không.

Ví dụ, việc thêm một điều kiện lọc có khiến những API khác trả thiếu dữ liệu?

Nhóm 5 - Test Gaps

Reviewer nên chỉ ra những trường hợp quan trọng chưa được kiểm thử.

Nhưng thiếu một bài test không tự động chứng minh code có lỗi. Cần phân biệt rủi ro chưa được kiểm chứng với lỗi đã xác nhận.

7. Phân loại mức độ nghiêm trọng của phát hiện

Cần có một cách phân loại nhất quán để nhóm phát triển không mất thời gian xử lý những vấn đề ít quan trọng trước các lỗi nghiêm trọng.

Tôi đề xuất một hệ thống bốn mức mang tính nội bộ:

• P0 - Critical: Nguy cơ gây thiệt hại nghiêm trọng như lộ dữ liệu diện rộng, mất dữ liệu không thể phục hồi hoặc xử lý tiền sai nghiêm trọng.
• P1 - High: Lỗi có thể ảnh hưởng trực tiếp đến nghiệp vụ quan trọng, bảo mật hoặc tính toàn vẹn dữ liệu.
• P2 - Medium: Lỗi có ảnh hưởng thực tế nhưng có giới hạn, hoặc rủi ro cần bổ sung biện pháp kiểm soát.
• P3 - Low: Những cải tiến ít ảnh hưởng đến tính đúng đắn, chẳng hạn khả năng bảo trì hoặc một số trường hợp nhỏ.

Đây không phải hệ thống mức độ nghiêm trọng thống nhất của mọi công cụ AI.

Tổ chức có thể sử dụng một hệ thống phân loại khác. Điều quan trọng là cả nhóm hiểu giống nhau về ý nghĩa, cách xử lý và điều kiện chặn merge.

8. Prompt mẫu cho AI Code Reviewer

Đây là prompt tôi đề xuất cho một phiên reviewer độc lập.

ROLE: Independent Senior Code Reviewer

OBJECTIVE: Review the current Pull Request against approved requirements.

INPUT:
- Task Specification
- Acceptance Criteria
- Business Rules
- PR Diff
- Relevant Source Code
- CI / Test Results

REVIEW PRIORITIES:
1. Business Logic
2. Authorization
3. Data Integrity
4. Security
5. Regression
6. Missing Critical Tests

RULES:
- Do not trust the author's summary

without checking evidence.
- Do not modify source code.
- Do not invent business rules.
- Do not report style preferences

as functional bugs.
- Do not assume unverified issues

are confirmed vulnerabilities.
- Inspect relevant surrounding code

before reporting an issue.
- Avoid duplicate findings.

FOR EACH FINDING:
- Finding ID
- Severity
- File and line reference
- Triggering condition
- Expected behavior
- Actual or potential behavior
- Evidence
- How to reproduce
- Recommended fix
- Confidence and verification status

CLASSIFY:
- Confirmed
- Likely / Needs Verification
- Not Reproducible
- Informational

FINAL OUTPUT:
- Review Summary
- Confirmed Findings
- Unverified Risks
- Missing Critical Tests
- Merge Blockers
- Questions for Human Review

Do not claim the PR is safe just because no findings were found.

Nếu công cụ có chế độ review chỉ đọc, nên sử dụng chế độ đó để hạn chế nguy cơ reviewer vô tình chỉnh sửa mã nguồn trong khi kiểm tra.

9. Ví dụ review một chức năng thanh toán cọc

Giả sử AI Coding Agent vừa tạo chức năng xử lý callback thanh toán.

Trong một ví dụ đơn giản hóa, đoạn code mới có dạng:

public async Task HandleCallback(

PaymentCallback callback) {

var order = await repository

.GetOrderAsync(callback.OrderId);

if (callback.Status == "SUCCESS")

{

order.PaymentStatus = "PAID";

await repository

.SaveChangesAsync();

} }

Nhìn qua, đoạn code khá dễ hiểu.

Nhưng AI Reviewer cần đặt thêm những câu hỏi:

• Callback đã được xác thực từ nhà cung cấp thanh toán chưa?
• Callback có thuộc đúng merchant và giao dịch không?
• Số tiền, loại tiền và trạng thái có khớp yêu cầu thanh toán không?
• Callback trùng lặp được xử lý như thế nào?
• Đơn hàng đã hủy có thể bị chuyển lại thành đã thanh toán không?
• Hệ thống có ghi lại sự kiện thanh toán để đối soát không?
• Nếu order không tồn tại thì xử lý ra sao?

Đây là những điểm cần kiểm tra, không phải kết luận rằng đoạn code trên chắc chắn đã thiếu tất cả biện pháp bảo vệ.

Ví dụ, bước xác thực callback có thể đã được thực hiện ở middleware hoặc thành phần xử lý bên ngoài.

Reviewer phải đọc đúng phạm vi mã nguồn trước khi đưa ra kết luận.

Một finding tốt nên được viết như thế nào?

Finding ID: REV-PAY-001

Severity: P1
- High

Location: PaymentCallbackHandler

Observation: The handler updates payment status based on callback.Status.

Potential Risk: An unverified callback could cause an incorrect payment state if verification is absent elsewhere.

Verification Needed: Inspect the callback authentication and payment reconciliation flow.

Expected Behavior: Only authenticated, validated payment events can change the order payment status.

Suggested Test: Submit an invalid callback and verify the order state remains unchanged.

Status: Needs Verification

Finding này xác định được vị trí, điều kiện rủi ro, hành vi mong muốn và cách xác minh.

Nếu kiểm tra hệ thống cho thấy callback đã được xác thực đầy đủ ở lớp khác, reviewer cần cập nhật hoặc đóng finding.

Không nên giữ một cảnh báo sai chỉ vì nó do AI phát hiện.

10. Cách xử lý khi hai AI đưa ra kết luận khác nhau

Giả sử AI Reviewer A cho rằng một đoạn code có race condition.

Reviewer B lại cho rằng đoạn code an toàn vì database đã có unique constraint.

Nên tin ai?

Tôi sẽ không chọn theo tên mô hình.

Hãy quay lại bằng chứng:

• Unique constraint có thật sự tồn tại trong schema đang sử dụng không?
• Nó ngăn được dạng trùng lặp nào?
• Logic kiểm tra và ghi dữ liệu có diễn ra trong transaction phù hợp không?
• Có tình huống thao tác đồng thời vẫn gây ra trạng thái không nhất quán không?
• Có thể tạo integration test để kiểm chứng không?

Một unique constraint có thể ngăn dữ liệu trùng trong một bảng, nhưng chưa chắc ngăn mọi vấn đề liên quan đến xử lý đồng thời hoặc tác động bên ngoài.

Ngược lại, không phải cứ thấy hai request cùng chạy là có lỗi race condition.

Chúng ta cần kiểm tra điều kiện cụ thể.

Khi hai AI bất đồng, hãy biến bất đồng thành một giả thuyết có thể kiểm chứng, thay vì tiếp tục hỏi thêm nhiều AI để bỏ phiếu.

11. Không phải task nào cũng cần hai hoặc ba AI Reviewer

Đây là phần quan trọng nếu muốn kiểm soát chi phí.

Việc dùng nhiều AI không miễn phí. Mỗi lần review có thể cần đọc diff, tài liệu, mã nguồn liên quan và kết quả kiểm thử.

Tôi đề xuất chia mức kiểm tra theo rủi ro.

Low Risk - Một lớp review phù hợp

Ví dụ: Sửa câu chữ, thay đổi giao diện nhỏ hoặc cập nhật nội dung không liên quan đến dữ liệu và quyền truy cập.

Có thể sử dụng CI, kiểm tra của người phát triển và một lượt AI Review nếu cần.

Medium Risk - Review tập trung

Ví dụ: Thay đổi form, thêm một API nghiệp vụ hoặc chỉnh sửa một luồng có ảnh hưởng đến dữ liệu.

Nên chạy CI đầy đủ, AI Review tập trung vào những phần thay đổi và kiểm tra thủ công theo acceptance criteria.

High Risk - Review độc lập và kiểm thử chuyên sâu

Ví dụ: Thanh toán, hoàn tiền, phân quyền, dữ liệu cá nhân, database migration hoặc hệ thống có mức độ quan trọng cao.

Nên sử dụng reviewer độc lập, kiểm thử chuyên sâu, đánh giá bảo mật khi cần và yêu cầu người có chuyên môn phê duyệt.

Một AI thứ hai có thể hữu ích khi cần góc nhìn bổ sung cho rủi ro cao.

Nhưng không nhất thiết mọi thay đổi đều phải được kiểm tra bằng nhiều mô hình.

12. Cách giảm token khi sử dụng AI Code Review

Muốn giảm chi phí, đừng bắt đầu bằng việc tìm mô hình rẻ nhất.

Hãy kiểm tra xem reviewer đang đọc những gì và làm những công việc nào.

Chỉ review thay đổi có liên quan

Ưu tiên bắt đầu từ PR diff, Task Specification và những tài liệu liên quan.

Chỉ mở rộng sang phần mã nguồn khác khi cần hiểu dependency hoặc hành vi.

Để CI xử lý các kiểm tra xác định

Lint, formatter, type checking và nhiều loại static analysis có thể chạy bằng công cụ chuyên dụng.

Không cần tiêu tốn token để AI tranh luận về những lỗi mà compiler đã chỉ ra rõ ràng.

Không review lại toàn bộ khi chỉ sửa một finding nhỏ

Có thể thực hiện review bổ sung tập trung vào phần thay đổi và những đường dẫn bị ảnh hưởng.

Với thay đổi quan trọng hoặc phụ thuộc rộng, vẫn cần regression test và review mở rộng phù hợp.

Không sử dụng nhiều reviewer theo thói quen

Chỉ bổ sung một reviewer khác khi có lý do, chẳng hạn rủi ro cao, phát hiện mâu thuẫn hoặc cần chuyên môn đánh giá riêng.

Loại bỏ finding trùng lặp

Nếu ba agent cùng phát hiện một lỗi, hãy hợp nhất thành một finding có đủ bằng chứng.

Không cần tạo ba ticket chỉ vì có ba người nhận xét.

Đo tổng chi phí, không chỉ token

Chi phí review nên bao gồm thời gian review, chi phí model, thời gian xác minh false positive và thời gian sửa lỗi.

Một lượt review rẻ nhưng tạo ra quá nhiều cảnh báo sai có thể khiến tổng chi phí cao hơn.

13. Có nên tạo một file REVIEW.md riêng?

Có thể, nhất là khi nhóm phát triển có những quy tắc review ổn định.

Ví dụ:

# Code Review Policy

## Review
Priorities
1. Correctness
2. Authorization
3. Data integrity
4. Security
5. Regression
6. Critical test gaps

## Required
Evidence

For every finding:
- File and location
- Triggering condition
- Expected behavior
- Actual or potential behavior
- Evidence or reproduction plan
- Severity
- Verification status

## Rules
- Do not report formatting issues

already covered by CI.
- Do not duplicate findings.
- Do not invent business rules.
- Do not infer vulnerabilities

without reviewing related code.
- Mark unverified risks clearly.
- Avoid unrelated refactoring.

## Merge
Guidance

P0/P1 issues must be evaluated and resolved before approval.

Human reviewers own the final merge decision.

Tuy nhiên, cần phân biệt file hướng dẫn nội bộ với file được một công cụ hỗ trợ tự động.

Một số nền tảng Code Review có cơ chế đọc REVIEW.md, nhưng không nên mặc định mọi AI Coding Agent đều nhận diện file này.

Nếu công cụ không hỗ trợ, có thể đưa nội dung review policy vào project instructions hoặc cung cấp file theo cách công cụ cho phép.

14. Cách áp dụng với Codex, Claude Code và GitHub

OpenAI Codex

Codex hỗ trợ review thay đổi mã nguồn cục bộ và các pull request trong những môi trường tương thích.

Với Git repository, có thể sử dụng chế độ review được cung cấp trong ứng dụng, CLI hoặc IDE để kiểm tra diff.

Đối với GitHub, Codex cũng có cơ chế yêu cầu review pull request thông qua tích hợp tương ứng khi đã được cấu hình.

Không nên mặc định rằng mọi tài khoản hoặc repository đều có cùng tính năng. Hãy kiểm tra khả năng và quyền truy cập thực tế.

Claude Code

Claude Code có thể được yêu cầu phân tích mã nguồn và kiểm tra những thay đổi.

Anthropic cũng cung cấp cơ chế Code Review dành cho những tổ chức và gói dịch vụ đủ điều kiện, sử dụng nhiều agent chuyên trách để tìm lỗi.

Các tính năng, giới hạn và chi phí có thể thay đổi. Cần kiểm tra tài liệu chính thức trước khi áp dụng vào quy trình của nhóm.

GitHub

GitHub Pull Request cung cấp một nơi để tập hợp diff, review comments, kết quả CI và trạng thái phê duyệt.

Dù sử dụng AI nào, nên giữ các bằng chứng review và quyết định merge trong hệ thống quản lý mã nguồn thay vì chỉ để trong lịch sử chat.

Với các repository quan trọng, hãy sử dụng branch protection, required checks và quy trình phê duyệt phù hợp.

15. Mẫu báo cáo AI Code Review

Một báo cáo tốt cần ngắn gọn ở phần tổng quan, chi tiết ở phần bằng chứng.

# AI Code Review Report

## Pull
Request PR: Task: Base Branch: Commit: Reviewed At:

## Summary
Change Description: Risk Level: Review Scope:

## Verification
Build: Unit Tests: Integration Tests: Security Checks:

## Findings
### REV-001
Severity: Status: File: Location: Trigger: Expected: Observed: Evidence: Reproduction: Recommended Fix:

## Missing
Verification
- ...

## Out-of-Scope
Changes
- ...

## Open
Questions
- ...

## Merge
Assessment GO / NO-GO / NEEDS REVIEW

## Human
Decision Pending

Không nên cho phép báo cáo tự động đánh dấu GO chỉ vì AI không tìm thấy lỗi.

GO hoặc NO-GO cần dựa trên quy trình phê duyệt thực tế và mức rủi ro của thay đổi.

16. Checklist 15 mục trước khi yêu cầu AI Code Review

1. Đã xác định đúng pull request, branch hoặc commit chưa?
2. Task Specification có sẵn chưa?
3. Acceptance Criteria đã được phê duyệt chưa?
4. Business Rules có thể truy cập chưa?
5. Reviewer có quyền đọc đúng mã nguồn cần thiết chưa?
6. Đã xác định phạm vi review chưa?
7. Đã biết những module liên quan chưa?
8. Đã có kết quả build chưa?
9. Đã có kết quả unit test chưa?
10. Đã có kết quả integration test nếu cần chưa?
11. Đã xác định mức rủi ro của thay đổi chưa?
12. Đã có quy tắc phân loại finding chưa?
13. Đã quy định reviewer không tự sửa code chưa?
14. Đã có định dạng báo cáo và yêu cầu bằng chứng chưa?
15. Đã xác định người chịu trách nhiệm xác minh và quyết định merge chưa?

17. Checklist 15 mục sau khi AI Code Review

1. Reviewer đã đọc đúng diff cần kiểm tra chưa?
2. Các phát hiện có vị trí mã nguồn cụ thể chưa?
3. Các phát hiện có điều kiện xảy ra rõ ràng chưa?
4. Đã phân biệt lỗi xác nhận và rủi ro chưa xác minh chưa?
5. Đã kiểm tra những phần mã nguồn phụ thuộc chưa?
6. Đã đối chiếu business rules chưa?
7. Đã kiểm tra authorization chưa?
8. Đã kiểm tra dữ liệu và transaction chưa?
9. Đã kiểm tra những tình huống ngoại lệ chưa?
10. Đã kiểm tra rủi ro regression chưa?
11. Đã loại bỏ cảnh báo trùng lặp chưa?
12. Đã xác minh false positive chưa?
13. Đã tạo test cho những lỗi được xác nhận khi phù hợp chưa?
14. Đã chạy lại các bước kiểm tra sau khi sửa lỗi chưa?
15. Đã có người phê duyệt quyết định merge chưa?

18. Một sai lầm khác: AI Review càng nhiều càng tốt

Có những nhóm sẽ muốn dùng nhiều AI để kiểm tra mọi pull request.

Tôi hiểu sự hấp dẫn của cách làm này. Khi đã có công cụ tự động, chúng ta dễ nghĩ rằng thêm một lượt review sẽ giúp an toàn hơn.

Nhưng review cũng có chi phí.

Chi phí không chỉ là token. Nó còn là thời gian xác minh nhận xét, chỉnh sửa code và chạy lại kiểm thử.

Thêm nhiều reviewer mà không phân vai có thể chỉ tạo ra nhiều báo cáo giống nhau.

Thay vì vậy, chúng ta nên giao những nhiệm vụ khác nhau:

• Reviewer chính: Kiểm tra logic và ảnh hưởng của thay đổi.
• Reviewer bảo mật: Tập trung vào các đường dẫn nhạy cảm khi rủi ro yêu cầu.
• Reviewer dữ liệu: Kiểm tra transaction, concurrency và tính toàn vẹn khi có thay đổi liên quan.

Những vai trò này có thể được thực hiện bởi một hoặc nhiều agent, tùy độ phức tạp và chi phí.

Không cần tạo ba agent chỉ để trông quy trình có vẻ đầy đủ.

19. AI Code Review cần nằm trong quy trình phát triển, không đứng riêng

Kết nối lại những bài viết trước, chúng ta có một chuỗi công việc như sau:

HUMAN + AI RESEARCH
        | v APPROVED BRD / SRS
        | v BUSINESS RULES
        | v TASK SPECIFICATION
        | v AI CODING AGENT
        | v PULL REQUEST
        | v CI / AUTOMATED TESTS
        | v AI CODE REVIEW
        | v FINDING VERIFICATION
        | v HUMAN REVIEW
        | v MERGE
        | v RELEASE CHECKLIST
        | v GO-LIVE

Trong quy trình này, AI hỗ trợ nhiều công đoạn.

Nhưng trách nhiệm đối với yêu cầu, dữ liệu, bảo mật và quyết định triển khai vẫn cần được xác định rõ cho con người và tổ chức vận hành.

Tôi đã chia sẻ bộ 150 checklist trước và sau Vibe Coding, trước khi Go-live Website dưới dạng Google Sheets để mọi người có thể sử dụng lại.

Tạo bản sao miễn phí bộ 150 checklist Vibe Coding và Website Go-live

Bộ checklist này không thay thế code review, nhưng có thể giúp nhóm phát triển kiểm soát những hạng mục quan trọng trước khi đưa sản phẩm vào sử dụng thực tế.

20. Kết luận: AI tìm lỗi, con người cần bằng chứng

Với chú Nha 27 tuổi, AI Code Review là một bước phát triển hợp lý khi AI ngày càng tham gia nhiều hơn vào việc tạo mã nguồn.

AI có thể giúp chúng ta viết code nhanh hơn, nhưng sản lượng code tăng cũng đồng nghĩa với việc cần kiểm tra nhiều thay đổi hơn.

Điều tôi muốn giữ lại trong quy trình là một nguyên tắc đơn giản:

Không đánh giá mã nguồn chỉ bằng lời khẳng định. Hãy đánh giá bằng yêu cầu, bằng chứng và kết quả kiểm thử.

AI Reviewer không cần chứng minh nó thông minh hơn AI Coding Agent.

Nó chỉ cần giúp chúng ta nhìn thấy những rủi ro có thể bị bỏ sót, đưa ra cách kiểm chứng và làm cho quyết định kỹ thuật có cơ sở hơn.

Đôi khi một reviewer độc lập là đủ. Đôi khi cần nhiều lớp kiểm tra hơn. Tùy vào mức độ rủi ro của hệ thống.

Nhưng dù sử dụng bao nhiêu AI, đừng biến số lượng lời nhận xét thành thước đo chất lượng.

Một finding được xác minh và sửa đúng có giá trị hơn mười cảnh báo không có bằng chứng.

Và nếu một ngày nào đó AI Coding Agent hỏi chú Nha: "Em viết xong rồi, anh có tin em không?", có lẽ chú sẽ trả lời:

"Tin chứ. Nhưng cho anh xem test trước đã!"

Nguồn tham khảo

• OpenAI - Review Pull Requests with Codex
• OpenAI - Code Review Documentation
• OpenAI - Codex Review on GitHub
• Anthropic - Set Up Code Review for Claude Code
• GitHub - Reviewing Changes in Pull Requests
• OWASP - Code Review Guide
• OWASP - Application Security Verification Standard