Code output doubles, reverts fall: how Anthropic stopped reading everything

On October 15, 2026, the team that builds Claude Code, Anthropic’s coding assistant, published an account of how it reviews its own code. The starting point is unusual: Claude writes about 90% of Claude Code’s code. Between June and September, the number of changes merged into the software more than doubled, and the share of them that had to be undone fell by more than 40%. Output rose while the error rate dropped, because the team stopped asking “did a human read it all?” and asked instead which check, automated or human, should catch which mistake.

Twice as many changes, a revert share down 40%

A software team does not edit its product directly. Every change goes through a pull request, a proposed change that waits to be reviewed and then merged into the main code. When a merged change breaks something and is taken out, that is a revert. These are Anthropic’s two counters.

The drop applies to the share of changes reverted, not to their number. Taking the announced thresholds as they stand (volume times two, share times 0.6), the number of reverts would have grown by about 20% on a doubled volume. That calculation is ours; Anthropic does not publish the figure. The result is this: volume doubled without reverts keeping pace.

Nobody can read everything anymore: 30’000 changes a day

Anthropic keeps most of its code in a single large repository. In May, about 2’500 changes were merged into it each day. In September, more than 30’000.

At that pace no human reads every line. The team drew the consequence: “did a human read the code?” is, in its view, an imprecise proxy. The right question is what could go wrong, and which check should catch it. The scarce resource is no longer code, it is human attention. The goal becomes that most changes merge with at most one human in the loop, who can be the author.

The guardrail fits in one sentence: if reverts or incidents rise, human time has not been saved, only moved from reviewing to cleaning up. Efficiency is therefore measured at the end of the process. The team tracks human approvals per change, time spent waiting for a person, and, as a brake, reverts and incidents.

Seven layers of control, each catching what the others let through

1. Work verified before it is proposed. Claude is given a way to run what it writes (tests, a build, a screenshot to compare against the design) and must show the output instead of announcing it is done. Boris Cherny, who created Claude Code, estimates this improves the final result two to three times. A second agent, starting from a blank page, reviews the change.
2. An agent review on every change. Several agents hunt for bugs in parallel, another group votes on each finding, and only findings that reach agreement are posted. Each must be fixed or closed with a reason.
3. A security review that blocks. While a finding is open, the change does not merge.
4. Mandatory automated checks. Code style, types, tests across platforms, build. The form for each change asks how it was tested and how to undo it.
5. Human approval scaled to risk, detailed below.
6. A merge queue, then a gradual release. The queue reruns every check on the latest code. The new feature reaches Anthropic’s own employees first, behind a switch that turns it on or off.
7. Fast detection and rollback. The switch turns a feature off without a new release. Each week, the on-call team asks which layer should have caught each incident.

Risk	Examples	Human approvals
Low	Documentation, copy, internal features, additions behind a switch	None, once automated and security checks are green
Medium	Ordinary product changes, sensitive areas (caching, auto-updater, model instructions)	One person
High	The riskiest code	Two people

A classifier sets the tier from the change itself, not from its author. Some files, such as those that drive the automated checks, always require a person.

Two rules to copy first

The first: an agent’s approval never counts as a person’s. An automated review can clear a low-risk change; it does not fill a slot that requires a human. The second: whoever prompted the change answers for it, as if they had typed the code themselves. On an agent-written change, the person directing the agent counts as a required reviewer. An approval also covers one specific version: an addition it has not seen needs a new one.

The reviewer is reviewed too

The automated reviewer improves in a loop. Each past incident becomes a test case, confirmed by an expert, and the reviewer is scored on all of them every day. A new problem appeared: an agent that writes and an agent that reviews can keep each other busy forever. The reviewer flags an error, the agent fixes it, the reviewer finds another. One change went through more than 50 rounds overnight before a human stopped it by hand. Now, after three rounds, the reviewer asks the author to step back and rethink the approach.

Measure (Anthropic)	Before	After
Changes receiving substantive comments	16%	54%
Changes passing in a single review round	65%	78%
Changes needing five rounds or more	8.9%	1.5%
Average number of reviews before passing	2.08	1.32

Humans have not gone away. They decide whether to build a feature at all, review risky code (billing, the auto-updater, control files), judge architecture choices that others will copy, read the evidence (test output, screenshots, reviewer findings) and answer for outcomes.

It is not a new idea: machines have been checking machines for a long time

Nobody checks every packet crossing the internet by hand. The TCP protocol attaches a checksum to each packet and asks again for one that arrives damaged or does not arrive. A server’s memory corrects a flipped bit by itself through error-correcting codes. A database writes every change to a log that a standby server replays, while other processes watch it. Double-entry bookkeeping, more than five centuries old, records each transaction twice, as a debit and a credit, so that the books must balance. In 1948, Claude Shannon showed that a message can be sent reliably over a noisy channel provided the right redundancy is added.

These systems were never made reliable by having a person inspect every step. They were made reliable by having machines check machines, with checks designed by people. Code written by agents joins that tradition.

The bottleneck has moved

Writing faster moves the bottleneck to reading. In 2025, Faros AI analysed data from more than 10’000 developers across 1’255 teams. Those using AI heavily merged 98% more pull requests, but review time rose 91%, bugs per developer 9% and average change size 154%. The study finds no significant improvement at company level, in delivery throughput or in quality. Faros sells measurement tools and measures activity, not delivered value: these are correlations. They still describe the wall that teams hit when they speed up without rethinking review.

Anthropic’s method assumes a floor. The team can lighten human review because almost everything there is reversible: tests an agent can run, switches, gradual release, rollback within minutes. Without that, reviewing less is not an option. It also acknowledges a gap: it has no circuit breaker yet that tightens approval when reverts or incidents rise, and its engineers want one before more code moves to merges with no human reviewer.

What we take from it for an organisation

• Measure waiting, not lines. The volume of code produced says nothing about efficiency. The time a change waits for a person, the approvals per change and the revert rate do.
• Build the floor before opening the tap. Tests an agent can run, switches, gradual release, fast rollback. Start strict, loosen when the evidence allows.
• Turn every repeated review into a rule, a test or a tool. And run the automated reviewer every day against the worst incident the organisation has had: nobody else owns that test case.
• Keep a person on the hook. In a regulated institution, the useful question is who approves each change and who answers for it. That is the four-eyes principle, applied to a reviewer that never sleeps.

Everyone can buy access to the same models. What sets organisations apart is rebuilding the process around them, and keeping people where judgment, trust and accountability cannot be delegated.