Anthropic explains how the Claude Code team reviews code when AI writes most of it

Anthropic has published a detailed account of how the Claude Code team reviews changes when roughly 90 percent of that codebase is written by Claude itself. The post, on the team's own blog, describes a layered pipeline in which automated reviewers do most of the reading, human attention is allocated by risk, and undoing a bad change is treated as a first-class capability.

The numbers the team reports are striking. Between June and September, merged pull requests to Claude Code's repositories more than doubled while the share that had to be reverted dropped by more than 40 percent. The pressure is broader: in Anthropic's monorepo, changes landing per day grew from about 2,500 in May to more than 30,000 in September. Claude Code lives in a separate repository, but at that volume the team says manual line-by-line review by people is no longer practical.

Review as a continuous process, not a gate

The team's central argument is that asking whether a human read the code is the wrong question. The better question, they write, is what could go wrong with a change and which check — human or automated — is best placed to catch it. In practice, review moved from a final checkpoint to a background process that runs throughout development. Most changes have already been reviewed and repaired by Claude at least once before any person is asked to look, clearing routine mistakes and leaving human attention for higher-level judgment.

The stated goal is that most pull requests across the Claude Code repositories — the CLI, desktop and web apps, and mobile apps — merge with at most one human in the loop, who may simply be the author, without increasing reverts or incidents. The team tracks median and 95th-percentile human approvals per pull request, human comment counts, and how long a PR waits on a person, with revert and incident rates as guardrails. If those rates climb, the team notes, human time was not saved, only displaced.

Layers instead of a single checkpoint

The post walks through the layers a typical change passes through:

• Verification before the pull request. Claude is given something runnable — a test, a build, a screenshot to compare against a design — and must show the output rather than claim completion. A subagent reviews the diff with fresh context, and internal skills hunt bugs, simplify the diff, and check behavior end to end. Boris Cherny, who created Claude Code, estimates that giving the model a way to verify its own work makes the result two to three times better.
• AI review on every pull request. Each PR gets a Claude review that reads the diff against the whole repository and the change's stated intent. When the research preview launched, the share of internal PRs receiving substantive review comments rose from 16 to 54 percent. Most PRs over 1,000 lines produce findings; small ones usually come back clean. Administrators set each repository to Quick, Standard, or Deep review intensity.
• Findings vetted by other agents. Multiple bug-hunting agents work in parallel, and a separate group votes on each finding, which is posted only if enough agree it is real. Stylistic findings are dropped, a filter the team validated with A/B tests on its own PRs. What survives appears as inline comments tagged so pre-existing problems are not blamed on the author. Every finding must be fixed or resolved with a written reason, and an agent often applies fixes overnight.
• Security review that blocks merges. A pull request cannot merge while any bug or security finding is open, and findings clear automatically once a later commit addresses them. Public equivalents include an open-source security review GitHub Action and a /security-review command, while Code Review for Claude Code is generally available on Team and Enterprise plans, with a lighter local /code-review command.
• Conventional CI. Linting, type checks, cross-platform tests, and builds run before a person looks. The PR template asks how the change was tested and how to undo it; Claude can draft the answers, but the person who requested the change signs off.
• Risk-based human approval. Documentation fixes and auto-updater changes carry very different risk and get different treatment: low-risk changes such as docs, copy edits, internal-only features, and additive changes behind a flag require no human approval once automated checks clear.

Why it matters

The post acknowledges that review traditionally does a second job — building shared understanding across a team — but concentrates on defect detection.

Most teams adopting AI coding tools are hitting the wall Anthropic describes: generation speed has outrun human review capacity. What makes the account useful is how concrete the transferable ideas are — verify with runnable evidence, filter machine findings with machine voting, price human attention by risk, and make rollback fast instead of pretending review catches everything. The early metrics, doubled merges alongside a 40 percent drop in reverts, suggest the approach can hold quality at far higher throughput, at least in the environment where the tool itself is built.