On Tuesday Anthropic published a long engineering post about replacing git. Not GitHub, git itself. Their monorepo was taking about 2,500 merged changes a day in May. By September it was over 30,000. Anthropic says it uses Claude to write software more than almost any other company, and the merge rate shows it.
Git assumes every copy of a repository is complete and can work offline. That suits a person on a laptop. It doesn’t suit always-online agents and jobs working on a repository with almost 100 GB of history, checking out a working copy of over 25 GB compressed around 25 million times a day. Anthropic ran several hundred git mirrors to keep up, and they got harder to run as merges climbed. So a team of seven built Scion, plus a new code review tool, and moved the monorepo across in five months. The server does the heavy work: history, blame, merges. Clients fetch only what they need. Anthropic reports CI checkouts taking seconds rather than minutes, and a 25% CPU saving in CI alone.
What jumped out at me is that they dropped the conventional merge queue. At that volume they can’t lock the repository and test each change in turn, so they test after merge and before deploy, and accept that concurrent changes will sometimes conflict. Claude usually fixes the conflict faster than a person would find it.
The same problem at a smaller scale
Anthropic says Scion isn’t for most teams. But I’ve hit a small version of the same problem on my own project, where Claude Code does the development. It still felt slow, and my plan was to run several agents in parallel to speed it up. First I had Claude Code go through 30 days of CI history.
The main pipeline takes about ten minutes to run, but each of the 77 merged changes was billed around 106 minutes of runner time. Jobs run in parallel and each is billed separately, and changes went through the pipeline two or three times on average, mostly for ordinary fixes. In 29 of the 77, a run happened only because another change merged first, so the branch pulled it in, with nothing to resolve, and ran everything again. The cause was one branch protection setting: require branches to be up to date before merging.
That cost 13% of all CI minutes and about nine and a half hours of waiting. More agents would have made it worse, because every extra open pull request has to catch up each time something merges. AI on top of a broken process just breaks it faster.
What to look at
Look at everything your pipeline runs on every push to a pull request. Ask whether it needs to be there or could run once after merge, before a pre-production deploy. That’s the trade Anthropic made, and it’s what the review recommends for my setup: turn the up-to-date rule off, and check the merged result once on the main branch before anything deploys. The deploy doesn’t need a pipeline of its own. It can stay where it is, as long as it waits for those tests on the merged code. Not everything moves. My Docker build caught five real failures in a month, so it stays on pull requests. It just doesn’t need to wait for the database tests to finish first, which takes the pipeline from about ten minutes to under six.
Then learn how GitHub bills you. Every job is rounded up to a whole minute, so a four-second check costs a full minute, and I had several running on every push. Some behaviour is less obvious. If a required check is skipped by a condition, say to save minutes when nothing relevant changed, GitHub counts it as passed. Cut minutes the wrong way and untested code can merge. Merge queues, GitHub’s own fix for this kind of waiting, are only available on repositories owned by an organisation, not a personal account. None of this shows up unless you go looking, and a coding agent won’t go looking unless you ask it to.
The review puts the saving at around 28% of CI minutes per change, and the wait between a green build and a merge should disappear. For Anthropic the problem was throughput. For a small team paying for every minute, it’s cost as well, because agents push far more changes through the same pipeline. It isn’t the hardest problem with agentic coding. Review and quality still are. But it’s the one that turns up on the bill first. If you’re diligencing a business that says AI has doubled its engineering velocity, ask what happened to review time, CI spend and change failure rate over the same period.