Anthropic Dropped the Merge-Queue Lock. Testing Moved After the Merge.

In May 2026, Anthropic averaged around 2,500 merged code changes per day. By September it was merging over 30,000 per day. Those are the company’s own numbers, from an engineering post titled Redesigning source control at Anthropic, and they describe more than a tenfold rise in a few months.

Much of the post is about infrastructure: new systems named Scion and Antique, and the cost of serving checkouts at that scale. The part that matters for anyone governing agent-written code is shorter. It is the admission that Anthropic could not replicate a standard control in software delivery at this volume, and a description of what replaced it.

The lock that could not survive

Anthropic calls a global repository lock on the merge queue “the industry standard.” In our understanding, that lock is what keeps the main branch green after each change.

Its engineers asked a direct question: “What does CI even mean when hundreds or even thousands of changes can merge while tests are running?” Their answer was that they “haven’t been able to effectively replicate the industry standard of a global repository lock on the merge queue.” Instead, they “invested in post-merge and pre-deploy automated testing.”

The post is candid about the cost. “This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them.”

Our reading of the trade: the guarantee moves from the merge to the deploy. Anthropic tests post-merge and pre-deploy, and says Claude typically fixes the resulting conflicts.

We should be clear about what the source does not say. Anthropic reports no conflict or incident data for the post-merge model. This is a vendor describing its own system. The claim that Claude fixes conflicts faster than humans can spot them is a claim, with no data attached in the post.

Review moved to intent

The second change is about people, and it comes from how Anthropic built the new system itself. “Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code.”

For changes to that system, what the reviewer checks has shifted from the diff to the purpose.

The post separately describes its review tooling. The review system “can express complex semantic constraints on approvals, which lets us differentiate simple things like comment-only changes from sensitive logical changes, so that human reviewers can focus on the most consequential changes.”

There is a second layer underneath. The platform “supports rich access control on repositories, as well as the ability to apply permissions to individual directories in order to protect the most sensitive code without losing the benefits of a monorepo.”

Put those two together and, in our reading, you have a routing system: approval rules distinguish comment-only from sensitive logical changes, and directory permissions protect the most sensitive code.

We have written about code review doing five jobs at once and about why replacing it ends up renaming governance. Anthropic’s account is useful because it names the mechanisms.

The human says no

The most revealing line is about the engineers’ role while building the system. “Very often, we found that the role of the engineers was to tell Claude ‘no.’ Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place.”

Our reading of that failure mode: the agent follows a pattern that should never have been allowed, and a core constraint breaks as a result. What stops it is a person who knows the constraint and says no.

A second note points the other way. Adversarial review “can also be myopic, so skilled engineers needed to steer Claude away from over-engineering parts of the system in response to hypothetical concerns.” So the human role covers both directions: saying no to changes that break constraints, and steering Claude away from over-engineering against hypothetical concerns.

Neither job is line reading. Both require knowing what the system is for. In our reading, intent review is where that knowledge gets applied.

What does not transfer

Anthropic is explicit that its infrastructure is not a template. “Scion is by no means a suitable replacement for git for general use. The concepts we’ve outlined here really only make sense for truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code.”

It adds a second caveat, about token spend: “Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend.”

The scale numbers make the point: “on the order of 25 million code checkouts per day for CI,” which fetched naively “would be over 600 PB of git traffic per day.” The post also reports that Scion’s infrastructure is “200x smaller than our previous git mirroring infrastructure in terms of CPU and memory requirements,” and “CI alone realized a 25% CPU capacity win.” Anthropic says a team of seven built Scion and Antique and fully migrated to them in five months.

None of that is a reason to adopt Scion. Anthropic says so itself.

What does transfer

Our reading is narrower than the infrastructure story. When agent volume outgrows what a serialized pre-merge gate can hold, the control relocates to two places: what a human approves, and where the test runs. Those are routing decisions, and routing decisions are cheap to copy compared with a source control system.

The routing rules in the post can be stated without any of Anthropic’s tooling:

Classify changes by consequence before review. Comment-only changes do not need the same approval as changes to sensitive logic.
Protect sensitive directories with their own permissions, so the most consequential code always reaches someone who knows its constraints.
Decide explicitly where your test gate sits. If it moves after the merge, the deploy gate becomes the guarantee, and it has to be treated with that weight.
Write down the invariants that reviewers are there to defend, so “no” has a reference.

The last item is our inference from the “tell Claude ‘no’” passage. Anthropic does not describe a written list of invariants. It describes engineers who know them. In our reading, where that knowledge lives in a few heads, intent review at agent volume will expose how thin that layer is.

There is also a timing question. Anthropic’s volume grew more than tenfold between May and September. Teams that wait until review queues collapse to design routing rules will be designing them under pressure. The verification capacity argument applies here: the number of changes can grow faster than the controls that verify them.

Do this now

Take last month’s merged changes and sort them into two piles: changes a reviewer could approve from intent alone, and changes that touched logic where an invariant could break. Count both. If you cannot sort them, you do not yet have the semantic approval rules that Anthropic relies on, and that is the first thing to build.

Then pick your three most sensitive directories and check who is allowed to approve changes there today. If the answer is “anyone with write access,” directory-level permissions are the control in this post we would adopt first.

Finally, find where your tests actually gate. If agents are already pushing volume past what a serialized queue can hold, decide on purpose whether the deploy gate carries the guarantee, before the queue decides for you.

This analysis synthesizes Redesigning source control at Anthropic (Anthropic, October 2026).

Victorino Group helps engineering organizations design approval routing and verification gates for agent-written code. Let’s talk.