When AI Writes 90% of the Code, Who Reads It?
Anthropic previously shared a striking number: roughly 90% of the code in Claude Code was written by Claude itself. That raises an obvious question—someone still has to read the code, right? And who takes responsibility when things go wrong?
Last week, the Claude Code team laid out their answer in a blog post. The results of their code review pipeline: between June and September, merged PRs more than doubled while the rollback rate *dropped* by 40%. The work of reading code hasn't disappeared—but most of it has moved from humans to machines.
The post, written by Addy Osmani and colleagues and published October 15, is worth walking through in full, because it starts with a reframing.
Replacing the Question
Traditional code review does two things: catch errors before ship, and help teammates understand the codebase. After AI started writing code, the first job exploded in scale—daily landed changes in Anthropic's monorepo grew from ~2,500 in May to over 30,000 in September, a 12x increase. Reading every line is physically impossible.
The team's solution was to swap the metric. "Did a human read this code" is a crude proxy. The real question is: what could this change break, and which check—machine or human—is the right tool to catch it? Once the question changes, review's position changes too: from a gate at the end of the pipeline to a spell-checker that runs while code is being written. Most changes are already reviewed and fixed by Claude at least once before a human ever sees them.
The Life of a Change
Before a PR is even opened, changes pass a first gate. The team doesn't tell Claude "you're done"—it gives it things it can *run*: tests, builds, screenshots compared against design mocks—requiring it to show output. Then a separate subagent reviews the diff in a fresh context (no stale conversation polluting its judgment). Boris Cherny, creator of Claude Code, has said that giving the model a way to verify its own work may be the single most important thing for good results—he estimates it makes outcomes 2–3x better.
Once a PR opens, layers of checks queue up. CI runs as always; red blocks merge. AI review is the heavy hitter: multiple agents hunt for bugs in parallel, another set of agents votes on each finding, and only findings with enough votes get surfaced (style nits are dropped outright—these filters survived A/B testing on the team's own PRs). Surviving findings are ranked by severity, and each must be answered: fixed, or closed with a reason. Security review runs as a separate channel; unresolved findings there also block merge.
Then comes human approval, tiered by risk: zero humans for docs changes, one for normal product work and sensitive areas (caching, auto-updater, system prompts), two for the highest-risk paths. A classifier assigns the tier based on the change itself, not the author. A few lines are written especially firmly: agent approvals never count toward the human headcount; approvals bind to a specific commit, so any new push resets them; whoever directed the agent to write the code counts as a required reviewer.
Merging goes through a queue—all checks re-run against the latest trunk with the change applied, because two individually-passing PRs don't necessarily pass together. Deploys use feature flags: Anthropic employees get it first, then the latest channel, then stable. If something breaks, flags shut off in minutes, bad builds roll back directly, and a weekly-rotating on-call watches the dashboards.
Reviewing the Reviewers
The most honest part of this system is how they manage the quality of the AI reviewers themselves.
Every incident becomes a test case: an engineer confirms the bug is real and where it lives, then adds it to the collection. The review AI runs evaluation against the full incident history daily; anyone changing its prompt, tools, or model must re-score it, and the change only sticks if scores improve.
Noise gets its own measurement: track how humans handle each comment (fixed, marked false positive, marked intentional, marked doesn't matter), and run the review AI against known-clean PRs to count how many harmful changes it introduces. Priorities are written down: catch real bugs first, then reduce review rounds.
The most interesting problem is convergence. Agent writes code, agent reviews code—the two can loop forever: the reviewer finds a new nit each round, the author agent dutifully fixes it. It actually happened: one CLI PR got reviewed 50+ times overnight before the author manually stopped it. Running git blame, they found ~59% of what the reviewer kept flagging was old code from round one—the reviewer wasn't finding new bugs, it was digging up a few old ones each round. The team added a three-round cap (after which the author must step back and rethink), review of new diffs only, category-based tagging (fix all instances of a class at once), and a ban on re-reporting already-raised findings. After the fixes, one-pass approval rose from 65% to 78%, five-plus-round reviews fell from 8.9% to 1.5%, and average rounds dropped from 2.08 to 1.32.
What's Left for Humans
The post lists it clearly: deciding whether to do the thing at all (direction, taste, scope); reviewing dangerous code (billing, auto-updater, CI workflows—always humans); approving architectural patterns; reading evidence—test output, command returns, screenshots—and requesting a genuine deep review when it's unclear what the automated checks would miss; and finally, being accountable for outcomes, regardless of who typed the code.
Even review's second function—knowledge transfer—got rebuilt. No human holds the whole codebase in their head; to understand a module, ask Claude to write an explainer on the spot—minutes, and reflecting today's code, not last quarter's. Reading a colleague's one-line copy change line-by-line teaches less than reading an explainer for the module you're about to modify.
The culture matches: "you landed it, you own it"—when small-to-medium changes break, the person who landed them usually fixes them. The preconditions for this not spiraling are written in four lines: changes stay small, easy to fix and revert; everything is reversible, flags and rollouts measured in minutes; blast radius determines review density—expensive code gets more people and more checks; and this isn't blame-hunting—incident retrospectives look at systems only.
Where This Sits on the Line
Two days ago I wrote about Self-Healing Harnesses: agents can propose changes, but persistent approval authority stays with an external gate. The Claude Code review pipeline is the productized version of the same principle—proposal authority goes fully to machines (writing code, filling templates, overnight fixes), while approval authority is risk-tiered and kept with humans, and machine approval can never substitute for a human headcount. Assertions need enforcement is the same motif again: don't say "done," show output; findings need vote-based verification; reviewers get evaluated daily against the incident set. Even their pitfall fits the line—two agents looping fifty-plus rounds is a live specimen of review itself failing to converge.
The piece ends on its most restrained note. A colleague observed that slowing down does reduce error rates—mainly because you're doing less of everything; the team would rather find and fix problems faster. They admit the circuit breaker—automatically tightening approvals when alerts spike—doesn't exist yet, and engineers want it built before more changes go through the zero-human path. Ninety percent of the code is machine-written, but the words "zero human" still live in the wishlist column.
---
*Source: "How the Claude Code team does code review" (claude.dev, 2026-10-15, Addy Osmani / Morgan Westlee Lunt / Qing Wang). All figures come from the original: 90% AI-written code share, June–September PR doubling with 40% rollback reduction, monorepo daily changes 2,500 → 30,000+, review comment coverage 16% → 54%, convergence improvements 65% → 78% / 8.9% → 1.5% / 2.08 → 1.32 rounds, and Boris Cherny's 2–3x estimate.*