This week Anthropic published how the Claude Code team does code review — a fair question, since Claude writes about 90% of Claude Code's code. The scale first. Changes landing in their monorepo went from about 2,500 a day in May to more than 30,000 in September. From June to September, merged pull requests to Claude Code's own codebase more than doubled, while the share that had to be reverted fell by more than 40 percent. Nobody read 30,000 changes a day. So what replaced reading?
Layers, and a better question. They stopped asking "did a human read the code?" and started asking what could go wrong with this change, and which check — automated or human — is the right one to catch it. A change now passes through verification before a pull request exists (the agent must show test output, not say "done"), an AI review on every PR whose findings are voted on by other agents and must each be fixed or closed with a reason, a security review that can block merging, ordinary CI, human approval scaled by the change's own risk — none for a flagged, additive change, one person for ordinary work, two for the highest-risk paths — then a merge queue, feature flags and a staged release, and underneath it all, fast detection and fast rollback. Review stopped being a gate at the end of the road and became something closer to spellcheck: continuous, mostly machine, spending human attention only where risk concentrates.
I read this with some recognition. I ship with agents as a team of one, and my verification stack grew the way theirs did — by failure, not by design. Mechanical checks first. Then fresh-context adversarial audits that read the artifact's actual bytes and may not trust any fact the producer supplied. Then benchmarks relative to the current winner, never absolute. Then an owner veto whose reasons are converted into permanent rules. Then arena metrics, the only real falsification. And plumbing underneath: a content-addressed publish gate, so the bytes that were audited are the bytes that ship — the same instinct as my eval harness, which imports only the agent core's public facade and runs the byte-for-byte production loop, so a bug found in evaluation is a real bug, not an artifact of a reimplementation. Different scale, same skeleton: no single check is trusted, and every mechanism belongs to exactly one layer.
Two of their moves are moves I already have. The first: "any incident is now an eval." They collected the pull requests that caused incidents, together with their fixes and reverts, and the reviewer is scored against that set every day — and rescored whenever its prompts, tools or model change. I reached the same place from the other direction: an audited ledger is a golden set that is already accumulating, because every passed artifact plus its verdict is a labeled case. The discipline I was missing is exactly the one they run — when a rule or a skill changes, re-run a slice of the ledger and block on regression, not on absolute thresholds. The second move: fix the source, not the finding. When their reviewer keeps flagging the same thing, the fix goes into CLAUDE.md, a lint rule, or the skill that produced the code. When one of my auditors catches something the others missed, the catch is promoted into the rule text every future auditor reads. A ratchet, in both shops.
They also publish their failure mode, which I appreciated. An agent author will patiently fix every nit an agent reviewer raises, so the two can keep each other busy forever — one pull request went through more than fifty rounds of review overnight. Worse, when they checked what the reviewer kept flagging, about 59 percent of it had been sitting there since before the reviewer's first pass: each round was surfacing a few more old bugs, not new ones. Their answers are a round cap, diff-only re-review, flagging the class of bug instead of the line, and never repeating a finding. And noise itself is measured by outcome: every reviewer comment is sorted by what the author did with it — fixed it, said it was wrong, said it was intentional, decided it didn't matter. That is the same refusal to trust a single confident reading that makes me fan a prompt out to hundreds of parallel runs and judge it by the tally, not by how one answer looks.
What does not transfer to a team of one is the part they are most honest about leaving unfinished. Code review has a second job — spreading knowledge of the codebase across a team — and a solo builder simply does not have it; their own replacement, asking the agent to explain exactly the slice you are about to change, works at least as well alone. The harder gap is the human layer. Their risk table ends in people: a second approver for dangerous paths, a trusted-author list, and the admission that they do not yet have circuit breakers that tighten approval when revert rates move. Mine ends in one person's attention — the person who directed the agent, who counts as a reviewer under their rules, and who is also the only available second pair of eyes. The owner veto is my circuit breaker. It is manual and it does not scale, but unlike theirs, it exists.
"Did a human read the code?" was always a proxy question. At thirty thousand changes a day, and at one person's release cadence, the real work is identical: decide what each layer catches, fossilize every failure into the set that tests the layers, and keep one named person accountable for what ships. They phrase it as a team norm — you land it, you own it. On a team of one, it is not a norm. It is the org chart.
Source: "How the Claude Code team does code review," Anthropic, October 15, 2026 — all figures about their repository and process are theirs.