Almost every software company on Earth uses Git. In October 2026, Anthropic, the company behind Claude, said it had stopped.
In May 2026, Anthropic merged about 2,500 code changes a day. By September it was more than 30,000 a day, with AI writing much of that code. Git became the bottleneck. So a team of seven people built a new source control system, Scion, and moved the company's main repository off Git in five months.
This post explains it from the ground up with one tiny example app, so you don't need to be a Git expert to follow it.
🎥 Prefer video? I made a 5-minute animated version: (https://www.youtube.com/watch?v=9Q-5sJ1q5Tc)
First, how Git works (in 60 seconds)
Imagine a small app called ShopApp with three files: login.py, cart.py and payment.py.
Every time a developer changes something and saves it in Git, Git records exactly what changed, who changed it and when. That record is a commit. Commit after commit, you get the full history of the project, and you can go back to any earlier point.
Git has one more superpower: every developer gets a full copy of the project, with its whole history, on their own laptop. You can work offline, on a train, anywhere, and push your changes to the shared copy when you're ready.
That design is why Git took over the world. It's also, as we'll see, the root of Anthropic's problem.
"Pull first": the rule everyone has hit
Two developers, Priya and Arun, work at the same time. Priya changes login.py. Arun changes payment.py. Different files.
Priya pushes first. Then Arun pushes, and Git says no:
! [rejected] main -> main (fetch first)
Git only checks one thing: did you start from the latest version? Arun didn't, because Priya's change landed first. So Arun pulls, Git combines both changes automatically (they touched different files), and Arun pushes again.
If both of them had changed the same line of cart.py, Git couldn't guess who is right. It marks a conflict, and a person has to decide:
For teams of people, this works beautifully.
What went wrong at Anthropic
Now picture Anthropic's setup, using the figures from their engineering post:
- All the code lives in one giant repository. The main branch's history is almost 100 GB, and a compressed working copy is over 25 GB.
- Most of the work isn't done by people on laptops. It's done by AI agents, CI jobs and research jobs that are always online.
- Every test needs a copy of the code: about 25 million checkouts a day. Fetched the normal Git way, that would be over 600 petabytes of traffic a day. That's roughly 1,200 full-HD movies every second (my own back-of-envelope comparison: 600 PB a day is about 6.9 TB a second).
To cope, they ran several hundred internal Git mirrors. But the repository outgrew the mirrors' disks and memory, copies fell behind the latest code, and history operations like diff and blame got harder to keep working.
In Anthropic's own words, the properties that make Git excellent for distributed, offline work were "actively undermining our ability to scale."
Note what the problem was not: Git didn't fail at storing changes. It was built for a world of offline laptops with full copies, and Anthropic's world became always-online machines needing fresh code millions of times a day.
What Scion does differently
The big idea: stop giving everyone a full copy. Keep one main copy on a server, and let the server do the work.
- Nothing to push. Commits, rebases and merges happen on the server. An agent hands in its change and the server saves it into the main code.
- Changesets, not snapshots. Each change records only what changed, and things like history and blame are built separately as derived data.
- Fetch only what you need. Sparse and virtual checkouts mean a job gets only the parts of the repository it uses. Files still appear in the listing, and their contents arrive when something opens them.
- Fewer branches. Mostly one main line plus release branches, because global state every server has to agree on doesn't scale.
Back to Priya and Arun. Here's how a server-side merge works in principle (my own illustration; Anthropic's post doesn't list per-case rules):
| Situation | What happens |
|---|---|
| Nobody touched your files since you started | Goes straight in. No pull. |
| Same file, but different lines | The server combines both. No pull. |
| The very same lines | A real clash, which still needs a fix |
Real clashes don't disappear. Anthropic says concurrent changes can still conflict, that post-merge and pre-deploy tests catch them, and that Claude typically fixes them.
The results they report: CI and research checkouts became about 100× faster (seconds instead of minutes), and the Scion infrastructure is about 200× smaller in CPU and memory than their old Git mirroring setup.
Why not just use many small repositories?
Fair question. Git handles small repositories easily, and most companies do exactly that. Anthropic's post doesn't explain why they keep one big repository, so here are the usual reasons companies like Google and Meta give for theirs:
- One change, many projects. If twenty apps share the same login code, twenty repositories means twenty separate updates, and for days some apps still run the old version. With one repository, a single change updates all twenty together.
- One version of shared code, instead of old versions piling up.
- Everything in one place, which matters even more when AI agents need to see and change code across the whole company.
The cost is size, and that's exactly the problem Scion solves.
Should you stop using Git?
No. Anthropic itself says Scion isn't a replacement for Git in general, and it isn't being released. For most teams, Git is still the right tool, and some of the same ideas are available today: sparse checkout, partial clone, and merge queues on GitHub and GitLab.
But the bigger lesson is worth noticing: when AI agents write code at this speed, even the most trusted tools have to change.
Would you let AI agents merge 30,000 changes a day? I'd love to hear your take in the comments.
Sources
- Anthropic Engineering, "Redesigning source control at Anthropic" (13 Oct 2026): https://www.anthropic.com/engineering/redesigning-source-control
- Fact check for every number in this post: https://github.com/kannajune/kdblueprints-sources/blob/main/2026-10-15-scion/SOURCES.md
The ShopApp example, Priya and Arun, the three-case table and the movie comparison are my own explanations, not Anthropic's.
Top comments (0)