Claude Code review PR do AI tạo: máy kiểm tra, người quyết định theo rủi ro
Đội Claude Code chuyển phần lớn việc kiểm tra diff sang hệ thống tự động, giữ phê duyệt của con người cho thay đổi rủi ro và coi revert, incident là chỉ số bảo vệ chất lượng.
Khi AI tạo ra nhiều thay đổi hơn, câu hỏi trong code review không còn chỉ là: “Đã có ai đọc từng dòng chưa?”
Theo đội Claude Code, câu hỏi hữu ích hơn là: thay đổi này có thể gây lỗi gì, và lớp kiểm tra nào — máy hay con người — phù hợp nhất để phát hiện nó?
Bài viết của đội Claude Code mô tả một quy trình review nhiều lớp: kiểm tra tự động diễn ra từ trước khi mở PR, AI review mọi PR, security review và CI có thể chặn merge, còn mức phê duyệt của con người được quyết định theo rủi ro của thay đổi.
Từ tháng 6 đến tháng 9, đội này cho biết số PR được merge trong codebase Claude Code đã tăng hơn gấp đôi, trong khi tỷ lệ phải revert giảm hơn 40%.
Review không biến mất, mà được phân phối lại
Claude Code cho biết Claude viết khoảng 90% code của chính Claude Code. Trong monorepo của Anthropic, số thay đổi được merge mỗi ngày đã tăng từ khoảng 2.500 vào tháng 5 lên hơn 30.000 vào tháng 9 cùng năm.
Ở quy mô đó, review thủ công từng dòng trở nên rất khó duy trì. Theo bài viết, code review vẫn có hai nhiệm vụ chính:
Tìm và sửa lỗi trước khi phát hành.
Xây dựng hiểu biết chung về hệ thống trong đội ngũ.
Bài viết tập trung chủ yếu vào nhiệm vụ đầu tiên. Thay vì coi việc “một người đã đọc code” là thước đo cuối cùng, đội Claude Code đánh giá rủi ro của từng thay đổi và chọn kiểm tra phù hợp để bắt rủi ro đó.
Mục tiêu của họ là để phần lớn PR trong các repository Claude Code có thể merge với tối đa một người tham gia vòng review — người đó có thể chính là tác giả — mà không làm tăng revert hoặc incident.
Để theo dõi chi phí review của con người, họ đo:
Số approval của con người trên mỗi PR, gồm median và phân vị 95%.
Số bình luận của con người.
Thời gian PR chờ người xử lý.
Revert và incident là các chỉ số bảo vệ. Nếu chúng tăng, việc giảm thời gian review không thực sự tiết kiệm công sức mà chỉ chuyển chi phí sang giai đoạn xử lý lỗi.
Lớp 1: Xác minh thay đổi trước khi mở PR
Theo đội Claude Code, phần lớn review hiện diễn ra trước khi PR tồn tại.
Họ yêu cầu Claude có một cách để tự xác minh kết quả, như chạy test, build hoặc so sánh screenshot với thiết kế. Mục tiêu là yêu cầu hệ thống đưa ra đầu ra có thể kiểm tra, thay vì chỉ tuyên bố đã hoàn thành.
Sau đó, một subagent đọc lại diff với ngữ cảnh mới.
Bài viết cũng đề cập các tài liệu hướng dẫn dành cho reviewer:
CLAUDE.md mô tả stack, quy ước, mục tiêu và những điều dự án không làm. Đội này giữ tài liệu ngắn, rồi dẫn đến tài liệu chi tiết hơn khi cần.
REVIEW.md do code owner viết, nêu điều quan trọng trong từng phần của repository.
Theo mô tả, REVIEW.md hiệu quả khi ngắn gọn và cụ thể: chỉ ra dạng lỗi cần quan tâm, các đường dẫn nên bỏ qua, giới hạn số nhận xét vụn vặt, đồng thời yêu cầu finding phải có bằng chứng bằng file và dòng thay vì suy đoán từ tên.
Với đội vận hành nền tảng, đây là một gợi nhắc quan trọng: AI reviewer cần ngữ cảnh của repository và failure mode cụ thể, không chỉ cần diff.
Lớp 2: AI review trên mọi pull request
Đội Claude Code cho biết mọi PR đều được Claude review trước khi con người xem.
Reviewer đọc diff trong bối cảnh toàn repository và ý định của PR, rồi đánh giá các câu hỏi như:
Thay đổi có giải quyết đúng vấn đề không?
Nó có phù hợp với hệ thống hiện có không?
Nó có làm hỏng phần khác không?
Với bug fix, nguyên nhân gốc đã được xử lý chưa?
Phiên bản công khai Code Review for Claude Code được bài viết cho biết đã khả dụng cho gói Team và Enterprise. Lệnh /code-review chạy một phiên bản nhẹ hơn ở môi trường cục bộ.
Theo bài viết, các finding được nhiều agent kiểm tra chéo trước khi hiện cho người. Những nhận xét chỉ về style, diagnostics hoặc cleanup có thể bị loại. Finding còn lại được hiển thị inline, sắp theo mức độ nghiêm trọng và có thể mang nhãn:
Important
Nit
Pre-existing
Nhãn Pre-existing đặc biệt đáng chú ý: lỗi không do PR hiện tại tạo ra không nên bị quy thành trách nhiệm của tác giả thay đổi đó.
Mỗi finding cần được xử lý bằng cách sửa hoặc đóng thread kèm lý do. Đội Claude Code cho biết đôi khi agent sẽ tiếp tục xử lý finding ngoài giờ làm việc, để tác giả quay lại với một PR đã đi qua thêm một vòng sửa.
Lớp 3: Security review có thể chặn merge
Security review là một lớp riêng trong quy trình được mô tả.
Theo bài viết, PR không thể merge nếu finding từ bug review hoặc security review vẫn còn mở. Một finding có thể được xử lý bằng commit mới; nếu finding là false positive, thread có thể được đóng với lý do ngắn.
Bài viết cũng nêu lệnh:
text
/security-review
Đội Claude Code cho biết có GitHub Action mã nguồn mở cho security review, đồng thời dẫn đến tài liệu thiết lập riêng.
Phần bình luận cộng đồng đặt ra một lưu ý: việc đóng finding bảo mật nghiêm trọng dưới dạng false positive cần được cân nhắc kỹ. Đây không phải là quy tắc được bài viết xác nhận, nhưng là rủi ro thực tế mà các đội platform và security cần đánh giá trong quy trình review của mình.
Lớp 4: Các kiểm tra tự động vẫn là blocker
Bên cạnh AI và security review, quy trình còn dựa vào các kiểm tra quen thuộc:
Lint.
Type check.
Test trên các nền tảng.
Build.
Bài viết cho biết một PR CLI điển hình có thể chạy hàng chục kiểm tra trước khi có người xem.
PR template cũng hỏi thay đổi đã được test như thế nào và cách undo khi cần. Claude có thể hỗ trợ điền nội dung này, nhưng người yêu cầu thay đổi là người sign off.
Điểm đáng chú ý ở đây không phải là thay thế CI bằng AI review. AI review nằm trong một chuỗi kiểm soát, còn test, build và các kiểm tra tự động vẫn là điều kiện chặn merge.
Lớp 5: Approval của con người theo mức rủi ro
Đội Claude Code không áp dụng một mức review giống nhau cho mọi thay đổi.
| Mức rủi ro | Ví dụ trong bài viết | Approval con người |
|---|---|---|
| Thấp | Docs, copy, tính năng nội bộ, thay đổi cộng thêm sau feature flag | Không cần nếu review tự động và security check đã đạt |
| Trung bình | Thay đổi sản phẩm thông thường; khu vực nhạy cảm như caching, auto-updater hoặc system prompt | Một người |
| Cao | Code có rủi ro cao nhất và một số path luôn cần hai người | Hai người |
Theo mô tả, classifier đầu tiên đọc thay đổi để chọn tier rủi ro. Classifier thứ hai đánh giá liệu thay đổi cụ thể có cần thêm một người hay không, ngay cả khi tier ban đầu không yêu cầu.
Một số path luôn cần người review, gồm những khu vực mà owner đánh dấu là nhạy cảm và mọi file workflow CI.
Nguyên tắc cốt lõi là: mức kiểm soát được quyết định bởi thay đổi, không phải danh tiếng của tác giả.
Rollback là lớp bảo hiểm cuối cùng
Đội Claude Code nhấn mạnh họ đầu tư nhiều vào việc giúp undo sai lầm nhanh và dễ.
Đây là phần đặc biệt gần với tư duy SRE: mọi lớp review đều có thể bỏ sót lỗi. Vì vậy, giảm rủi ro không chỉ là cố gắng bắt lỗi trước khi merge, mà còn là giảm chi phí phục hồi khi lỗi vẫn đi vào production.
Bài viết mô tả rollback như lớp nằm bên dưới toàn bộ chuỗi kiểm tra. Mỗi lớp có thể bắt một số vấn đề và bỏ sót số khác; rollback xử lý phần còn lại.
Điều đáng rút ra cho đội DevOps/SRE
Bài viết không lập luận rằng con người nên ngừng review code. Thay vào đó, nó đặt lại cách phân bổ sự chú ý:
Máy xử lý các kiểm tra lặp lại và có thể tự động hóa.
AI review diff trong bối cảnh repository và ý định thay đổi.
Security, test, build và các kiểm tra khác giữ vai trò gate.
Con người tập trung vào thay đổi có rủi ro cao.
Revert và incident xác nhận liệu việc tối ưu thời gian review có thực sự hiệu quả hay không.
Với các đội đang dùng agent để tăng tốc thay đổi, đây là câu hỏi cần theo dõi: tốc độ merge có tăng mà không kéo theo revert và incident hay không?
Nếu câu trả lời là không, phần thời gian “tiết kiệm” được ở review có thể chỉ đang xuất hiện trở lại dưới dạng chi phí vận hành.