Anthropic has published a detailed account of how the Claude Code team reviews code when, in its words, Claude writes about 90 percent of Claude Code's own code. The headline claim: from June to September, merged pull requests to the Claude Code codebase more than doubled, while the share that had to be reverted fell by more than 40 percent. The post, How the Claude Code team does code review, is by Addy Osmani, Morgan Westlee Lunt and Qing Wang and was published on October 15, 2026. The core idea is blunt. Anthropic says it did not remove review. It moved most of the reading to machines, tuned the process for scarce human attention, and invested in making mistakes fast to undo. This is the process, with the numbers Anthropic gives and what you can borrow.
TL;DR: what Anthropic says it does
| Question | Answer from the post |
|---|---|
| Does a human read every diff? | No. "Did a human read the code?" is treated as an imprecise proxy for "what could go wrong, and which check should catch it?" |
| What is the goal? | Most PRs merge with at most one human in the loop (who can be the author), with no rise in reverts or incidents |
| What changed in volume? | Changes landing per day in Anthropic's monorepo went from about 2,500 in May to more than 30,000 in September |
| What changed in quality? | Merged Claude Code PRs more than doubled June to September; reverted share fell by more than 40 percent |
| Who decides risk? | A classifier reads the change and sets the tier, not the author |
| Can a bot approve? | An agent's approval never counts as a person's |
| What is the guardrail metric? | Revert and incident rates |
Why review had to change
Claude Code lives in its own repository, separate from the monorepo, but it sees the same pressure: when agents write code, the number of changes goes up fast, and line-by-line manual review becomes close to impossible. Anthropic frames code review as doing two jobs: finding and fixing issues before they ship, and building shared understanding of the codebase across the team.
That framing matters because it explains the design. Review used to be a gate at the end of the road: write code, open a PR, wait for a colleague. Now it runs continuously, "more like spellcheck while you write," and most changes have been reviewed and fixed by Claude at least once before a human is asked to look.
This lines up with an argument we covered recently in AI coding agents produce more code, not more software: review capacity, not typing speed, is the bottleneck. Anthropic's post is a first-party answer from a team living inside that bottleneck.
The scarce resource: human time and attention
Anthropic counts human time on both sides: the time people spend reviewing, and the time they spend fixing what bad code breaks. Cutting the first does not help if the cost simply reappears in the second.
To measure it, the team tracks human approvals per PR (median and 95th percentile), human comments, and how long a PR waits on a person. Reverts and incidents are the guardrail. If those rise, the team has "only moved" the cost rather than saved it.
The six layers
1. Verify the work before anyone looks
Most review now happens before a PR exists. Claude is given something it can run, such as tests, a build, or a screenshot to compare to a design, and is asked to show output instead of saying it is done. A subagent then reviews the diff with fresh context. Engineers also run internal skills before opening a PR: one hunts for bugs, one simplifies the diff, one checks behavior end to end.
The post quotes Claude Code's creator Boris Cherny, who has called giving Claude a way to verify its work probably the most important factor for good results, estimating it makes the final result two to three times better. For more on steering the agent with files, see our guide to CLAUDE.md, skills, hooks and subagents.
When the automated reviewer keeps flagging the same thing, the team fixes it at the source: in a skill, a lint rule, or an instruction file.
- CLAUDE.md tells Claude what the project is: stack, conventions, goals and non-goals. Every review loads it, so Anthropic keeps it short and points to other docs.
- REVIEW.md, written by code owners, tells the reviewer what matters in their part of the code. Anthropic says good ones are short, define what failure looks like (for docs "it lies," for config "it misroutes"), cap nits, list paths to skip, ask for a file and line as evidence, and require a summary that starts with a count and says plainly when nothing needs fixing.
2. AI review on every pull request
Every PR gets a Claude review before a person looks. It reads the diff against the whole repository and the PR's stated intent, and asks whether the change solves its problem, fits the system, or breaks something else. The public product, Code Review for Claude Code, is described as generally available on Team and Enterprise plans, and /code-review runs a lighter version locally. We covered an earlier cloud-based variant in Claude Code ultrareview.
Anthropic reports that when it launched the research preview, the share of internal PRs getting substantive review comments rose from 16% to 54%. Most PRs over 1,000 lines get findings; most small ones come back clean. Admins set each repo to Quick, Standard, or Deep.
Findings are verified before humans see them. Several agents hunt for bugs at the same time, then a separate group votes on each finding, and it is only posted if enough agree it is real. Style-only, diagnostic, and cleanup findings are dropped, a filter the team A/B tested on its own PRs. Comments are tagged Important, Nit, or Pre-existing, so an old bug does not look like the author's fault. Every finding must be answered: fix it, or resolve the thread with a reason.
3. Security review that can block
Security gets its own automated review, and a PR cannot merge while any finding from the bug review or the security review is still open. A later commit that fixes the issue clears the finding on its own. Anthropic points to the open-source security review GitHub Action and the /security-review command for the same setup. If you want to go deeper on securing agent workflows, see how Anthropic's open-source scanner helps maintainers.
4. Automated checks that block
Lint, type checks, tests on every platform, and a build. A typical CLI pull request 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 on it.
5. Human approval, scaled by risk
| Risk | Examples | Human approvals |
|---|---|---|
| Low | Docs, copy, internal-only features, additive changes behind a flag | None once automated review and security checks are green |
| Medium | Ordinary product changes; sensitive areas such as caching, the auto-updater, system prompts | One person |
| High | The highest-risk code, plus a small set of paths that always need two people | Two people |
Several details stand out. The change sets the tier, not the author: a classifier picks the tier, and a second classifier asks whether this particular change needs another person even when its tier says it does not. Paths owners list as sensitive, and any CI workflow file, always need a person. Only authors on the repo's trusted list get the lighter paths. On an agent-written PR, the person directing the agent counts as one of the required reviewers. An approval covers one specific commit, so if an agent pushes new commits or someone hand-resolves a merge, approval must be given again.
6. Merge queue, flags, and gradual release
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 heavy internal use often surfaces regressions before users see them. Public releases go to the latest channel first while stable trails.
The last layer: detect and roll back
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. Anthropic is candid about a gap: noticing a bad merge still depends on the author and on-call as well as revert and incident dashboards. There are no circuit breakers yet that tighten approval when those numbers move, and engineers want them before more code moves to zero-human merges.
How Anthropic keeps the AI reviewer good
The reviewer improves 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 "any incident is now an eval."
Noise is measured by watching what people do with comments: fixed, called wrong, called intentional, or judged unimportant. 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. The written priority is catching real bugs first and cutting review rounds second.
Noise costs more when the author is an agent. A person waves off a nit in seconds; an agent fixes it, which means another commit and another round.
The fifty-round loop
Claude Code review rounds shown as a lens inspecting one changed tile in a larger mosaic
Review also has to converge. 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, about 59% was code present since the reviewer's first pass: it was finding a few more old bugs each round, not new ones. The fixes, per the post:
- A round cap: after three rounds, the reviewer asks the author to reconsider the approach
- Diff-only re-review after the first few passes
- Flag the class of bug, so the author fixes every instance
- No repeats of findings already posted
Review agents also run nightly over existing code to catch old bugs before they surface elsewhere. This is the same loop pattern we described in loop engineering for coding agents, with a hard stop added.
Where humans stay in the loop
Anthropic lists the decisions it keeps for people: whether to build something at all (direction, taste, scope), risky code like billing, the auto-updater and CI workflows, architecture that sets a pattern others will copy, reading the evidence (test output, the command that ran, a screenshot, the reviewer's findings), and owning the outcome. A person is accountable for every change that ships, whoever typed it.
What about learning the codebase?
If machines read most diffs, how does anyone learn the code? Anthropic's answer is informal: nobody holds a complete mental model of Claude Code, and the team does not think anyone needs to. When someone wants to understand a module, they ask Claude to write an explainer for that slice, which takes minutes and reflects the code as it is today. Some engineers have Claude build a small visual artifact for it. The post argues this teaches more than reading a one-line copy change ever could. Open Slack channels, where everyone sees what others build, supply the rest.
"You land it, you own it"
If you land a small or medium change and something goes wrong, the norm is that you usually fix it. Anthropic lists what makes that safe: small changes that are easy to debug and revert, reversibility through flags and staged releases, blast radius setting the bar for scrutiny, and fast regression signals from telemetry and internal use. It is explicitly not about blame; owning the fix means you have the most context, and incident reviews examine the system.
What to do on your team
Anthropic ends with an adoption list. Condensed:
- Before the PR: give your agent checks it can run, listed in a short CLAUDE.md, with hooks for formatters and linters. Run
/code-reviewand/security-review, or a fresh-context subagent. - On every PR: require CI and add Testing, Risk and How to revert to the template. Add an AI reviewer on one repo, tune REVIEW.md for a few weeks, then widen. Require every review thread to be resolved. Cap review rounds.
- Approval: write risk tiers set from the change, start strict and loosen with evidence. Use CODEOWNERS and branch protection so auth, billing, CI and installers always need a person. Never let a bot replace a required human, and dismiss approvals on new commits.
- Merge and after: merge queue, flags, internal use first, staged releases, one-step rollback. Turn incidents into an eval set and rescore the reviewer whenever prompts, tools or model change. Measure human time, with reverts and incidents as the guardrail.
If you are earlier in the journey, our guide to Codex Auto-Review shows a rival approach to reviewer agents, and the Postgres 19 delay over AI code review bugs is a cautionary example of what happens when review capacity is overwhelmed.
What to be careful about
The figures here are Anthropic's own, from its own team and codebase, and the post does not publish the underlying revert counts or a baseline for the comparison period. "More than doubled" and "fell by more than 40 percent" are directional claims, not a reproducible study. Claude Code is also a product Anthropic sells, so the post doubles as a case for its Code Review feature. The company's own admission of the missing circuit breakers is the most useful honesty signal in the piece.
For smaller teams, the transferable parts are cheap: a short CLAUDE.md, a REVIEW.md written by whoever owns the code, a round cap, and a revert-rate dashboard. The expensive parts (a risk classifier, a vote among review agents, an incident-derived eval) are worth building only once review volume justifies them.
Related reading
- Claude Code commands: complete reference
- Steering Claude Code with CLAUDE.md, skills, hooks and subagents
- Loop engineering for coding agents
- Claude Code ultrareview: cloud bug hunt
- AI coding agents: more code, not more software
- Codex Auto-Review guide
- Alibaba Open Code Review CLI
- Official: Anthropic's engineering post and the Claude Code repository
To stop agents from taking dangerous actions during automated review and merge flows, AgentBeam is the agent security platform from the explainx.ai team.
Details and figures are as published by Anthropic on October 15, 2026, and may change.