How the Claude Code team does code review

What it claims

The Claude Code team's target is that most PRs in its repos (CLI, desktop, web, mobile) merge with at most one human in the loop, and that human can be the author, with no rise in reverts or incidents. Human cost is measured as:

• human approvals per PR (median and p95)
• human comments
• time a PR waits on a person

Revert and incident rates are the guardrail. The pressure behind this: Anthropic's monorepo went from about 2,500 changes landing per day in May to more than 30,000 in September.

How it works

Before the PR. Claude is given something it can run (tests, a build, a screenshot to compare against the design) and must show the output rather than claim it is done. A fresh-context subagent then reviews the diff. Internal skills hunt for bugs, simplify the diff and check behaviour end to end. Recurring reviewer findings get fixed at the source: a skill, a lint rule, or the instruction files.

• CLAUDE.md is loaded on every review, so it is kept short and points to other docs. The reviewer also flags changes that make a line in it stale.
• REVIEW.md is written by code owners, and the team checks separately that the reviewer follows it. Good ones:
• state what failure means in that repo ("it lies" for docs, "it misroutes" for config)
• cap nits and list paths to skip
• require file-and-line evidence
• ask for a summary that opens with a count and says plainly when there is nothing to fix

On the PR. Several agents hunt for bugs in parallel. A separate group votes on each finding, which is posted only if enough agree. Style, diagnostic and cleanup-only findings are dropped; these filters were A/B tested on internal PRs. Findings are tagged Important, Nit or Pre-existing. A PR cannot merge with an open bug-review or security-review finding: fix it, or close the thread with a reason. A finding clears automatically if a later commit fixes it.

Gating rules:

• An approval covers one commit. Agent pushes and hand-resolved merges require re-approval.
• An agent's approval never fills a human slot.
• The person who prompted an agent-written PR counts as a required reviewer.
• The merge queue re-runs all checks against main. New behaviour ships behind flags to employees first, then the latest channel, then stable.

flowchart TD
  PR[PR opened] --> S{Sensitive path or CI workflow?}
  S -- yes --> H[Human required]
  S -- no --> C1[Classifier sets risk tier]
  C1 --> C2{2nd classifier: needs a person anyway?}
  C2 -- yes --> H
  C2 -- no --> T{Author on trusted list?}
  T -- no --> H2[Second human approval]
  T -- yes --> L[Lighter path: automated checks may clear]

Evidence

• From June to September, merged PRs more than doubled and the revert share fell by more than 40%.
• When the automated reviewer launched as a research preview, the share of internal PRs getting substantive review comments went from 16% to 54%.
• Most PRs over 1,000 lines get findings; most small ones come back clean.
• Incidents as evals. Past incident-causing PRs, with their fixes and reverts, were confirmed by engineers who know that code. The reviewer runs against this set daily.
• Noise. Each comment is classified by how the author responded: fixed, wrong, intentional, or didn't matter. The reviewer also runs on known-clean PRs to count findings that would have prompted a harmful change.
• Stated priority. Catch real bugs first, cut review rounds second.

How to use it

• Code Review for Claude Code is GA on Team and Enterprise plans. Admins set each repo to Quick, Standard or Deep; Deep pays off where one missed bug costs more than the extra review time.
• Local equivalents are /code-review (a lighter version) and /security-review. There is also an open-source security review GitHub Action.
• The public product posts findings, not approvals. Letting low-risk changes merge on automated checks alone is the team's internal policy, not a product feature.

Limits

• Loops can fail to converge. Agent author plus agent reviewer can loop: one PR ran 50+ overnight rounds. A git blame showed about 59% of repeat flags were code present since the reviewer's first pass, so later rounds were mostly finding old bugs, not new ones. The team now tracks rounds-to-pass alongside recall. The concrete re-review changes are not in the fetched text.
• Noise is costlier with agent authors. An agent fixes every nit, which adds a commit and another review round.
• No circuit breakers yet. Nothing automatically tightens approval when revert or incident numbers move, and engineers want this before more code moves to zero-human merges.
• Knowledge-sharing is informal. It relies on Claude-written explainers and open Slack channels, with no formal process.