Claude Writes 90% of Claude Code. Who Reviews It?

Anthropic's answer to the question in the title, published on its engineering blog this week: mostly, other models do. Claude writes about 90% of Claude Code's own code, and from June to September, merged pull requests more than doubled while the share that had to be reverted fell by more than 40%. Review did not disappear. It was rebuilt as seven layers of checks, with human attention reserved for five kinds of decisions.

The part worth reading slowly is not the seven layers. It is what happened when an AI author met an AI reviewer: one CLI pull request went through more than fifty rounds of review overnight before its author stopped it. When the team ran git blame on what the reviewer kept flagging, about 59% of it was code that predated the reviewer's first pass. The reviewer was not finding new bugs. It was rediscovering old ones, a few per round, forever. That failure mode, and how they fixed it, is the part most coverage of this post will skip.

Facts below are from Anthropic's post, fetched October 17, 2026. Disclosure: Wallaby Token sells API access to open-weight models, and we run multi-model AI reviews on our own work, which is why we read this one closely. Anthropic's post is about its internal process; nothing in it requires you to use their tools.

The scale that forced the redesign

In Anthropic's monorepo, changes landing per day went from about 2,500 in May to more than 30,000 in September. Claude Code lives in its own repositories, but the pressure is the same: at that throughput, line-by-line human review is not a bottleneck, it is a fiction. People either become the queue or start rubber-stamping.

So the team changed the question. Instead of "did a human read the code," they ask "what could go wrong with this change, and which check, automated or human, is the right one to catch it?" The target state: most PRs merge with at most one human in the loop, sometimes only the author, with no increase in reverts or incidents. The guardrail metrics are revert and incident rates, not review coverage. If those rise, they have not saved human time; they have moved it.

The seven layers, briefly

A change's life, from laptop to users:

Verification before the PR exists. Claude has to show evidence (test output, a build, a screenshot) instead of claiming done, and a fresh-context subagent reviews the diff. Boris Cherny, who created Claude Code, calls giving the model a way to verify its work probably the single most important factor, worth a two-to-three-times improvement in results.
AI review on every PR. Several agents hunt for bugs in parallel, then a separate group of agents votes on each finding before it is posted. Style-only findings get dropped. Everything that survives is tagged Important, Nit, or Pre-existing, and every finding must be fixed or answered. When the research preview launched, the share of internal PRs getting substantive review comments went from 16% to 54%.
Security review that blocks. Unresolved security findings stop the merge, full stop.
The usual automated gates. Lint, types, cross-platform tests, builds. The PR template demands "how was this tested" and "how to revert," and a person signs off on both.
Human approval, scaled by risk. Docs fixes need nobody once the automated layers are green; ordinary product changes need one person; the highest-risk paths need two. Two rules deserve to be quoted: an agent's approval never counts as a person's, and an approval covers exactly one commit. New commits require re-approval.
Merge queue, feature flags, gradual release. New behavior ships to employees first, then to a latest channel, with stable trailing behind.
Fast detection, fast rollback. Flags turn off without a deploy, and every incident review asks the same question: which layer should have caught this?

The loop: when the reviewer never stops

Here is the problem that only exists when both sides of the review are models. A human reviewer gets tired and walks away. An AI reviewer does not. A person can wave off a nit in seconds; an agent author fixes it, which means another commit, which triggers another round. Anthropic had gotten used to running several review rounds by default, because each pass caught something new. The 50-round PR was the bill coming due.

The git blame result is the tell. If 59% of flagged code predates the first review pass, marginal findings per round are mostly archaeology. The fix has four parts:

A round cap. After three rounds, the reviewer stops and asks the author to reconsider the approach, on the theory that a change needing four rounds of patching may be the wrong change.
Diff-only re-review. After the first passes, the reviewer only sees what changed, so old code stops generating new comments.
Flag the class, not the line. If the same bug appears five times, the finding names the pattern, and the author fixes every instance.
No repeats. A finding already posted cannot be posted again.

If you are wiring an AI reviewer into your CI this quarter, copy this section first. The failure it prevents is silent: nothing errors, the bills just grow and the PRs never converge.

The reviewer is a system under test, not a tool

Two more practices are worth stealing, and both are about treating the reviewer itself as a system under test.

Incidents become the eval set. The team collected past PRs that caused incidents, had engineers who know the code confirm each bug and where it lived, and now runs the reviewer against that set daily. A change to the reviewer's prompt, tools, or model only ships if the score improves. This is the same discipline as pre-registering a kill rule for a product: we did that publicly for one of ours, and the uncomfortable version of the lesson is identical. If you cannot say what would prove your reviewer worse, you do not have a reviewer, you have a vibe.

Noise is measured by what humans do with the comments. Every reviewer comment is sorted by the response it got: fixed, wrong, intentional, or did not matter. They also run the reviewer on PRs known to be clean and count how often it would have pushed someone toward a harmful change. Catching more bugs is easy if you flag everything; the hard part is doing it without training authors to ignore you. We ran into the same trade-off from the other side when we sent one spec to four isolated AI reviewers: convergent findings were signal, but they were still opinions, not validation, and each one needed a human ruling.

What humans still do

The list Anthropic keeps for people is short and worth reading as a job description for senior engineers in 2027:

Should we build this at all. Direction, taste, scope. Agents make starting cheap, which makes "no" more valuable, not less.
Risky code. Billing, the auto-updater, CI workflows: anything where a miss is expensive gets people, plural.
Architecture that sets a pattern. The code others will copy gets human eyes, because the copies will not get them.
Reading evidence. Test output, screenshots, the reviewer's findings. The skill moved from reading diffs to reading receipts.
Owning the outcome. Every shipped change has an accountable person, whoever typed it. Their norm: you land it, you own it, and owning it is not blame.

One quiet casualty: review's second job, spreading codebase knowledge across the team. Their answer is that nobody holds a complete mental model of Claude Code anymore, and nobody needs to. When you need to understand a slice of the codebase, you ask Claude to write an explainer of that slice, generated fresh. A one-line copy change teaches you nothing, the post argues; an explainer for the module you are about to touch teaches a lot.

What to copy this week

You do not need Anthropic's scale for the three cheapest layers:

Write the two files. A short CLAUDE.md (what the project is, conventions, non-goals) and a REVIEW.md per area (what failure looks like here, a cap on nits, paths to skip, and a demand that every finding cite file and line). When your reviewer flags the same thing twice, fix the file, not the code. This is the layer with the best ratio of effort to effect in the whole post.
Write down risk tiers before you need them. Tier from the change, not the author. Keep the light paths for people you trust, never count a bot's approval as a person's, and expire approvals on new commits.
Cap the rounds. Three rounds, then step back and reconsider the approach. Re-review only the diff. Flag bug classes, not lines. This one sentence of policy is what stands between you and the 50-round overnight PR.

And one honest note from our side of the fence: every one of these layers is inference. Parallel bug-hunting agents, verifier votes, nightly sweeps of old code, daily eval runs. The token meter spins at every layer, which is why the cost curve of your review stack is worth understanding before you build it. Our own September bill shows what real agent workloads cost on an open-weight model, and the Kimi K3 pricing page has the current rate card if you want to price a review loop of your own.

Where to go next

Deeper: We pre-registered a kill rule for our own product. It fired. — the same "incidents as evals" discipline, applied to a product instead of a reviewer.
Sideways: We sent the same spec to four AI reviewers — what multi-model review catches, and where it stops being evidence.
Forward: Can Claude Code actually use other models? — if you want your review agents on an open-weight endpoint, that is the working setup.