# Team Claude Code review code như thế nào?

> Team Claude Code tối ưu quy trình review code bằng hệ thống AI kiểm chứng đa tầng, phê duyệt theo rủi ro và các rào chắn tự động.

Nguồn: https://camnangai.com/ung-dung-ai/lap-trinh-vien/team-claude-code-review-code-nhu-the-nao  
Xuất bản: 2026-10-17

Khi các tác nhân AI viết phần lớn mã nguồn trong dự án, quy trình **review code** truyền thống nhanh chóng bộc lộ giới hạn. Đội ngũ [Claude Code](https://camnangai.com/cong-cu/claude-code-la-gi) giải bài toán này bằng cách chuyển việc soi từng dòng code từ con người sang các lớp kiểm tra tự động bằng AI, đồng thời bắt buộc tác nhân tự xác minh kết quả trước khi mở PR.

Cách làm này gỡ gánh nặng cho kỹ sư nhờ phân tầng phê duyệt theo mức độ rủi ro thực tế của thay đổi. Những PR rủi ro thấp sẽ tự động merge ngay khi vượt qua các cổng kiểm tra, còn sức lực của con người được giữ lại cho các vùng mã nhạy cảm.


  Kết hợp giữa tích hợp liên tục (CI) tự động, AI review nhiều tầng, quét bảo mật chuyên biệt và cơ
  chế khôi phục nhanh (rollback), bạn cùng đội ngũ có thể đẩy tốc độ phát hành lên rất cao mà không
  làm tăng sự cố trên môi trường thực tế.


![Quy trình review code đa tầng cho AI agent tại Anthropic](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/01-infographic-vn.webp)

## Vì sao team Claude Code đổi cách review code?

Tốc độ sinh code của các mô hình AI đã đẩy quy mô thay đổi mã nguồn vượt xa sức đọc của con người. Hiện tại, chính Claude viết khoảng 90% mã nguồn của dự án **Claude Code**. Trong kho lưu trữ tập trung (monorepo) của [Anthropic](https://www.anthropic.com), số lượng thay đổi merge mỗi ngày đã nhảy vọt từ khoảng 2.500 vào tháng 5 năm 2026 lên hơn 30.000 vào tháng 9 năm 2026.

Với lưu lượng đó, thói quen **review code** thủ công từng dòng trở thành một điểm nghẽn thực sự. Khi sản lượng code của mỗi kỹ sư tăng 200% so với cùng kỳ năm ngoái, người review rất dễ rơi vào cảnh đọc lướt cho xong thay vì kiểm tra kỹ logic. Nói thẳng ra, bắt mắt người đọc hết mọi thay đổi nhỏ là chuyện bất khả thi khi lượng PR tăng theo cấp số nhân.

Vì vậy, đội ngũ kỹ sư buộc phải đặt lại câu hỏi cốt lõi khi review code. Thay vì hỏi "Đã có ai đọc qua toàn bộ diff này chưa?", họ hỏi "Thay đổi này có thể gây lỗi ở đâu, và công cụ kiểm tra nào, tự động hay con người, phù hợp nhất để bắt lỗi đó?".

Thời điểm review cũng thay đổi hẳn. Trước đây, review là cái cổng chặn ở cuối đường: lập trình viên viết xong code, mở PR rồi ngồi chờ đồng nghiệp vào duyệt. Giờ đây, hoạt động review chạy liên tục ngay trong lúc viết code, giống như trình kiểm tra lỗi chính tả theo thời gian thực; phần lớn lỗi vặt đã được Claude tự phát hiện và sửa xong trước khi con người nhìn thấy PR.

![Chuyển đổi từ cổng review thủ công ở cuối kỳ sang vòng lặp kiểm chứng liên tục thời gian thực](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/02-vn.webp)

## Trước khi mở PR: Claude tự kiểm chứng công việc

Phần lớn công việc **review code** hiện diễn ra trước cả khi PR xuất hiện. Thay vì chỉ báo cáo miệng rằng nhiệm vụ đã xong, **Claude Code** phải tự chạy các bước [kiểm chứng](https://camnangai.com/ung-dung-ai/lap-trinh-vien/xac-minh-code-thoi-dai-ai) cụ thể như chạy bộ kiểm thử (test suite), lệnh build, công cụ kiểm tra mã tĩnh (linter), hoặc chụp ảnh màn hình trình duyệt và trình giả lập để đối chiếu với thiết kế. Theo ước tính từ chính đội ngũ phát triển, việc buộc tác nhân đưa ra bằng chứng kiểm tra giúp chất lượng kết quả cuối cùng tốt hơn gấp 2 đến 3 lần và khép kín vòng phản hồi mà chưa cần lập trình viên can thiệp.

Khi các bước kiểm tra cơ bản đã xanh, một [subagent](https://camnangai.com/ung-dung-ai/lap-trinh-vien/mastering-subagents-in-claude-code) (tác nhân phụ) sẽ nhảy vào đọc lại toàn bộ diff trong một cửa sổ ngữ cảnh (context window) hoàn toàn mới trước khi báo cho con người, nhằm tránh bị định kiến từ phiên viết code trước đó dẫn dắt. Đội ngũ kỹ sư cũng chạy thêm một số [kỹ năng](https://camnangai.com/kien-thuc-ai/agent-skills-la-gi) nội bộ chuyên biệt để săn lỗi ngầm, rút gọn diff và kiểm tra hành vi hệ thống từ đầu đến cuối (end-to-end). Riêng những thay đổi chạm vào giao diện sẽ phải so khớp trực tiếp với bộ quy chuẩn thiết kế của dự án.

Toàn bộ luồng kiểm tra sớm này dựa vào hai tệp cấu hình đặt ngay trong kho mã nguồn: `CLAUDE.md` và `REVIEW.md`. Tệp `CLAUDE.md` định nghĩa kiến trúc công nghệ, quy ước viết code cùng các mục tiêu và giới hạn của dự án, nên cần giữ ngắn gọn vì phiên làm việc nào cũng phải tải nó vào ngữ cảnh. Còn tệp `REVIEW.md` do chính nhóm phụ trách từng phần code viết ra để chỉ điểm các kiểu lỗi đặc thù trong miền của họ, giới hạn số lượng góp ý vụn vặt (nitpicks), liệt kê các thư mục cần bỏ qua và ép AI phải chỉ rõ tên tệp kèm dòng code làm bằng chứng thay vì đoán mò qua tên hàm.

```markdown
# Quy tắc Review cho Module Cấu hình & Core Engine

## Tiêu chuẩn đánh giá & Kịch bản thất bại

- Chỉ tập trung vào các lỗi logic nghiêm trọng: Lỗi định tuyến, cấu hình sai môi trường, hoặc sai lệch trạng thái bộ nhớ đệm.
- Giới hạn tối đa 3 góp ý nhỏ (nitpicks) về định dạng trên mỗi PR.
- Bắt buộc cung cấp đường dẫn tệp và số dòng cụ thể (`path/to/file.ext:line`) làm bằng chứng cho mỗi phát hiện lỗi.
- Đưa ra bản tóm tắt đầu ra bắt đầu bằng số lượng lỗi phát hiện được.

## Đường dẫn bỏ qua (Skip Paths)

- Bỏ qua kiểm tra đối với các thư mục: `docs/`, `tests/fixtures/`, và `generated/`.
```

## Trên mỗi PR: CI, AI review và security review chặn merge

Mỗi khi lập trình viên mở PR, thay đổi sẽ đi qua ba cổng **review code** tự động trước khi đến tay con người. Cổng đầu tiên là hệ thống CI bắt buộc với đầy đủ linter, kiểm tra kiểu dữ liệu tĩnh (static type checking), kiểm thử đơn vị đa nền tảng và kiểm tra build. Khi lượng tác vụ CI tăng gấp 25 lần chỉ trong 6 tháng, việc chạy toàn bộ bài test trên mọi PR khiến hạ tầng nhanh chóng quá tải, buộc Anthropic phải đập đi xây lại dịch vụ phân tích phạm vi ảnh hưởng của bài test (Test Impact Analysis). Họ tách khâu ghi nhận kết quả khỏi một tiến trình đơn lẻ và chuyển sang các worker không lưu trạng thái (stateless worker) ghi thẳng vào nhật ký (journal) trên kho dữ liệu trên bộ nhớ (in-memory data store), nhờ đó xóa bỏ hoàn toàn độ trễ của tiến trình lắng nghe (listener lag) để giữ hàng đợi ổn định.

Cổng thứ hai là hệ thống AI review đa tác nhân chạy theo ba mức Quick, Standard hoặc Deep tùy cấu hình từng kho lưu trữ, tiêu tốn trung bình khoảng 15–25 USD tiền token cho mỗi lượt review. Nhiều tác nhân cùng soi diff song song để tìm lỗi logic, sau đó một nhóm tác nhân xác minh sẽ bỏ phiếu đồng thuận nhằm lọc bỏ các cảnh báo giả (false positive) cũng như những nhận xét chỉ thuần về định dạng. Nhờ cơ chế lọc này, tỷ lệ PR nội bộ nhận được nhận xét thực chất đã tăng từ 16% lên 54%: các PR lớn trên 1.000 dòng có tỷ lệ phát hiện lỗi tới 84% với trung bình 7,5 vấn đề, còn các PR nhỏ dưới 50 dòng chỉ dừng ở mức 31% với trung bình 0,5 vấn đề.

![Ba cổng kiểm tra tự động chặn merge trên mỗi pull request: CI, AI Code Review và Security Review](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/03-vn.webp)

Cổng thứ ba là bước rà soát bảo mật tự động chạy qua lệnh `/security-review` hoặc GitHub Actions. Công cụ này quét toàn bộ diff để chặn sớm các lỗ hổng nguy hiểm như SQL injection, tấn công chèn mã kịch bản chéo trang (XSS), lỗi xác thực và phân quyền, xử lý dữ liệu không an toàn hay phụ thuộc vào thư viện bên thứ ba có lỗ hổng.

Cả hai cổng AI review và security review đều có quyền chặn merge. Chỉ cần còn bất kỳ cảnh báo lỗi hay rủi ro bảo mật nào đang mở, PR sẽ không thể gộp vào nhánh chính; tác giả buộc phải đẩy commit sửa lỗi hoặc đóng luồng nhận xét kèm lý do giải trình rõ ràng để bác bỏ cảnh báo giả.

## Phê duyệt theo mức rủi ro, không theo tác giả

Số lượt con người cần ký duyệt trong **review code** phụ thuộc vào mức độ rủi ro của bản thân thay đổi đó, chứ không phụ thuộc vào việc tác giả là kỹ sư kỳ cựu hay một tác nhân AI. Một bộ phân loại (classifier) tự động sẽ đọc diff để gán nhãn rủi ro, và một bộ phân loại thứ hai kiểm tra xem liệu thay đổi rủi ro thấp đó có chứa điểm bất thường nào cần gọi thêm người vào xem hay không. Với các PR do tác nhân AI viết, kỹ sư ra lệnh qua prompt và điều phối tác nhân sẽ đứng tên chịu trách nhiệm giống hệt như khi tự tay gõ từng dòng code.

Đội ngũ chia rủi ro thành ba bậc rõ rệt để không lãng phí sự tập trung của con người vào những chỗ vô hại. Điểm nguyên tắc ở đây là kết quả kiểm tra của AI tuyệt đối không bao giờ được tính thay cho suất phê duyệt của con người ở các bậc rủi ro trung bình và cao.

| Mức độ rủi ro  | Loại thay đổi điển hình                                                                              | Phê duyệt từ con người                  |
| :------------- | :--------------------------------------------------------------------------------------------------- | :-------------------------------------- |
| **Thấp**       | Tài liệu, văn bản giao diện, tính năng nội bộ, thay đổi bổ sung đằng sau cờ tính năng (feature flag) | 0 (Tự động sau khi CI và AI review đạt) |
| **Trung bình** | Tính năng sản phẩm thông thường, thay đổi bộ nhớ đệm, trình tự động cập nhật, system prompt          | 1 người                                 |
| **Cao**        | Logic cốt lõi nhạy cảm, hệ thống thanh toán, quy trình CI, các đường dẫn bảo mật quan trọng          | 2 người                                 |

Chỉ những tác giả nằm trong danh sách tin cậy của kho lưu trữ mới được đi theo luồng phê duyệt rút gọn này, còn người ngoài nhóm sở hữu vẫn cần thêm một kỹ sư thứ hai duyệt. Mỗi lượt phê duyệt cũng chỉ có giá trị cho đúng một mã commit cụ thể; nếu tác nhân đẩy thêm commit mới hoặc có người tự tay giải quyết xung đột merge, toàn bộ lượt duyệt trước đó sẽ bị hủy để xét lại từ đầu.

## Sau khi merge: flag, phát hành dần và rollback nhanh

Vượt qua các cổng **review code** trước khi merge vẫn chưa phải là đích cuối. Ngay khi đủ điều kiện, PR sẽ đi vào hàng chờ merge (merge queue) để chạy lại toàn bộ bộ kiểm thử trên trạng thái mới nhất của nhánh `main` sau khi đã gộp thay đổi đó vào. Lớp đệm này chặn đứng kịch bản quen thuộc: hai PR chạy test riêng lẻ đều xanh, nhưng khi gộp chung vào nhánh chính lại làm vỡ build của nhau.

Sau khi vào nhánh chính, các hành vi mới thường nằm sau cờ tính năng và được bật trước cho nhân viên Anthropic dùng thử nội bộ (dogfooding) hàng ngày. Chính cường độ sử dụng liên tục của các kỹ sư trong công ty giúp làm lộ ra các lỗi hồi quy (regression) rất nhanh trước khi tính năng chạm tới người dùng bên ngoài.

Khi phát hành ra công chúng, bản cập nhật cũng đi theo lộ trình triển khai theo giai đoạn (staged rollout). Mã mới sẽ lên kênh thử nghiệm (`latest`) trước để theo dõi số liệu vận hành, rồi sau đó mới được đẩy sang kênh ổn định (`stable`).

![Lộ trình triển khai sau merge: Merge queue, dùng thử nội bộ qua feature flag, phát hành từng chặng và khôi phục nhanh](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/04-vn.webp)

Nếu vẫn có lỗi lọt qua mọi tấm lưới trên, đội ngũ ưu tiên khả năng khôi phục tính bằng phút: tắt cờ tính năng ngay lập tức mà không cần đợi triển khai lại, hoặc chạy lệnh hoàn tác (revert) bản thay đổi. Nhờ kết hợp kiểm tra tự động ở đầu vào với khả năng quay lui nhanh ở đầu ra, từ tháng 6 đến tháng 9, số lượng PR merge vào kho mã nguồn **Claude Code** đã tăng hơn gấp đôi, trong khi tỷ lệ PR phải revert lại giảm hơn 40%.

## Reviewer AI được cải thiện liên tục như thế nào?

Để hệ thống reviewer AI làm tốt việc **review code** theo thời gian, đội ngũ nuôi nó bằng một vòng lặp dữ liệu lấy trực tiếp từ các vấp ngã trên hệ thống thực tế. Mỗi khi có một PR gây sự cố phải tung bản vá tiến (fix-forward) hoặc revert, các kỹ sư nắm rõ vùng code đó sẽ xác nhận lại nguyên nhân gốc rễ rồi đưa nó vào bộ đánh giá (eval) chạy hàng ngày. Bất kỳ chỉnh sửa nào đối với prompt, công cụ hay mô hình của reviewer AI đều phải ghi điểm cao hơn trên toàn bộ bộ eval này thì mới được giữ lại.

Ở chiều ngược lại, đội ngũ kiểm soát độ nhiễu bằng cách theo dõi phản ứng thực tế của lập trình viên trước từng nhận xét do AI để lại: họ sửa code theo gợi ý, đánh dấu nhận xét là sai, giải thích rằng đó là hành vi cố ý, hay lờ đi. Thực tế vận hành cho thấy kỹ sư đồng thuận rất cao với kết quả của hệ thống khi chưa đến 1% phát hiện bị đánh dấu là sai. Nhờ vậy, bài toán tối ưu luôn giữ đúng thứ tự ưu tiên: bắt trúng lỗi thật trước, rồi mới tìm cách rút ngắn số vòng trao đổi.

![Vòng lặp hoàn thiện reviewer AI: Biến sự cố và hoàn tác thực tế thành bộ đánh giá chuẩn hóa hàng ngày](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/05-vn.webp)

Khổ nỗi, khi tác nhân viết code gặp tác nhân review code, cả hai rất dễ sa vào hiện tượng lặp không hội tụ (convergence problem) vì cứ sửa qua sửa lại mãi không dứt. Đã có một PR của công cụ dòng lệnh chạy hơn 50 vòng review và sửa lỗi suốt cả đêm cho tới khi tác giả phải tự tay dừng lại; đến khi chạy `git blame` kiểm tra, đội ngũ phát hiện khoảng 59% lỗi mà reviewer AI cứ nhắc đi nhắc lại thực chất là code cũ đã nằm sẵn ở đó từ lượt kiểm tra đầu tiên chứ không phải lỗi do PR mới gây ra.

Để dứt điểm vòng lặp vô tận này, đội ngũ áp đặt bốn giới hạn cứng: khóa trần ở mức tối đa 3 vòng review trước khi trả về cho con người xem xét lại hướng tiếp cận, chỉ quét phần diff mới phát sinh ở các vòng sau, yêu cầu AI gom nhóm theo lớp lỗi để sửa một lần cho hết thay vì bắt lẻ từng dòng, và chặn đăng lại các nhận xét đã nêu. Nhờ bốn thay đổi này, tỷ lệ PR đi qua chỉ sau 1 vòng review đã tăng từ 65% lên 78%, số vòng review trung bình giảm từ 2,08 xuống 1,32, và tỷ lệ PR bị kéo dài từ 5 vòng trở lên tụt từ 8,9% xuống chỉ còn 1,5%.

## Con người vẫn giữ những quyết định nào?

Tự động hóa **review code** không đẩy con người ra khỏi quy trình mà trả họ về đúng những việc máy móc làm rất tệ. Kéo một kỹ sư kỳ cựu ra khỏi mạch làm việc sâu chỉ để bắt vài lỗi cú pháp hay định dạng là một sự lãng phí quá đắt đỏ so với chi phí chạy một lượt kiểm tra tự động bằng AI.

Con người giữ quyền quyết định về hướng đi sản phẩm, gu thiết kế và phạm vi tính năng. Kỹ sư là người trả lời câu hỏi đầu tiên: "Chúng ta có nên làm tính năng này không?", đồng thời cầm trịch các quyết định kiến trúc dài hạn sẽ tạo thành khuôn mẫu cho cả các tác nhân lẫn đồng nghiệp sao chép về sau.

Song song đó, con người vẫn trực tiếp gác cổng các vùng code có bán kính ảnh hưởng lớn như hệ thống thanh toán, cơ chế tự động cập nhật và luồng cấu hình CI. Thay vì tự đọc chay từng dòng code ở các phần thông thường, kỹ sư chuyển sang đọc bằng chứng kiểm tra: xem kết quả chạy test, lệnh đã thực thi cùng đầu ra thực tế, ảnh chụp màn hình và danh sách phát hiện của reviewer AI.

Và trên hết, con người giữ trách nhiệm giải trình cuối cùng theo nguyên tắc "You land it, you own it" (Bạn đưa mã nguồn lên, bạn sở hữu nó). Dù đoạn code đó do chính tay bạn gõ hay do tác nhân AI sinh ra theo lệnh của bạn, một khi đã đưa nó lên nhánh chính, bạn vẫn là người chịu trách nhiệm nếu nó gây lỗi trên hệ thống thực tế.

## Áp dụng cho team của bạn: nên bắt đầu từ đâu?

Nếu muốn đưa mô hình **review code** này về đội ngũ của mình, bạn không cần dựng ngay cả một hệ thống đồ sộ từ ngày đầu; hãy bắt đầu từ những điểm chặn sát tay lập trình viên nhất. Hãy cấp cho tác nhân các lệnh kiểm chứng tự động có thể chạy ngay trên máy cục bộ, viết một tệp `CLAUDE.md` ngắn gọn nêu rõ quy ước dự án, và tạo tệp `REVIEW.md` đầu tiên để gom những lỗi hay phải nhắc đi nhắc lại khi duyệt bài.

Sau đó, hãy bật công cụ AI review tự động thử nghiệm trên một kho lưu trữ duy nhất, dành vài tuần tinh chỉnh `REVIEW.md` cùng giới hạn số vòng lặp để dẹp bớt tiếng ồn rồi mới nhân rộng ra các kho khác kết hợp phân tầng phê duyệt theo rủi ro. Mảnh ghép giữ cho toàn bộ hệ thống ngày càng sắc bén hơn nằm ở chỗ biến mọi sự cố và bản commit revert trong quá khứ thành một bộ eval cố định, để bất kỳ thay đổi nào trên hệ thống review cũng được chấm điểm bằng dữ liệu thật trước khi áp dụng.

## Tài liệu tham khảo

- [How the Claude Code team does code review — claude.dev Blog](https://claude.dev/blog/solving-code-review-at-anthropic/)
- [Code Review — Claude Code Docs](https://code.claude.com/docs/en/code-review)
- [Code Review for Claude Code — Anthropic](https://claude.com/resources/articles/code-review)
- [Automated Security Reviews in Claude Code — Claude Help Center](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code)
- [Best practices for Claude Code — Claude Code Docs](https://code.claude.com/docs/en/best-practices)
- [Claude Code GitHub Actions — Claude Code Docs](https://code.claude.com/docs/en/github-actions)
- [Redesigning source control at Anthropic — Anthropic Engineering](https://www.anthropic.com/engineering/redesigning-source-control)
- [Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic — Anthropic](https://claude.com/resources/articles/agentic-coding-is-straining-ci-heres-how-we-scaled-test-impact-analysis-at-anthropic)