In May 2026, Anthropic merged about 2,500 changes a day into its main codebase. By September it was more than 30,000. Anthropic says Claude's ability to write code is "what put us in this situation in the first place." Git stopped fitting, so they replaced it.
You probably don't need to replace Git. But one decision in their write-up applies to almost any team adding coding agents, and it's about the merge queue.
Merges per day in Anthropic's monorepo, May vs. September 2026. Source: Anthropic Engineering.
Why Git stopped fitting
Git assumes clients that keep a full copy of the history and work offline. That's perfect for people. Anthropic's clients are mostly machines: "nearly all of our clients were agents and jobs that are online by definition." They run on the order of 25 million CI checkouts a day against a main-branch history of almost 100 GB, and at the peak it took several hundred internal Git mirrors to keep up.
So a team of seven built Scion, which flips the model. The server creates commits, performs merges and rebases, and answers history questions, while clients fetch only what they need. Anthropic reports an infrastructure footprint 200x smaller in CPU and memory than the old mirrors, and CI checkouts in seconds instead of minutes. The migration took five months.
The write-up is just as clear that Scion is "by no means a suitable replacement for git for general use." It only makes sense for enormous monorepos, and it needs its own code review, code search and CI.
The merge queue decision
A merge queue is the line in front of main. Each change is tested against the latest main plus everything queued ahead of it, then lands. The industry-standard version holds a global lock on the repository while it does that, and it's how most teams keep main green.
Anthropic writes that a proper merge queue "doesn't make much sense at agent scale," and asks: "What does CI even mean when hundreds or even thousands of changes can merge while tests are running?" They couldn't make the global lock work at their volume, so instead of making the line faster, they moved the check. They "invested in post-merge and pre-deploy automated testing." The gate that matters now sits before production, and when concurrent changes conflict, Claude can typically fix them faster than a person would notice.
Before: changes wait one at a time behind a global lock. After: no global lock, and the real gate sits before deploy.
Find your one-at-a-time step
Every delivery pipeline has a step where changes wait for each other: the merge queue, a required human review, a single shared staging environment. When agents multiply how much code your team produces, that step hurts first.
The reflex is to make it faster with bigger runners, more reviewers or another staging box. Sometimes that's enough. The better question is the one Anthropic asked: does this check need to sit here at all? Moving a gate to where it doesn't block everyone can beat any speedup.
To find yours, trace one change from commit to production and circle every place where it waits for another.
Where this breaks down
- Scale. Most teams will never see 30,000 merges a day, and Anthropic admits its "ability to spend tokens for internal use far exceeds what any other business would realistically want to spend." If your queue isn't hurting, leave it alone.
- Risk. Testing after merge means main can be broken for a while. That only works if pre-deploy checks are reliable and conflicts get fixed fast.
- Source. Every number here comes from Anthropic's own engineering blog, with no independent measurement.
The real bottleneck
Strip out the version control details and this is a story about one part of a system getting 12x faster while the rest didn't. Anthropic expects this class of problems to become "more commonplace over the next six to 12 months." Find your one-at-a-time step before then.
Where is it in your pipeline: the merge queue, code review, or somewhere else?
Sources
- Redesigning source control at Anthropic, Anthropic Engineering, October 13, 2026 (updated October 15, 2026)
Top comments (1)
The idea of moving the gate instead of making the line faster is the part I'm stealing. One thing that makes post-merge testing survivable is fast, automatic revert, because if it takes an hour to find the culprit after hundreds of changes have landed, the real gate is just whoever notices first. Does their write-up say how they trace a red main back to one change at that volume?