Anthropic's Claude Code team details how it reviews agent-written code
The Claude Code team at Anthropic published a post on how it reviews code when agents write most of it. The team has said before that Claude writes about 90 percent of Claude Code's own code, and the post asks the obvious questions: how do you review at that volume, does anyone still read code, and who catches what breaks? Its headline claim: from June to September, merged pull requests to Claude Code's codebase more than doubled, while the share that had to be reverted fell by more than 40 percent. The post gives no absolute counts, only these relative changes, and does not say the review process caused the revert decline.
The pressure is real. In Anthropic's monorepo (a separate repository from Claude Code's own), changes landing per day went from about 2,500 in May to more than 30,000 in September. The team says it did not remove review. It moved most of the reading to machines, optimized for human time and attention, and invested in making mistakes quick and easy to undo. Its working idea is that "did a human read the code?" is an imprecise proxy for "what could go wrong with this change, and which check, automated or human, is the right one to catch it?" Review used to be a gate at the end; now it runs continuously, like spellcheck, and most changes have been reviewed and fixed by Claude at least once before a human is asked to look.
The stated goal is that most PRs in the Claude Code repos (the CLI, the desktop and web apps, and the mobile apps) merge with at most one human in the loop, who can be the author, with no increase in reverts or incidents. To measure human time the team tracks human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Revert and incident rates are the guardrail: if they rise, time has only been moved, not saved.
The flow has several layers. Most review happens before a PR exists: Claude is given something it can run, such as tests, a build or a screenshot to compare against the design, and asked to show the output rather than say it is done; then a subagent reviews the diff with fresh context. Many engineers also run internal skills that hunt for bugs, simplify the diff and check behavior end to end. Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for good results and estimates it makes the final result two to three times better. When the automated reviewer keeps flagging the same thing, the team fixes it at the source: in a skill, with a lint rule, or in instruction files. CLAUDE.md describes the project (stack, conventions, goals, non-goals) and is loaded on every review. REVIEW.md, written by code owners, says what matters in their part of the code; good ones are short, describe what failure looks like in that repo, cap nits, list paths to skip and ask for a file and line as evidence.
Every PR then gets a Claude review before a person looks. It reads the diff against the whole repo and the PR's stated intent, and on a bug fix it looks for the root cause. The public version, Code Review for Claude Code, is generally available on Team and Enterprise plans, and /code-review runs a lighter version locally. After the research preview launched internally, the share of internal PRs getting substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings and most small ones come back clean. Admins set each repo to Quick, Standard or Deep; Deep pays off where one missed bug costs more than the extra review time. Several agents look for bugs at once, and a separate group votes on each finding, which is posted only if enough of them agree it is real. Findings about style, diagnostics or cleanup are dropped; the team A/B tested those filters on its own PRs. Comments appear inline, sorted by severity and tagged Important, Nit or Pre-existing. Every finding must be answered, by a fix or by resolving the thread with a reason, and a PR cannot merge while any finding from the bug review or the separate security review is open. Standard checks (lint, type checks, tests on every platform, a build) run too, and a typical CLI PR may run dozens of checks. The PR template asks how the change was tested and how to undo it; Claude can fill that in, but the person who asked for the change signs off.
Human review is tiered by risk. The change, not the author, sets the tier: one classifier picks the risk tier, and a second asks whether this particular change needs another person even if its tier says no. Owner-listed sensitive paths and any CI workflow file always need a person. Only authors on a repo's trusted list, mostly the owning team, get the lighter paths; everyone else needs a second person. An agent's approval never counts as a person's, so automated review can clear a low-risk change but cannot fill a slot that calls for a human. On an agent-written PR, the person directing the agent counts as one of the required reviewers. An approval covers one specific commit and must be given again if new commits land that the system cannot vouch for, such as an agent's push or a hand-resolved merge.
After approval, the merge queue re-runs every check against main with the change applied, so two PRs that pass separately cannot combine into a broken main. New behavior usually ships behind a flag to Anthropic employees first, and public releases go to the latest channel before the stable channel. Flags turn off without a deploy, Claude Code has a weekly on-call rotation, and incident reviews ask which layer should have caught the issue. The team admits a gap: noticing a bad merge still depends on the author, on-call and the revert and incident dashboards, and there are no circuit breakers yet that tighten approval when those numbers move. Engineers want them before more code moves to zero-human merges.
The process is meant to improve in a loop. Past PRs that caused incidents, with their fix-forwards and reverts, were collected and each bug confirmed by engineers who know the code; the reviewer runs against that set daily, so every incident becomes an eval. Noise is measured by sorting each reviewer comment by the response: fixed, said wrong, said intentional, or judged not to matter. The team also runs the reviewer on PRs known to be clean and counts how often it reports something that would lead to a harmful change. Its written priority is real bugs first, fewer review rounds second.
Noise costs more when the author is an agent, since a nit becomes another commit and another round. Review has to converge, because an agent author and an agent reviewer can keep each other busy indefinitely: one CLI PR went through more than fifty rounds of review and fixes overnight before its author stopped it. Running git blame on what the reviewer kept flagging showed about 59% of it was code present since the reviewer's first pass, so it was rarely finding new bugs, only a few more old ones each round. The team admits it made this worse by running several rounds by default. It now tracks rounds-to-pass alongside recall and changed its re-review behavior. Review agents also run nightly over existing code to catch old bugs.
Review's second job is spreading codebase understanding, and the post asks how anyone learns the code if machines do the reading. The team says it has no formal process for this. Nobody holds a complete mental model of Claude Code, and it does not think anyone needs to; when someone wants to understand a part, they ask Claude to write an explainer for exactly that slice, which takes minutes and reflects the code as it is today.
Key facts
- From June to September, merged PRs to Claude Code's codebase more than doubled while the share reverted fell by more than 40 percent (relative changes; no absolute counts given).
- Every PR gets a Claude review before a human looks; several agents find bugs and a separate group votes on each finding, and a PR cannot merge while a bug or security finding is open.
- The change, not the author, sets the review tier: classifiers pick the risk tier, an agent's approval never counts as a person's, and the person directing an agent counts as a required reviewer.
- After the automated reviewer's research preview launched internally, the share of internal PRs with substantive review comments rose from 16% to 54%.
- Open problems: no circuit breakers yet that tighten approval when reverts or incidents rise, and agent-on-agent review loops (one CLI PR ran more than fifty rounds overnight).
Why it matters
Most teams are asking how to review code when agents produce it faster than people can read it. This is a first-party account from the team that says Claude writes about 90 percent of Claude Code. Its answer is to stop treating "a human read the diff" as the goal and ask which check, automated or human, fits each risk, while using revert and incident rates as the guardrail. The design choices are concrete: tiers set by the change rather than the author, no agent approvals in human slots, per-commit approvals, a merge queue, flags and on-call.
Who it affects
Engineering teams whose code volume is rising because of coding agents, and the reviewers and on-call engineers who absorb that load. Admins on Team and Enterprise plans are affected directly, since Code Review for Claude Code is generally available there and they set each repo to Quick, Standard or Deep. Maintainers who write instruction files such as CLAUDE.md and REVIEW.md also shape how the reviewer behaves in their part of the code.
How to use it
The post points to several practices. Give Claude something it can run (tests, a build, a screenshot against the design) and ask it to show the output. Have a subagent review the diff with fresh context before opening a PR. Keep CLAUDE.md short, and have code owners write a short REVIEW.md that states what failure looks like, caps nits, lists paths to skip and asks for file and line evidence. Fix recurring reviewer findings at the source with a skill, a lint rule or an instruction file. Block merges on open bug or security findings. Code Review for Claude Code is available on Team and Enterprise plans, /code-review runs a lighter version locally, and the open-source security review GitHub Action or the /security-review command cover security. Track rounds-to-pass so review converges, and turn past incidents into an eval set.
How solid is it
This is a first-party process report from the team itself, not independent measurement. The June to September figures are relative only: merged PRs more than doubled and the reverted share fell by more than 40 percent, with no absolute counts or baseline revert rate. The post reports the two trends together and does not claim the review process caused the drop in reverts. The 2,500 to 30,000 daily changes figure is for Anthropic's monorepo, not the Claude Code repository. The text available for this retelling is cut off before the end, so some lists, such as what changed in re-review and the decisions left to humans, are not covered.
Risks and caveats
The team names its own gaps. There are no circuit breakers yet that tighten approval when revert or incident numbers move, and engineers want them before more code moves to zero-human merges. Noticing a bad merge still depends on the author, on-call and the dashboards. Agent author and agent reviewer can loop: one CLI PR ran more than fifty rounds overnight, and about 59% of what the reviewer kept flagging was code present since its first pass. Reviewer noise is costlier when the author is an agent, because each nit becomes another commit and another round. The team also says it has no formal process for spreading codebase understanding and relies on Claude-written explainers.
“Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator.”
— Boris Cherny, who created Claude Code