Anthropic merged over 30,000 code changes a day in September. Five months earlier, that number was around 2,500. And somewhere in between, git stopped being able to keep up.
That is not a benchmark. It is a company admitting its own tooling broke. The same Claude that wrote the code also broke the thing that stores it.
I keep coming back to one line from Anthropic's engineering post: "the latent demand for merging code is practically infinite." That sentence is either the most exciting or the most terrifying thing I have read this year, and I genuinely cannot decide which.
Here is what happened. Anthropic's monorepo hit a wall. The main branch history is nearly 100 GB. A compressed working copy is over 25 GB. They run about 25 million code checkouts a day for CI alone, before you count agent sandboxes and developer machines. Fetched normally, that is over 600 PB of git traffic per day.
So they built Scion. An in-house version control system. Seven engineers. Five months. Migrated the whole monorepo off git.
What Scion actually is
Strip the framing away and Scion is a centralized system wearing a distributed system's clothes. It looks a lot like Subversion with better marketing, and I mean that as a description, not an insult.
The core idea is simple. Git assumes clients are offline and self-contained. Every clone is a full repo. Every dev can diff, blame, and check out without a network.
nearly all of Anthropic's clients are agents, and agents are always online.
So they threw out the assumption. In Scion, the server does the real work. It creates commits, computes diffs, finds merge bases, runs blame. The client just lays files on disk and asks for what it needs.
The unit of work is a "changeset," not a commit. A changeset only records what changed relative to its parent, plus pointers to compressed file contents in blob storage. No packfiles. No pushing. Every commit and rebase happens server side.
Here is the part I did not expect: the working copy is optional.
A CI job that only needs a diff never has to check out the repo. It asks the server for the diff and moves on. When files on disk are unavoidable, the client does sparse or virtualized checkouts, paying only for what it actually reads.
That is a real design decision, not a slogan. It is also the entire reason their checkout count is survivable.
The numbers
| Metric | Before | After |
|---|---|---|
| Daily merges | ~2,500 (May) | 30,000+ (Sept) |
| Infra footprint | several hundred mirrors | 200x smaller |
| CI checkouts | minutes | seconds |
The 200x is the number everybody quotes. I care less about that and more about what it says about their old setup. They were running several hundred git mirrors just to survive. That is not a system. That is triage.
And the fixes did not scale either. Seeds drifted behind main between refreshes. Shallow clones and promisor remotes made history-dependent work, like diff and blame, fragile. Every workaround created a new thing to babysit.
Scion's answer: no fully materialized copy of the repo exists anywhere. Not even on the server. Data is distributed, content-addressed, and cached freely because a stored object never changes.
That last detail matters more than it looks. It is why the whole thing scales horizontally without everyone coordinating all the time.
The most honest paragraph Anthropic wrote
Buried in the reporting, not the headline: Anthropic's own engineers admit Claude writes better code than they do.
Then comes the actual job. From their post: "Very often, we found that the role of the engineers was to tell Claude 'no.'"
That is the whole shift in one sentence. The humans are not writing the code. They are the constraint layer. The seatbelt.
Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place.
I have run into a smaller version of this. The agent does exactly what you asked, in a way you would never have permitted if you had thought to say no in advance. It is fast and it is confident and that is precisely the problem.
Being the person who says no is not a demotion. It might be the most important job in the building.
A tangent about naming things
While reading all this I got stuck on the names. Scion. Antique. Two tools, same launch, and neither name tells you anything about what it does.
A scion is a descendant, an heir, the young shoot grafted onto an older plant. Cute if you already know it replaces git. Useless if you do not.
Antique is worse. It is the code review surface. You named the thing humans stare at all day after the word for "old."
I have shipped bad names. Everyone has. But naming an internal dev tool is one of the few places you get to just say what the thing is and move on. Scion could have been called Monorepo VCS and nobody would have blinked.
This is not a real problem. It just lives in my head rent free now.
Real talk
Most of you do not need this. I mean that.
If your team merges a few hundred changes a day, git is fine. Great, even. Git is not broken. Git is optimized for a world where humans write code slowly and work offline, and for almost everyone that world is still here.
Scion exists because Anthropic hit a load roughly nobody else has hit yet. They said so themselves. This is not for general use. There is no open source release, and there will not be one.
And the 200x number deserves a caveat the headlines skip. It is 200x versus running several hundred mirrors. Your git setup is not several hundred mirrors. Your comparison is not their comparison.
I also want to flag the uncomfortable reading. A tool this expensive to build only makes sense if you have venture money to burn on writing your own infrastructure. That is fine, but it means the story is really about scale and budget as much as it is about clever engineering.
The genuinely useful thing here is not Scion. It is the warning. Anthropic thinks other teams will hit this in the next few months. Believe them or do not, but the checkouts, the merge rate, and the agent count are all moving in one direction.
I still think about that line about infinite demand for merging code. It sounds like a boast until you remember who wrote it. A company that just spent five months and seven engineers cleaning up after its own success.
They also told GitHub and GitLab to go solve the general version of this problem. Which is a very polite way of saying: this is your problem now.
The part I cannot shake is the engineers saying no. Not as a joke. As the actual description of the job. Six months ago that would have sounded like a punchline about AI taking work. Now it reads like a job posting.
Top comments (0)