# How the Claude Code Team Does Code Review

> The Claude Code team handles code review at agentic scale with pre-PR verification loops, multi-agent checks, and risk-tiered human approvals.

Source: https://camnangai.com/en/for/developers/how-the-claude-code-team-does-code-review  
Published: 2026-10-17

To manage **code review** at agentic scale, you have to move routine diff reading to parallel
  multi-agent checks, enforce deterministic verification loops before pull requests are opened,
  scale human approvals by risk tier rather than author identity, and keep rollback fast.


Claude writes roughly 90% of [Claude Code](https://camnangai.com/en/tools/what-is-claude-code)'s own code. When daily merges to [Anthropic](https://www.anthropic.com)'s monorepo jumped from about 2,500 in May to over 30,000 in September 2026, traditional line-by-line manual inspection simply stopped working.


  By restructuring the review pipeline between June and September, merged pull requests to Claude
  Code's codebase more than doubled while revert rates fell by over 40%.


![Multi-layered automated code review architecture for the agentic coding era at Anthropic](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/01-infographic-en.webp)

## Why did the Claude Code team change how it does code review?

Engineering output per Anthropic engineer grew 200% in the last year as agentic coding tools matured. With Claude generating roughly 90% of Claude Code's own codebase, human line-by-line **code review** turned into a hard bottleneck. While Anthropic's main monorepo grew from 2,500 to over 30,000 daily merges between May and September 2026, Claude Code lives in its own repository under the same kind of pressure. Because developers were opening pull requests much faster than peers could read them, continuous integration (CI) queues and review backlogs piled up. Worse, asking humans to read every diff line by line produced shallow skims instead of careful scrutiny, slowing delivery without actually catching bugs.

That pressure forced the team to separate the two jobs code review has always done: catching bugs before they ship, and spreading codebase knowledge across the team. Requiring a human to read every line conflates those two goals. Asking "did a human read this code?" is a poor proxy for asking what could actually go wrong with a change, and whether an automated check or a person is better suited to catch it.

So the team moved review from a blocking gate at the end of development into a continuous check that runs while code is still being written. Much like spellcheck in a text editor, review agents inspect changes incrementally before a pull request even exists. By the time you open a PR, Claude has already checked and fixed the diff against repository conventions and automated tests at least once, which clears out routine syntax, style, and logic mistakes before another engineer ever gets pinged.

Under this model, human time and attention are the scarce resource you optimize for, covering both the hours spent reviewing diffs and the hours spent fixing whatever bad code breaks in production. The team tracks human approvals per PR (both median and 95th percentile), human comment volume, and how long a PR waits on a person, while using production revert rates and incident rates as hard guardrails. If reverts or incidents climb, you haven't saved engineering time—you have only moved it from review into firefighting.

![Shift from blocking end-of-cycle manual review to continuous real-time verification loops](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/02-en.webp)

## Before the pull request: Claude verifies its own work

Most **code review** now happens before a pull request is ever opened. The core habit behind agentic coding is the [verification](https://camnangai.com/en/for/developers/why-code-verification-matters-in-the-age-of-ai)-first rule: give Claude something concrete it can run, and require it to show the output instead of just claiming the job is done. When the agent has an explicit check—whether that is a test command, a build exit code, a linter, or a screenshot diff in a browser or phone simulator—it runs in a tight loop, fixing its own mistakes until the check passes. Boris Cherny, who created Claude Code, estimates that giving Claude a way to verify its work makes the final output 2x to 3x better than unverified generation.

Once the basic checks pass, a [subagent](https://camnangai.com/en/for/developers/mastering-subagents-in-claude-code) reviews the local diff inside a fresh context window so it isn't biased by the failed attempts and assumptions sitting in the authoring agent's session. Many engineers on the team also run internal [skills](https://camnangai.com/en/knowledge/what-are-agent-skills) before opening a PR: one hunts for bugs, one simplifies the diff, and one verifies behavior end to end, while UI changes are checked directly against design guidelines.

Whenever the automated reviewer keeps flagging the same mistake, the team fixes it at the source with a lint rule, a skill update, or two repository config files: `CLAUDE.md` and `REVIEW.md`. `CLAUDE.md` tells Claude what the project is (its stack, conventions, goals, and non-goals) and stays short because every session loads it into context. `REVIEW.md`, written by code owners for their specific slice of the codebase, spells out what failure looks like in that domain, caps minor nitpicks, lists paths to skip, and requires the reviewer to cite an exact file and line number as evidence instead of guessing from a function name.

```markdown
# CLAUDE.md - Core Project Conventions

- Build: `npm run build` | Test: `npm test -- path/to/test.ts`
- Style: Use ES modules (`import/export`). Prefer functional patterns.
- Boundaries: Do not modify files in `src/legacy/` without explicit approval.

---

# REVIEW.md - Routing Subsystem Rules

## Critical Failure Modes

- Config changes: verify routing logic matches schema in /docs/routing.md.
- State management: ensure all mutated state dispatches an explicit audit event.

## Review Constraints

- Cap cosmetic nitpicks at 3 per pull request.
- Ignore auto-generated files inside `src/generated/`.
- Require file path and exact line number for every flagged issue.
- Summary must begin with an explicit bug count: "Findings: X critical, Y minor."
```

## On every pull request: CI, AI review and security review block the merge

When you open a pull request, three automated gates run in parallel before any human **code review** happens. The first gate is required CI: linting, static type checks, cross-platform unit tests, and a full build. Because running every test on every PR collapses at agentic volume, and CI job volume at Anthropic jumped 25x over six months, the team rebuilt its deterministic test impact analysis service around a listener/selector architecture. Stateless listener workers record test results from CI runs and append them to a journal in an in-memory data store, while a selector process queries that rolled-up history to run only the tests relevant to the modified packages. Offloading state from the old single-process writer eliminated listener lag and kept job-result queues flat even under a 25x load jump.

The second gate is AI Code Review, which runs parallel multi-agent bug-hunting passes across the diff against the surrounding repository. Several agents hunt for logic bugs, edge cases, and regressions at the same time, and a separate group of verifier agents votes on each candidate so only findings that reach consensus get posted (dropping pure style or cleanup noise). Surviving findings appear as inline PR comments tagged Important, Nit, or Pre-existing, which keeps an old bug from looking like the PR author's fault. After launching this flow internally, the share of PRs receiving substantive review comments rose from 16% to 54%. Admins configure each repo to Quick, Standard, or Deep (with token usage averaging $15 to $25 per review), and on large PRs over 1,000 lines, 84% receive findings (averaging 7.5 issues), compared to 31% (averaging 0.5 issues) on PRs under 50 lines.

![Three automated merge-blocking gates on every pull request: CI, AI Code Review, and Security Review](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/03-en.webp)

The third gate is Automated Security Review, which scans the diff for vulnerabilities such as SQL injection, cross-site scripting (XSS), broken authentication or authorization, unsafe data handling, and vulnerable third-party dependencies. You can run it locally with `/security-review` or enforce it on every pull request through GitHub Actions.

```yaml
# .github/workflows/claude-security.yml
name: Security Review
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  security-scan:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
      id-token: write
    steps:
      - uses: actions/checkout@v6
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: "/security-review"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'
```

Together, these checks act as a hard merge block. A pull request cannot merge while any finding from the bug review or the security review remains open. You either push a commit that fixes the bug—which clears the finding automatically on the next pass—or close the comment thread with a short engineering reason to dismiss a false positive.

## Approval scaled by risk, not by author

Human sign-off in **code review** follows a three-tier risk model so engineers aren't pulled into rubber-stamping copy tweaks while risky code still gets deep scrutiny:

| Risk Tier  | Typical Changes                                                                                  | Required Human Approvals                            |
| :--------- | :----------------------------------------------------------------------------------------------- | :-------------------------------------------------- |
| **Low**    | Docs, copy edits, internal-only features, additive changes behind a feature flag                 | 0 once CI, AI review, and security checks are green |
| **Medium** | Ordinary product changes, plus sensitive areas like caching, the auto-updater, or system prompts | 1 person                                            |
| **High**   | Highest-risk code, including billing, auth, security boundaries, and CI workflows                | 2 people                                            |

An automated classifier reads the diff and assigns the risk tier based on the change itself, not who wrote it. A second classifier checks whether a low-risk change has any unusual trait that still calls for a human eye, while sensitive paths like billing, installers, and CI workflow files are locked down in `CODEOWNERS` and branch protection rules so they always require a person.

Strict guardrails keep the zero-human path safe. Only authors on the repository's trusted list—mostly the team that owns the repo—qualify for the lighter approval paths, while everyone else needs a second person. On an agent-written PR, the engineer who prompted and directed the agent is on the hook for the change and counts as one of the required human reviewers, whereas an agent's own approval never fills a human slot. Every approval is also bound to a specific commit hash, so if an agent pushes a new commit or someone resolves a merge conflict by hand, existing approvals reset automatically.

## After the merge: flags, gradual release and fast rollback

Passing pre-merge **code review** is not the end of the safety net. Once approved, a pull request enters the merge queue, which applies the change to the latest `main` branch and re-runs the full check suite against the combined result. That stops two PRs that passed CI separately from combining into a broken `main`.

After landing on `main`, new behavior rolls out in stages rather than hitting every external user at once. Runtime changes usually ship behind feature flags to Anthropic employees first, where heavy daily dogfooding across thousands of internal sessions surfaces regressions early. Public builds then go to the `latest` release channel first, while the `stable` channel trails behind as telemetry comes in.

![Post-merge progressive deployment: Merge queue, internal dogfooding with feature flags, staged rollout, and rapid rollback](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/04-en.webp)

Because some bugs will still slip through every pre-merge layer, the final defense is catching and undoing mistakes in minutes. Feature flags can be flipped off immediately without waiting for a new deploy, and the team runs a weekly on-call rotation watching live revert and incident dashboards. Whenever a bad change does force a revert or cause an incident, the follow-up review asks a specific systems question: which verification layer should have caught this before it shipped?

## How does the AI reviewer keep getting better?

The AI reviewer improves through a tight feedback loop built directly from production mistakes in **code review**. The team collected past pull requests that caused incidents, along with their fix-forwards and reverts, and had engineers who know those modules confirm each bug and its exact location. Those verified failures form a daily evaluation set, and any change to the reviewer's prompts, tools, or underlying model has to score higher against that eval set before the team keeps it.

Catching more bugs is easy if you don't mind flooding developers with false alarms, so the team also tracks noise by watching how engineers respond to every comment the reviewer leaves: whether they fixed it, marked it wrong, explained that the behavior was intentional, or ignored it. In practice, engineer agreement is remarkably high, with less than 1% of findings marked incorrect. Noise is even more expensive when the author is an agent—a human can wave off a nit in seconds, whereas an agent dutifully writes a fix, pushes a commit, and triggers another full round of review.

![The continuous eval loop: Turning production incidents and reverts into daily evaluation benchmarks](https://camnangai.com/articles/team-claude-code-review-code-nhu-the-nao/05-en.webp)

Left unchecked, an agent author and an agent reviewer will happily keep each other busy all night. One internal CLI pull request went through more than 50 rounds of review and fixes overnight before its author stepped in and stopped it. When the team ran `git blame` on what the reviewer kept flagging, about 59% of the comments pointed at code that had been sitting there since the reviewer's very first pass rather than new bugs introduced by the fix.

To force reviews to converge, the team changed how re-review works across four rules:

1. **A three-round cap** where the reviewer stops and asks the human author to step back and reconsider the approach.
2. **Diff-only re-review** after the first few passes so the agent stops re-auditing untouched files.
3. **Bug-class flagging** so the author fixes every instance of a mistake in one pass instead of playing whack-a-mole line by line.
4. **No duplicate findings** repeating issues that were already posted in earlier rounds.

Those four rules cut review churn sharply. The share of internal pull requests passing after a single review-and-fix round rose from 65% to 78%, PRs needing five or more rounds fell from 8.9% to 1.5%, and mean review rounds to pass dropped from 2.08 to 1.32.

## Which decisions do humans still own?

Automating routine diff reading in **code review** frees engineers from acting as human linters so they can focus on the high-impact decisions machines are still bad at. Pulling a senior engineer out of deep work to catch a missing null check costs far more than spending $15 to $25 of tokens on an automated multi-agent pass, so human attention is reserved for five specific areas.

First, humans decide product direction, taste, and scope—answering whether a feature should exist at all, and raising that question early in open Slack channels before a finished PR even lands. Second, humans still inspect and approve high-risk code paths such as billing, authentication, the auto-updater, and CI release workflows. Third, engineers own system architecture that sets a pattern other teammates and agents will copy across the codebase.

The remaining two responsibilities are reading verification evidence and owning the outcome in production. Instead of re-reading every line of a routine diff by hand, reviewers inspect the proof the agent produced: test outputs, the exact command that ran and what it returned, screenshots, and the AI reviewer's findings. And under the team's "You land it, you own it" norm, a human is accountable for every change that ships, regardless of who typed the code.

Moving most diff reading to machines also changes how the team shares codebase context. Nobody on the team tries to hold a complete mental model of Claude Code in their head anymore. When an engineer needs to work on an unfamiliar module, they ask Claude to generate an explainer—or a small visual artifact—for that exact slice of the codebase as it exists on `main` today, which teaches far more in a few minutes than skimming dozens of trivial one-line diffs ever did.

## Adopting this for your team: where to start?

You don't need Anthropic's entire infrastructure to bring this **code review** model to your own team; most of the building blocks are already available. Start before the pull request by giving your agent checks it can run locally in a short `CLAUDE.md`, wiring up hooks for formatters and linters, running `/code-review` and `/security-review` before opening a PR, and creating a `REVIEW.md` that captures the review comments your team repeats most often.

On pull requests, require CI and add explicit "Testing", "Risk", and "How to revert" fields to your PR template. Roll out an automated AI reviewer (such as Code Review for Claude Code or the Claude Code GitHub Action) on a single repo first, spend a few weeks tuning `REVIEW.md` and capping review rounds to keep noise down, and require every review thread to be resolved before merge. Once you trust the signal, write down explicit risk tiers protected by `CODEOWNERS`, pair them with a merge queue and feature flags, and turn every production incident or revert into a daily eval case so your reviewer keeps getting sharper over time.

## References

- [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)