Redesigning source control at Anthropic

Anthropic's merge volume grew more than tenfold recently. Somewhere in that growth curve, source control became the company's biggest development bottleneck. Not the models. Not the compute. Git itself. I've been writing about developer tools for years, and I've never seen a company hit a wall this hard on something most engineers treat as solved infrastructure.

Most teams would respond by buying more licenses or throwing hardware at the problem. Anthropic decided to build their own version control system instead. They call it Scion, and it takes a fundamentally different approach than git on several core principles. The reason is that agentic coding has broken assumptions about how software gets written, and the tools we've relied on for decades weren't built for a world where AI agents commit code at this rate.

The irony is that at Anthropic, writing code is no longer the bottleneck to building systems or doing research. Claude can autonomously iterate on research loops, micro-

Technical Overview

Our monorepo has outgrown Git. The history on main alone is almost 100 GB, and a fresh clone with compression still checks out at over 25 GB. That's not a repo anymore; it's a data set with version control bolted on. I keep waiting for the day when git status takes longer than compiling the project, and honestly, we're probably there.

The scale has forced some strange architectural decisions. We use Git history as a message queue between agents, storing state transitions as commits rather than spinning up Kafka or whatever the proper infrastructure would be. It works, mostly, because nothing else handles 100 GB of append-only state gracefully, but it's the kind of workaround that makes new engineers stare at the terminal for a minute before they understand what's happening.

We hit a wall earlier this year with our git-to-Scion ingestion pipeline. The first version was handwritten, and we thought it was solid until we pointed an early internal build of Claude Mythos Preview at it. The model rewrote the entire thing in one pass, and the result was better than ours. That's when you know your tooling has become a liability. It's similar to how version control works for large game and 3D assets, except we're doing it with source code, which feels like using a forklift to move a deck of cards.

If you're dealing with a repo this size, sparse checkouts are your only hope of keeping a working copy manageable:

git sparse-checkout init --cone
git sparse-checkout set src/core services/api
git read-tree -mu HEAD

The working copy drops from 25 GB to something you can actually fit in RAM, though you'll still wait for Git to walk that 100 GB history on operations that touch the index.

Industry Impact

Git assumes a particular rhythm of human work: you edit, you pause, you commit with intent. That assumption is baked into every merge conflict resolution, every blame annotation, every bisect. When agents write code—continuously, in bulk, without the pauses that make commits meaningful—that rhythm breaks down. Scion's divergence from git suggests they hit that wall and decided the tool itself was the problem, not the workflow.

What this means practically depends on whether you're running agents as autocomplete or as autonomous contributors. If an agent is just suggesting lines, git's friction is still useful; it forces a human to stop and review. But if agents are committing directly, or if you're coordinating multiple agents working on the same codebase, git's model of linear history and human-authored commits starts generating noise faster than signal. I think Scion is betting that the second scenario is coming, and that version control needs to look more like coordination than like a ledger.

The uncomfortable part is that we don't yet know what "good" looks like when half your team doesn't sleep and doesn't read your commit conventions. Until we have a few years of production experience with agent-heavy teams, I suspect most organizations will try to force git to work, hit scaling problems, and only then look for alternatives like Scion. Whether teams adapt their review processes to match agent speed, or just accept lower quality in exchange for volume, is the question I'm sitting with.

Conclusion

Going from 2,500 to over 30,000 merges per day in four months isn't optimization—it's a phase change. Anthropic built Scion in five months because git couldn't hold a 100GB history, let alone the commit volume from agents that iterate faster than humans can review. The migration worked.

But that "practically infinite" latent demand is a trap. Remove every bottleneck and the work doesn't vanish; it just relocates to the humans who now have to review code changing faster than they can read it. I'm still not sure what happens to software development when the commit rate exceeds comprehension, and I don't think Anthropic knows yet either.