AI Moved the Bottleneck From Writing Code to Reviewing It

When a team adopts AI coding agents, the constraint moves. Writing code stops being the slow part, and reviewing and merging it becomes the slow part. The work does not disappear; it relocates, and it lands on the people who were already the scarcest.

Anthropic hit that wall harder and earlier than anyone, because they adopted harder and earlier than anyone. In October 2026 they published what they did about it, and the numbers are worth reading even though the solution is one you cannot buy.

The number that makes the point

From Anthropic's own engineering post:

"In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day."

Twelve times the merge volume in four months, because Claude writes the code now. Their main branch history runs close to 100 GB, a compressed working copy is over 25 GB, and they perform roughly 25 million CI checkouts a day.

Their answer was to replace git. They built an internal version control system called Scion, moved their monorepo off git in five months, and a team of seven people did it.

You cannot copy the solution, and they say so

This is the part most of the coverage skips. Scion is not a product, and Anthropic has been direct about why:

"Scion is by no means a suitable replacement for git for general use."

"it's difficult to offer Scion in a form that would be broadly useful to other organizations"

The design, they say, "really only make sense for truly enormous monorepos." If you are reading this and your repository is not approaching 100 GB of history, Scion is not a decision in front of you. There is nothing to evaluate and nothing to migrate to.

What transfers is the diagnosis, not the tool.

Source: Anthropic, Redesigning source control at Anthropic, read 16 October 2026.

The same shift, measured outside Anthropic

If this were only happening at Anthropic's scale it would be a curiosity. It is not.

DORA, Google's software delivery research program, published its read in March 2026 and gave the effect a name:

"The verification tax: Time saved writing is often re-spent auditing."

The same post describes where the cost lands:

"Velocity gains for an individual author frequently translate into a significantly increased cognitive load for the reviewer."

And the finding that should shape how you plan for this:

"higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability."

Both at once. More shipped, and more broken. That combination is the thing to design around, because optimizing only for throughput makes the second half worse.

Source: DORA, Balancing AI tensions, published 10 March 2026, read 16 October 2026.

What this looks like below Anthropic's scale

We run AI coding agents against our own repositories every working day. We are a small team, nowhere near 30,000 merges, and the same pressure shows up anyway in a smaller and more ordinary form. Here is what actually broke for us, and what we changed.

Concurrent agents trample a shared checkout

Two agent sessions working in the same checkout will overwrite each other's work, and the loser gets no error. The fix is boring and complete: one git worktree per concurrent session, so every session gets an isolated working copy against the same repository.

The cost nobody mentions is disk. Worktrees accumulate quietly, and a handful of them with installed dependencies will fill a laptop. Remove the worktree when the work merges, and never delete the branch as part of that cleanup.

Cleanup chained to a merge can undo the merge

Deleting a branch immediately after merging it can close the pull request as unmerged, depending on timing. We now confirm the merge commit exists on the main branch before any cleanup runs. It is a two-second check that prevents an hour of confusion.

The build catches what review cannot

During a bulk rename across our own site, a find-and-replace that was correct for URLs also matched the import paths that load each article's body, because those paths contain the same string. The build failed immediately with a module-not-found error and the problem was fixed in minutes.

The reason that is worth telling: the failure mode next to it is silent. An article whose body fails to load still renders its title, its metadata and its FAQ, with no article in the middle and no warning anywhere. One of those is caught by a machine in seconds. The other is caught by a human noticing, eventually.

As agents produce more changes per day, the share of problems that a person will notice goes down. The share a build can prove goes up only if someone builds the check.

A check that cannot go red is not a check

We run a daily job that compares what we have published against what is actually indexed. It is wired to fail the workflow and open a tracking issue when pages are missing, and we have watched it do exactly that.

That sounds obvious until you audit your own alerts. A check that has never failed is indistinguishable from a check that cannot fail. Before trusting one, make it go red on purpose.

Some failures produce no error at all

Our worst category is the silent one. A lead submitted through an ad form that never reaches the CRM generates no error anywhere: the ad platform reports it delivered, the CRM shows nothing, and the only signal is a person noticing days later. We ended up writing a watcher that compares the two systems directly and reports the mismatch, because nothing in either system would ever raise it.

Agent-generated work has the same shape. Success and silence look identical, so the only reliable signal is a check that compares what should have happened against what did.

What to do about it

What we do not know

Honest limits, because this is a shift in progress rather than a settled practice.

We do not know where the review bottleneck starts to bite as a function of team size, and neither source gives a threshold. Anthropic's numbers are from a company operating far outside normal conditions, and DORA's are correlations across a survey population rather than a rule about your team.

We also do not know whether the tooling category now forming around AI code review will absorb this problem or simply move it again. Every previous wave of delivery tooling made some work disappear and created new work somewhere else, and there is no reason to expect this one to be different.

What is well supported is the direction: generation capacity has grown faster than verification capacity, and the gap is where the delays and the instability live.

Where this touches us

We build and run AI systems for other companies, which means we hit this on our own work before we recommend anything about it. If you are adopting AI coding tools and your delivery process is starting to strain, the useful conversation is usually about review capacity and automated gates rather than about which assistant to buy.

That is the work our AI engineering and automation practice does, and it starts with what is waiting in your queue rather than with a tool recommendation.

Sources

Read on 16 October 2026. Both are primary documents from the organizations that produced the research.

• Anthropic, Redesigning source control at Anthropic
• DORA, Balancing AI tensions, 10 March 2026
• Git documentation, git-worktree