Review code AI sinh ra

Khi tự code bằng tay, bạn thường kiểm soát trong lúc viết: viết một hàm, nghĩ qua nhánh lỗi, chạy thử, sửa tiếp. Khi dùng Claude Code, nhịp đó đổi hẳn. AI có thể sửa 12 file, thêm 800 dòng, đổi test, đổi cấu hình trong vài phút. Tốc độ này hữu ích, nhưng nó tạo một rủi ro mới: bạn bị đẩy vào vai người duyệt một khối diff lớn mà mình chưa kịp hiểu.

• ▸Vấn đề không phải AI viết nhanh; vấn đề là con người mất nhịp kiểm soát nếu không có quy trình.
• ▸Không merge code chỉ vì nó chạy và AI nói “đã xong”.
• ▸Mục tiêu review: hiểu đủ để chịu trách nhiệm, sửa tiếp, rollback và vận hành khi AI không còn ở đó.

Đừng mở diff lớn rồi đọc từ trên xuống ngay. Trước hết, bắt AI lập một bản đồ thay đổi. Bản đồ này giúp bạn biết đang kiểm cái gì, rủi ro nằm ở đâu, và nên đọc file nào trước. Nếu chưa quen cách Claude đọc/sửa file và chạy lệnh, xem lại bài Đọc, sửa code & chạy lệnh an toàn.

Trước khi tôi đọc diff, hãy tóm tắt thay đổi theo mẫu:

1. Mục tiêu ban đầu của task là gì?
2. File nào đã đổi, mỗi file đổi để làm gì?
3. Luồng người dùng hoặc API nào bị ảnh hưởng?
4. Rủi ro lớn nhất của thay đổi này là gì?
5. Test/build/lệnh nào đã chạy, kết quả ra sao?
6. Phần nào bạn chưa chắc và muốn con người kiểm kỹ?

• ▸Mục tiêu: thay đổi có đúng việc được giao không, hay AI tự mở rộng phạm vi?
• ▸File đổi: có file nào lạ, cấu hình nào bị đụng, migration nào xuất hiện không?
• ▸Rủi ro: dữ liệu, phân quyền, thanh toán, xoá/sửa hàng loạt, caching, concurrency.
• ▸Cách kiểm: test nào chứng minh hành vi, test nào còn thiếu.

Review code AI sinh ra nên đọc theo lớp rủi ro, không đọc như đọc truyện từ đầu tới cuối. Mỗi lượt chỉ tập trung vào một câu hỏi. Cách này chậm hơn một chút ở đầu, nhưng giảm khả năng bị AI dẫn đi khắp nơi.

• ▸Lớp ý định: diff có giải đúng bài toán không, hay chỉ làm một phiên bản gần giống?
• ▸Lớp ranh giới: API, route, schema, quyền truy cập, dữ liệu vào/ra có đổi không?
• ▸Lớp logic: điều kiện, vòng lặp, transaction, cache invalidation, lỗi đồng thời.
• ▸Lớp lỗi: empty state, null/undefined, lỗi mạng, lỗi DB, rollback, thông báo lỗi.
• ▸Lớp test: test có bắt đúng hành vi không, có test ca biên không, test có quá phụ thuộc implementation không?
• ▸Lớp maintainability: tên gọi, cấu trúc file, duplication, code có hợp convention repo không?

git diff --stat main
git diff --name-status main
git diff main -- src/path/to/file.ts
git diff main --check

AI có thể giúp bạn review nhanh hơn nếu bạn hỏi đúng. Nhưng hãy nhớ: câu trả lời của AI là đầu vào cho review, không phải phán quyết. Việc của bạn là biến phần giải trình đó thành hiểu biết của chính mình.

Review phần diff này như một senior engineer, nhưng chỉ báo cáo, không sửa file.

Tập trung vào:
- Giả định nghiệp vụ có thể sai.
- Rủi ro dữ liệu, phân quyền, concurrency, rollback.
- Test còn thiếu hoặc test yếu.
- Đoạn code nào khó bảo trì nếu không có AI.

Với mỗi finding, ghi: file, dòng, vì sao nguy hiểm, cách kiểm chứng, đề xuất sửa.

• ▸Hỏi “vì sao chọn cách này?” thay vì chỉ hỏi “có lỗi không?”.
• ▸Yêu cầu AI chỉ báo cáo ở vòng review; đừng để nó vừa tự sửa vừa tự chấm.
• ▸Bắt buộc có bằng chứng: file/dòng, rủi ro, cách tái hiện hoặc test cần thêm.
• ▸Nếu bạn không giải thích lại được, hãy coi đó là tín hiệu cần đọc kỹ hơn.

Một diff quá lớn không chỉ khó review. Nó còn khiến bạn dễ nhượng quyền định hướng cho AI: AI đã dựng thế này rồi, mình sửa tiếp theo nó vậy. Cách chống lại là chia việc lớn thành các checkpoint nhỏ. Đây cũng là lúc plan mode phát huy tác dụng: bắt AI trình kế hoạch trước khi sửa.

• ▸Plan trước: yêu cầu AI trình kế hoạch và điểm dừng trước khi sửa.
• ▸Một PR = một thay đổi có thể hiểu được, test được, rollback được.
• ▸Commit theo lát cắt: schema riêng, logic riêng, UI riêng, test riêng nếu cần.
• ▸Dừng sau mỗi checkpoint: đọc diff, chạy test, quyết định đi tiếp hay đổi hướng.

Thay đổi này đang quá lớn để review.
Hãy đề xuất cách chia thành 3 PR nhỏ, theo thứ tự merge an toàn.

Với mỗi PR, ghi:
- Mục tiêu.
- File dự kiến đổi.
- Test/lệnh kiểm chứng.
- Rủi ro còn lại sau khi merge PR đó.

Chưa sửa file. Chỉ lập kế hoạch để tôi duyệt.

Một thay đổi AI sinh ra chỉ nên merge khi bạn trả lời được các câu hỏi dưới đây. Không cần thuộc lòng mọi dòng, nhưng phải hiểu đủ để chịu trách nhiệm vận hành.

• ▸Tôi có nói lại được thay đổi này làm gì và không làm gì không?
• ▸Tôi biết file nào là lõi, file nào chỉ là wiring/UI/test không?
• ▸Tôi biết test nào bảo vệ hành vi chính và ca biên nào đã được thử không?
• ▸Tôi biết rollback thế nào nếu deploy lỗi không?
• ▸Tôi có thể debug bug đầu tiên mà không cần AI viết lại cả tính năng không?