Anthropic 10x code merges
the review bottleneck

In May, Anthropic merged about 2,500 code changes a day. By September the daily figure passed 30,000. In five months output rose tenfold and the constraint moved: what slows this company down is no longer writing code, but review, merge and CI — the parts of the pipeline built for people. That shift changes what a buyer should ask when sizing up an agent rollout. Not how strong the model is, but whether each release step leaves a readable record.

Anthropic published the numbers itself

The figures come from an engineering post on 13 October, signed by the seven people on the company’s source control team. Daily merges went from roughly 2,500 in May 2026 to more than 30,000 in September. These are the company’s own readings rather than an industry survey, but their unit is time, and time is easier to check than a satisfaction score.

To carry that load, the team moved the entire monorepo off git and onto a version control system it built itself, code-named Scion, over five months. The scale readings that came with it: a main branch history of about 100 GB, compressed working copies above 25 GB, roughly 25 million CI checkouts a day, and by their own back-of-the-envelope conversion more than 600 PB of git traffic daily. At peak they ran several hundred internal git mirrors at once.

They also built the parts people touch: a code review interface, code search, and identity and permission management for source control. Those three sit exactly where a person stands in the pipeline — reading the change, finding its history, deciding who may push.

None of this describes a stronger model. It describes a pipeline that became the problem once output started flowing through it.

The company frames it the same way. Code is no longer the bottleneck for building systems or doing research; the bottleneck is developer infrastructure designed for human scale, meaning source control, build and CI. The post closes with a caveat of its own: the workload is unusual, and the team does not expect most organisations to hit the same wall soon.

Why the constraint lands on review

A code change reaches the main branch through three gates. Someone reads it. Someone decides whether it belongs. A machine applies the rules and lets it through. When generation gets cheap, the constraint drifts to those gates, because none of them scales with output.

A person can read only so many diffs a day, and that ceiling comes from attention rather than tooling. Review criteria live either in a document, which updates slowly, or in a senior engineer’s head, which does not copy — when that person is away, the gate is process alone. CI time comes out of a machine budget that costs money, a procurement cycle and someone to maintain it.

Put those three sentences together and the shape of a tenfold increase becomes predictable: output can rise exponentially, release can only rise linearly. The difference does not disappear. It queues, as waiting time, merge conflicts, and exceptions granted to get something in before a freeze.

That supports a testable prediction. The higher the share of code written by agents, the sooner the review queue and CI duration break — not the editor and not the model quota. The prediction fails when a release step’s output becomes a machine-checkable condition rather than a human judgement.

Three gates, three owners

Where a gate sits decides who owns it, and these lines get blurred in practice. Reading the change belongs to the team that wrote it, so capacity lands on an engineering manager’s plan. Deciding whether it may enter belongs to reviewers, so the criteria eventually land on architecture or a technical standard. The machine gate belongs to the platform team, and CI duration is their service level. The record of why a release was allowed is the one nobody wants written by someone else.

Blurred ownership has a typical symptom: review slows down, so people are added; CI slows down, so machines are added. Both are real costs, and the queue does not move, because the number of gates and the criteria inside them are unchanged. Adding people to an unchanged process mostly adds coordination.

A sharper split assigns ownership by output. Whoever produces an executable decision owns the step. If review produces a written criterion — why this version passed and how that was verified — the reviewer owns it. If the pipeline produces a hard gate, the platform team owns that gate’s false-positive rate.

What this changes in procurement

For an AI application lead or a transformation lead, the shift replaces the first question on the vendor questionnaire. The old first question was which model. The better one now is which part of the pipeline has instrumentation.

Those are different questions. The first compares generation quality. The second compares whether each step the output passes through can be read, replayed, and pulled back six months later to show why it was allowed through.

Four questions make that concrete. Where is the release criterion written? Who signs it, and on what basis? How many hard gates exist in the pipeline, and what kind of change does each of them stop? If someone asks in six months why the third revision reached the main branch, how long does the answer take to produce?

Behind them sits a checklist a team can start filling in without buying anything: can a change be traced from request to production; is each release criterion an executable file rather than a verbal standard; who handles a gate failure; where release records are stored and for how long; who may change the criteria, and what they leave behind; whether the practice is the same across platforms. Blank lines mark where the risk sits today.

None of this is a security audit. It is a capacity question. An organisation that cannot answer it has a throughput ceiling set by the length of its review queue, not by how many model tokens it has bought.

How we decide a change is done

Our own operating rule is that done means an executable check, not a statement. A change counts as finished when a set of commands passes: the build succeeds, the validation script reports no errors, the live page actually serves the new content, and the structured data is present. A model saying it is finished does not count as a completion condition.

The rule looks plodding, and it buys a checkable position. Any claim of done can be re-run by someone who never wrote the code, and if the commands fail the claim does not hold. It is also why our throughput readings come from the release side of the pipeline rather than the generation side.

The limits matter as much as the rule. This kind of check answers one question: on what basis was this step allowed through. It is not monitoring, and it does not promise to catch a problem at the moment it happens. Noticing a problem and being able to hand over the record of it are two different capabilities.

Measuring it yourself, with three numbers

You do not need new tools to see whether this applies to you. Compute three numbers for a single week: how many changes reached the main branch, the average waiting time in review, and the average pipeline duration together with its re-run count. Put them on one page and you can see whether output and release sit on the same curve.

Then look at the distribution rather than the average. A median wait of two hours against a p90 of thirty means a few changes sit for a long time — usually the hard, important ones, which rarely pass on the first attempt and are the easiest to defer again and again.

Finally, answer one question: if code volume doubled tomorrow, which number breaks first? The answer is usually not the model quota. Find that number and you have found where the next hire belongs.

Do not generalise from one case

Three brakes. Anthropic says the workload is unusual and does not expect most organisations to meet the same problem soon, so a single company’s experience is not an industry reading.

Second, 600 PB is the company’s own conversion of its own traffic, not a statistic. Ten times in five months measures its merge volume, not how much code the market produced. Treating a company figure as an industry fact is the most common distortion in writing of this kind.

Third, most enterprises may be stuck a step earlier: nobody maintains the review criteria, or nobody has defined what passing means. In that setting, raising code volume only lengthens the queue.

What transfers is not the tenfold figure but the mechanism — the constraint moves. When output rises tenfold, go and find the part of the pipeline that still has people and no instrumentation.

Our judgment

When agents start writing the code, the capacity question has already moved from how strong the model is to whether the release path has an executable condition. A model benchmark measures generation; it measures nothing about pipeline capacity, and therefore predicts nothing about what a team can ship.

Three actions follow. Pick one pipeline and turn what counts as passing from a verbal standard into a check someone else can run. Give review conclusions criteria: who signs, what they sign, and what the signature leaves behind. Bind the release record to the change itself, so a question six months later can be answered by walking back from the commit.

The question to leave with: if your merge volume rose tenfold tomorrow, which step breaks first? If the answer is a vague sense that things would get messy, the criteria have not been written down, and that is the first thing to fix.

Sources

Anthropic engineering, Redesigning source control, 2026-10-13. Every external figure in this article comes from that post and is the company’s own reading.