# The Bottleneck Moved to the Merge

> Coding agents can produce code faster than an organisation can absorb it. Source control, review and CI each break differently, and Anthropic's Scion shows the order.

- URL: https://dperez.com/posts/the-bottleneck-moved-to-the-merge/
- Author: David Perez
- Published: 2026-10-17
- Tags: agents, source-control, ci

Coding agents can produce code faster than an organisation can absorb it.

Consider a platform team that rolls out agents in the spring. By autumn, pull requests arrive faster than CI can check out the code, reviewers cannot clear the queue, and someone is on call to keep the git mirrors alive. The models have become the fast part of the system, and the delivery infrastructure has not kept up.

Anthropic has described a sharper version of this. In [its engineering post on redesigning source control](https://www.anthropic.com/engineering/redesigning-source-control), published in October, the company says merges to its monorepo rose from about 2,500 a day in May 2026 to more than 30,000 a day by September, much of it code written by Claude. Source control became, in its words, _"our biggest development bottleneck"_. A team of seven replaced git for that monorepo with an in-house system called Scion, and built a code review tool called Antique alongside it, in five months.

Few enterprises will ever need Scion. The order in which its systems broke still tells them where their own rollouts will hit limits. As agents speed up code production, delivery comes to depend on three separate systems: the infrastructure that stores and merges changes, the people and rules that review them, and the pipelines that decide whether they are safe to ship. Each was sized for human developers, and each fails differently. Faster checkouts do not make review faster, and more automated review does not make a release safer.

## What Scion changes about git

A traditional git workflow keeps a lot of repository state on each client, with local commits followed by a push. That suits people on laptops who are sometimes offline. Partial clones, shallow clones and sparse checkouts reduce the cost, but a very large repository served to a fleet of short-lived CI jobs and agents can still make repository access expensive.

Scion turns that around. It assumes every client is online, and each one fetches only the files it needs. Commits, merges and rebases run on the server, so there is nothing to push, and many jobs ask the server questions through an API instead of holding a repository at all. Anthropic reports that the new setup uses [200 times less CPU and memory](https://www.anthropic.com/engineering/redesigning-source-control) than its old git mirroring fleet and that CI checkouts take seconds rather than minutes.

None of this is new as an idea, and Anthropic credits [Google's Piper and Meta's Sapling](https://www.anthropic.com/engineering/redesigning-source-control) as prior art. Google's 2016 description of Piper reads like an early draft of the same argument. Its authors wrote that [_"gaining the full benefit of Google's cloud-based toolchain requires developers to be online"_](https://cacm.acm.org/research/why-google-stores-billions-of-lines-of-code-in-a-single-repository/), and that on a typical workday engineers committed 16,000 changes while automated systems committed another 24,000. Google needed tens of thousands of engineers to generate that load. Anthropic reached a similar daily volume in a few months, because agents did the writing.

## Review and CI move with it

For most organisations, the changes to review will matter more than the new source control system. Antique can express semantic approval rules, so it can tell a comment-only edit from a change to sensitive logic and send only the latter to a human. The team says reviewers now focus on [the intent of a change rather than every line](https://www.anthropic.com/engineering/redesigning-source-control), and that one of the most important things an engineer does is tell Claude _"no"_ when an agent breaks a system constraint or over-engineers a fix.

The team also rethought the merge queue. Claude can usually fix a merge conflict faster than a person can spot one, so Anthropic leans more on testing [after merge and before deploy](https://www.anthropic.com/engineering/redesigning-source-control) than on holding every change at the gate.

That trade needs care. Merging before every check has run is a different decision from releasing before the code is validated, and only the first is on the table. Moving checks downstream works when post-merge testing is fast and reliable and a release gate still stands between the main branch and production. For a company whose auditors sign off on change control, the useful question is which checks can move later in the pipeline.

Approval rules by type of change are the more portable idea, and they are where I would start. Low-risk changes can take a lighter review path, while changes to security-sensitive logic, permissions, data handling or critical business rules keep stronger controls. The rules have to judge actual risk, since a formatting change can hide a logic edit, a test change can weaken an assertion and a comment can misdescribe behaviour. Done well, they point human attention at the changes where a mistake costs the most.

## Where to start this quarter

Do not build a Scion. Anthropic says it is [_"by no means a suitable replacement for git for general use"_](https://www.anthropic.com/engineering/redesigning-source-control), partly because adopting it means replacing code review, search and CI as well. Seven engineers spending five months on internal tooling is a cost most enterprises will not carry.

Some relief is already in git. [Scalar, which ships with git](https://git-scm.com/docs/scalar), clones only commits and trees by default, turns on sparse checkout and runs background maintenance. It eases repository access without changing git's architecture the way Scion does. Anthropic's stated aim is to get git servers to adopt server-side operations and better sparse and shallow support, and it says it hopes to work with GitHub, GitLab and the open-source community on that. The vendors are moving as well. Cursor put its own code hosting, [Origin, into early beta in August](https://cursor.com/changelog/origin-code-hosting), with agents working inside every repository, though it is too new to judge at agent scale.

The first job is to measure, and measure the queues as well as the volume. Merges per day can rise without telling you which of the three systems is straining. Cold and warm checkout times show pressure on the repository. Time to first review shows reviewer capacity, and time from opening a pull request to merging it shows friction across the whole path. Splitting CI queue time from execution time separates a scheduling shortage from slow tests. The post-merge failure and rollback rate shows whether faster integration is costing quality, and it is the one I would watch most closely, because doubling merge throughput is no win if production breaks more often.

Then define the thresholds that trigger an infrastructure review or a change in workflow, before the agent rollout reaches them. Ask your forge vendor what runs on the server and what still needs a full clone.

For anyone planning an agent rollout, choosing the model is the easier question. The harder one is which part of your delivery system finds out first when your agents start writing ten times the code.