Here is a question. If AI writes 90% of your company's code, who reads and approves it?
On October 15, Anthropic's Claude Code team published its own answer on the official blog. The short version: they did not remove review. They stopped asking "did a human read it?" and started asking "what could go wrong with this change, and which check — automated or human — should catch it?"
Start with the numbers. Between June and September, merged pull requests to the Claude Code codebase more than doubled. Over the same period, the share of changes that had to be reverted fell by more than 40%. More code, merged more safely.
Why the question had to change
In Anthropic's monorepo, changes landing per day climbed from roughly 2,500 in May to more than 30,000 in September. Claude Code lives in its own repository, but the pressure is the same.
[May] ~2,500 changes per day
[Sep] 30,000+ changes per day
At that scale, line-by-line human review is close to impossible.
Remove it, and quality collapses. So they changed the question.
The blog names two jobs of code review:
- Find and fix issues before they ship
- Build shared context and codebase understanding across the team
Most of the post is about the first. But the second gets an answer near the end.
The key reframing is this sentence: "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?" Pick that question and the timing changes too. Review used to be a gate at the end of the road: write the code, open a PR, wait for a colleague. Now it runs continuously, more like spellcheck while you type. Most changes have already been reviewed and fixed by Claude at least once before a person sees them.
The scarce resource is human time
The goal is explicit: most pull requests in the Claude Code repos (the CLI, the desktop and web apps, the mobile apps) should merge with at most one human in the loop — who can be the author — with no increase in reverts or incidents.
There is an important distinction here. Human time runs on two tracks.
cost of human time = (time spent reviewing) + (time spent fixing what bad code broke)
Cut only the first and the second grows: you did not save time,
you moved it. So the key metrics pair human approvals with
revert and incident rates.
The measurement is concrete: 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, you have not saved human time — you have only deferred it.
The life of a change: six layers
Here is the blog's own diagram, transcribed.
[BEFORE THE PR]
1. Verification : Claude runs the tests, build and linter.
A second agent reviews the diff in fresh context.
Internal skills add bug hunts, diff simplification,
and end-to-end checks
[ON EVERY PR]
2. Required CI : lint, types, tests across platforms, build,
packaging. Red blocks the merge
3. AI review : several agents hunt for bugs in parallel;
a separate group votes on each finding.
Only enough agreement gets posted.
Style and cleanup comments are dropped
4. Security : a separate pass. Any open finding from either
review blocks the merge
5. Risk-based approval: a classifier sets the tier -> 0, 1 or 2 people
[MERGING]
6. Merge queue : checks run again on the latest main with
the change applied
[AFTER THE MERGE]
7. Flags and gradual release: internal first, then the latest
channel, with stable trailing it
8. Watch, fix forward or roll back: flags turn off without a deploy;
broken builds get reverted
The point of the structure is "layers, not one gate." Each layer catches some problems and misses others. Few get through all of them, and rollback handles the rest.
Layer by layer
1. Verify before anyone else looks
Most review happens before a PR exists. The method is simple: give Claude something it can run — tests, a build, or a screenshot to compare against the design — and ask it to show the output instead of saying it is done.
Boris Cherny, who created Claude Code, has called giving Claude a way to verify its work probably the most important thing for getting good results. He estimates it makes the final result two to three times better. Verification looks different by domain: a bash command, a test suite, or trying the app in a browser or phone simulator.
When the automated reviewer keeps flagging the same thing, the fix goes to the source — the skill, a lint rule, or the instructional files.
CLAUDE.md : what the project is (stack, conventions, goals, non-goals)
kept short in large codebases, pointing to other docs.
Loaded on every review
REVIEW.md : written by code owners. Tells the reviewer what matters
in their part of the code
what failure looks like (for docs: "it lies";
for config: "it misroutes"), a cap on nits, paths to skip,
and a demand for file-and-line evidence over guesses
2. AI review on every pull request
Every PR gets a Claude review before a person looks. It reads the diff against the whole repo and the PR's stated intent and asks: does the change solve its problem, fit the system, or break something else?
During the research preview, the share of internal PRs receiving substantive review comments went from 16% to 54%. Most PRs over 1,000 lines get findings; most small ones come back clean. Each repo is set to Quick, Standard or Deep, with Deep reserved for places where one missed bug costs more than the extra review time.
The noise-reduction machinery is the impressive part. Findings are verified by other agents before humans see them.
[parallel hunt] several agents look for bugs at the same time
|
[voting] a separate group votes on each finding.
It is only posted if enough agree it is real
|
[filter] style, diagnostics and cleanup comments are dropped
(the team A/B tested these filters on its own PRs)
|
[post] inline comments sorted by severity
each tagged Important / Nit / Pre-existing,
so a bug the PR did not introduce does not look
like the author's fault
In the blog's words, "every finding has to be answered." Fix it, or close the thread with a reason. Often an agent picks up the fix overnight, so the author returns to a PR that has already been through another round.
3. Security review that can block
Security gets its own automated pass. A PR cannot merge while any finding from the bug review or the security review is still open. Fix it or close the thread with a short reason, which is how a false positive is cleared. If a later commit fixes the issue, the finding clears on its own. The same setup is available through the open-source security review GitHub Action or the /security-review command.
4. Approval scaled by risk
This is the table most teams will want to copy.
| Risk | Examples | Human approvals |
|---|---|---|
| Low | Docs, copy, internal-only features, additive changes behind a flag | None required once automated review and security checks are green |
| Medium | Ordinary product changes, plus sensitive areas such as caching, the auto-updater or system prompts | One person |
| High | The highest-risk code, plus a small set of paths that always need two people | Two people |
The rules that matter:
- The change sets the tier, not the author. A classifier reads the change and picks the tier. A second classifier asks whether this particular change needs another person even when its tier says it does not.
- Paths owners have listed as sensitive, and every CI workflow file, always need a person.
- Only authors on the repo's trusted list get the lighter paths. An agent's approval never counts as a person's.
- Whoever prompted the change is on the hook. On an agent-written PR, the person directing the agent counts as one required reviewer.
- An approval covers one specific commit. If new commits land that the system cannot vouch for — an agent's push, a hand-resolved merge — the approval has to be given again.
5. The merge queue and flags
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 their heavy use surfaces regressions before users see them.
6. Fast detection, fast rollback
Mistakes still get through, so the last layer is about catching them fast. Flags turn off without a deploy, a weekly on-call rotation runs, and incident reviews ask which layer should have caught the issue.
There is a candid admission here too: they do not yet have circuit breakers that tighten approval when the revert and incident dashboards move, and engineers want them before more code moves to zero-human merges.
The loop that makes the reviewer better
The process keeps improving as it runs, and this is where the most valuable practical detail lives.
[incident or revert] -> [expert-checked case] -> [added to the eval set]
^ |
[change the reviewer] <- [score went up?] <- [daily run over every case]
(rescore on every prompt, tool or model change)
Past PRs that caused incidents are collected with their fix-forwards and reverts, and engineers who know that code confirm each bug. The reviewer runs against that set daily.
Noise is measured by watching what people do with the comments: they fixed it, said it was wrong, said the behavior was intentional, or decided it did not matter. The reviewer is also run on PRs known to be clean, counting how often it reports something that would have led someone to a harmful change. The stated priority: catch real bugs first, cut review rounds second.
And then a very concrete failure mode.
An agent author and an agent reviewer can keep each other busy forever.
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 that had been there since the reviewer's first pass.
= it was not finding new bugs, it was finding a few more old ones
each round.
So re-review changed. After three rounds, the reviewer asks the author to step back and reconsider the approach. After the first few passes, only the new diff is re-reviewed. Flag the class of bug so the author fixes every instance, not one line. Do not repeat findings already posted. The results:
| Metric | Before | After the convergence work |
|---|---|---|
| Pass after one review and fix round | 65% | 78% |
| Need five or more rounds | 8.9% | 1.5% |
| Mean reviews to pass | 2.08 | 1.32 |
Where humans stay in the loop
Human attention moves to the decisions machines are bad at.
1. Should we build this at all - direction, taste, scope
(a team that declared its review bottleneck solved still kept
human review for changes from outside the team)
2. Risky code - billing, the auto-updater, CI workflows
3. Architecture that sets a pattern others will copy
4. Reading the evidence - test output, the command that ran and
what it returned, a screenshot, the reviewer's findings
(if you cannot say what the checks would miss, ask for a real
review rather than a quick approval)
5. Owning the outcome - a person is accountable for every change
that ships, whoever typed it
The second job of review — sharing context — gets its answer here. Nobody on the team keeps a complete mental model of Claude Code, and nobody needs to. When someone wants to understand a part of the codebase, they ask Claude to write an explainer for exactly that slice. It takes minutes and reflects the code as it is today.
And one team norm lands like a title. "You land it, you own it." Land a small or medium change and something still goes wrong, and you usually fix it. This does not go badly because changes are small and easy to revert, blast radius sets the bar, and regressions surface fast through telemetry. It is ownership, not blame.
Conclusion: how to adopt this with your team
The blog hands over a checklist you can use today.
[BEFORE THE PR]
[ ] Give your agent checks it can run (a short CLAUDE.md,
plus hooks that run formatters and linters)
[ ] Run /code-review and /security-review locally
(or a fresh-context subagent review)
[ ] Add a REVIEW.md and move repeated comments into it
[ON EVERY PR]
[ ] Require CI. Add Testing / Risk / How to revert to the PR template
[ ] Add an AI reviewer to one repo, tune REVIEW.md for a few weeks,
then widen
[ ] Add automated security review, and require every review thread
resolved before merge
[ ] Match review effort to risk (Quick / Standard / Deep)
[ ] Cap review rounds; after the first few, re-review only the new diff
[APPROVAL]
[ ] Write down risk tiers, set from the change rather than the author;
start strict and loosen with evidence
[ ] Use CODEOWNERS and branch protection so auth, billing, CI and
release workflows, and installers always need a person
[ ] Never let a bot's approval replace a required human's;
dismiss approvals on new commits
[MERGE AND AFTER]
[ ] Merge queue, feature flags, internal use first, staged releases,
one-step rollback
[ ] Turn incidents and reverts into an eval set, and rescore the
reviewer whenever its prompts, tools or model change
[ ] Measure human time, with revert and incident rates as the guardrail
One line captures it.
Stop asking "did a human read it?"
Ask "what could go wrong, and who catches it?"
That shift turns code review from surveillance into design. Saying "we automated review" undersells it; saying "we built a verifiable system" is more accurate. If you want the background on harness engineering, continue with What Is Harness Engineering?.
Further reading
- Claude Code for Real Projects: What Actually Works
- Org-Wide Code Review and Copilot Billing
- Kore AutoLoop: A Pattern for Agent Evaluation Loops
References
Go deeper with a course
To move those layers into your own repo, start by understanding what Claude Code reads and which tools it uses. Wire up CLAUDE.md and REVIEW.md, hooks and subagents, and the approval rules yourself, and you will feel how review becomes a harness.