Review code AI qua 3 lớp: ai đọc trước, ai quyết merge
Tóm tắt: Ở các dự án VAON áp dụng quy trình 10 bước, mỗi pull request đi qua ba lớp review theo thứ tự cố định. Người viết tự đọc lại, AI đọc theo tiêu chí của dự án, rồi một kỹ sư khác duyệt và trưởng nhóm quyết merge. Nhánh chính bị khoá, và khách xem được hồ sơ review.
Mục lục
- Ba lớp review pull request là gì, và vì sao thứ tự quan trọng?
- Vì sao người viết phải tự review trước khi gọi AI?
- AI review làm tốt gì, và vì sao không phải lớp cuối?
- Người review thứ hai và trưởng nhóm chịu trách nhiệm gì?
- Bạn xem được hồ sơ review nào?
- Khi nào ba lớp review chưa đủ?
- Câu hỏi thường gặp
1. Ba lớp review pull request là gì, và vì sao thứ tự quan trọng?
Ba lớp review pull request ở VAON là ba lần đọc cùng một thay đổi. Mỗi lần do một bên khác, với một mục đích khác. Pull request (PR) là yêu cầu gộp một thay đổi mã vào nhánh chính.
Thứ tự là: tự review, AI review, người thứ hai duyệt. Thứ tự này đi từ người hiểu ngữ cảnh nhất tới người có thời gian quý nhất. Mỗi lớp dọn bớt việc cho lớp sau. Nhờ vậy lớp cuối dồn sức vào câu hỏi khó nhất: mã có đúng nghiệp vụ không.
| Lớp | Ai làm | Giỏi ở | Yếu ở | Để lại gì |
|---|---|---|---|---|
| 1. Tự review | Người tạo PR | Biết task định làm gì, thấy file bị sửa ngoài phạm vi | Khó thấy điểm mù của chính mình | Mô tả PR, lý do thay đổi |
| 2. AI review | Claude, theo tiêu chí của dự án | Đọc đều tay mọi dòng, bắt lỗi theo mẫu | Có cảnh báo sai, có thể bỏ sót, không biết ý đồ nghiệp vụ | Nhận xét lưu ngay trong PR để người lọc |
| 3. Người thứ hai | Một kỹ sư khác; trưởng nhóm quyết merge | Đối chiếu với đặc tả, nhìn thiết kế | Thời gian có hạn, dễ lướt khi PR lớn | Nhận xét review, tên người duyệt |
Ba lớp review là một bước trong quy trình phát triển với Claude Code. VAON đang áp dụng quy trình này cho phần lớn dự án, chưa phải tất cả. Hai việc chạy ở mọi dự án: khoá nhánh chính và lưu hồ sơ review, test cho khách xem.
2. Vì sao người viết phải tự review trước khi gọi AI?
Người tạo pull request tự review trước vì họ là người duy nhất biết thay đổi này định làm gì. Với mã do Claude Code viết, đây thường là lần đầu một người đọc trọn vẹn thay đổi đó.
Câu hỏi của lớp này rất đơn giản: tôi có giải thích được từng đoạn không? Đoạn nào người tạo PR không giải thích được thì chưa nên đi tiếp. Gọi AI review lúc đó chỉ sinh thêm nhận xét cho một đoạn mã chưa ai hiểu.
Lớp tự review còn bắt một kiểu lỗi hay gặp khi AI viết mã: sửa nhiều hơn yêu cầu. Ví dụ minh hoạ: AI tiện tay sửa thêm một file dùng chung "cho gọn". Người tạo PR thấy ngay, vì họ biết phạm vi task.
Test đi cùng PR cũng được đọc ở lớp này. Cách kỹ sư đọc test do AI viết có ở bài test do AI sinh đi cùng pull request.
3. AI review làm tốt gì, và vì sao không phải lớp cuối?
AI review đứng ở lớp thứ hai vì AI đọc nhanh và không mệt, nhưng chỉ hữu ích khi có tiêu chí cụ thể. Ở VAON, Claude đọc thay đổi theo bộ tiêu chí review của dự án, không theo một câu lệnh chung kiểu "review giúp tôi".
AI làm tốt những việc người hay bỏ sót khi mệt. Một exception bị bắt rồi bỏ qua. Một endpoint mới thiếu kiểm tra quyền. Một hàm gọi tới API không tồn tại. Các điểm người cần kiểm trong mã AI có ở bài review code do AI viết: kiểm tra gì.
AI review không phải lớp cuối vì hai lý do. AI có cảnh báo sai, nên cần người lọc. AI cũng có thể bỏ sót, nhất là lỗi nghiệp vụ: mã đúng kỹ thuật nhưng làm sai điều đặc tả yêu cầu.
Đặt AI trước người thứ hai có một lợi ích rõ. Lỗi lặt vặt được dọn trước, nên thời gian của người review dành cho phần chỉ người làm được.
4. Người review thứ hai và trưởng nhóm chịu trách nhiệm gì?
Người review thứ hai chịu trách nhiệm đối chiếu thay đổi với đặc tả, còn trưởng nhóm chịu trách nhiệm quyết định merge. Đây là lớp có tên người đứng sau quyết định.
Người thứ hai không viết mã này, nên không mang cùng giả định với người tạo PR. Họ dễ thấy chỗ cả người tạo lẫn AI cùng bỏ qua. Ví dụ minh hoạ: đặc tả nói đơn huỷ sau khi giao chỉ được hoàn một phần. Mã hoàn toàn bộ vẫn chạy. Test vẫn xanh nếu test viết theo mã. Chỉ người đã đọc đặc tả mới thấy sai.
Quy tắc "chưa duyệt thì không merge" được máy giữ, không trông vào ý thức từng người. Trên GitHub, tính năng bảo vệ nhánh cho phép bắt buộc pull request có đủ số lượt duyệt trước khi merge. Khi bật, không có người duyệt thì không merge được, kể cả lúc gấp.
5. Bạn xem được hồ sơ review nào?
Mọi dự án VAON đều lưu hồ sơ review và test, và khách xem được. Với mỗi pull request, hồ sơ cho thấy:
- Thay đổi gì và vì sao (mô tả PR).
- Nhận xét review và cách xử lý từng nhận xét.
- Tên người duyệt và người quyết merge.
- Kết quả cổng tự động: quét secret, quét thư viện phụ thuộc, phân tích tĩnh.
Năm 2026, "Code AI viết thì ai kiểm tra?" là một trong ba câu khách hỏi VAON nhiều nhất. Chúng tôi học được rằng tên công cụ không trả lời câu này. Thứ trả lời được là một pull request thật, mở ra thấy ai đã đọc, ai đã duyệt, cổng nào đã chạy. CTO và Tech Lead tham gia mọi dự án, nên luôn có người đủ thẩm quyền giải thích một quyết định merge.
Định dạng hồ sơ có thể khác giữa các dự án. Nếu bạn cần cách lưu riêng, hãy nêu từ giai đoạn khởi động. Trước khi phát hành, phiên bản còn qua một cổng riêng, trình bày ở bài kiểm tra bảo mật trước phát hành cho mã AI.
6. Khi nào ba lớp review chưa đủ?
Ba lớp review giảm lỗi lọt, nhưng VAON không coi chúng là bảo đảm không có lỗi. Có ba trường hợp bạn nên biết trước.
- Khách chưa cho phép đưa mã vào AI. Lớp AI review không chạy. Còn lại tự review, người thứ hai và cổng tự động.
- Pull request quá lớn. Người đọc sẽ lướt. Cách giảm là chia thay đổi nhỏ, để mỗi PR đọc được trọn vẹn.
- Đặc tả chưa chốt. Người thứ hai không có gì để đối chiếu, nên lớp 3 mất phần giá trị lớn nhất.
Với thay đổi rất nhỏ, như sửa một dòng chữ, các bước trước đó được rút gọn. Nhánh chính vẫn khoá, cổng tự động vẫn chạy. Review cũng không thay kiểm thử nghiệm thu: bạn vẫn kiểm theo checklist trước khi nhận bàn giao.
7. Câu hỏi thường gặp
AI review có thay được người review không? Không. AI review ở VAON là lớp bổ sung, không thay người. AI đọc nhanh theo tiêu chí của dự án, nhưng có cảnh báo sai và có thể bỏ sót lỗi nghiệp vụ. Vì vậy kết quả AI review luôn có người lọc. Quyết định merge thuộc về trưởng nhóm, sau khi một kỹ sư khác đã duyệt.
Nếu tôi không cho đưa mã vào công cụ AI thì review thế nào? Khi bạn chưa cho phép, VAON không đưa mã vào công cụ AI và lớp AI review không chạy. Pull request vẫn qua tự review, một kỹ sư khác duyệt và trưởng nhóm quyết merge. Cổng tự động trên mỗi PR vẫn chạy, nhánh chính vẫn khoá. Phạm vi dùng AI được thống nhất trước khi dự án bắt đầu.
Tôi xem hồ sơ review ở đâu? Mọi dự án VAON đều lưu hồ sơ review và test, và bạn xem được. Mã có thể đặt trên kho của bạn ngay từ đầu. Bạn thấy mô tả thay đổi, nhận xét review, tên người duyệt và kết quả cổng tự động của từng pull request. Nếu cần định dạng riêng cho kiểm toán nội bộ, hãy nêu từ giai đoạn khởi động.
Ba lớp review có làm dự án chậm hơn không? Mỗi pull request tốn thêm thời gian đọc. Đổi lại, lỗi được bắt khi còn nằm trong một thay đổi nhỏ, chưa trộn với phần khác. Thứ tự ba lớp giúp giảm lãng phí. Người viết và AI dọn lỗi trước, người thứ hai tập trung vào nghiệp vụ. VAON không hứa một con số tiết kiệm thời gian.
Lỗi lọt qua cả ba lớp thì ai chịu trách nhiệm? Trách nhiệm được xác định theo hợp đồng từng dự án. VAON không coi việc "AI viết" là lý do để trách nhiệm khác đi. Mã do AI viết qua cùng các bước review và test như mã do người viết. Khi có sự cố, hồ sơ review cho hai bên biết thay đổi nào gây lỗi, ai đã duyệt và cổng nào đã chạy.
Việc làm được ngay: xin đội phát triển của bạn mở một pull request đã merge gần đây và chỉ ra ba thứ. Ai đã tự đọc lại, nhận xét nào của AI bị bỏ qua và vì sao, ai bấm duyệt. Nếu không ai chỉ ra được, review đang dựa vào trí nhớ chứ chưa có hồ sơ.
Nếu muốn xem ba lớp review áp vào dự án của bạn thế nào, đặt lịch trao đổi 60 phút miễn phí. CEO tham dự, không cần chuẩn bị tài liệu, không ràng buộc.
