Git was never built for agents: what I learned from Anthropic’s Scion

In May 2026, Anthropic merged about 2,500 code changes per day into its main repository. By September, it was more than 30,000.

That’s not a typo. More than twelve times as many in four months.

At that volume, something happened that few people expected to see so soon: Git stopped keeping up. And instead of patching the problem, Anthropic built its own version control system from scratch, called Scion. The company told the whole story in an article on its engineering blog, published on October 13.

I read the whole thing as someone who has worked in software development for more than 15 years. And I came away with a conclusion that goes far beyond Git.

Git was built for a different world

Git was born in 2005. It was designed for a very specific scenario: developers spread around the world, each with a full copy of the repository on their own computer, often working offline and syncing every now and then.

That model is brilliant. It’s why Git has dominated the market for almost two decades.

But in practice, almost every company uses Git in a centralized way. There’s one main server, usually on GitHub or GitLab, and everyone depends on it. Anthropic did the same.

The difference was who was on the other side. According to the article, nearly all of the repository’s clients were agents and jobs: CI runs, test environments, research jobs. All of them online by definition, all at the same time.

In other words: a system designed for offline humans was serving machines that never shut down.

When the numbers get absurd

A few figures from the article show the size of the problem:

• the main branch history was almost 100 GB
• a compressed working copy was over 25 GB
• there were about 25 million code checkouts per day just for CI, not counting developer environments, agent sandboxes and research jobs
• if every checkout downloaded everything the naive way, that would be more than 600 PB of Git traffic per day
• at peak, the company ran several hundred internal Git mirrors just to handle the load

You can imagine the effort of keeping that alive. Seed copies that drifted further behind main between refreshes, partial clones that made commands like diff and blame hard to keep working, infrastructure growing nonstop.

The team summed it up themselves: source control became the company’s biggest development bottleneck.

How Scion works

A team of seven people built Scion and migrated the monorepo in about five months, along with a new code review tool and code search. Over the same months, daily merges grew more than tenfold. It was like changing the plane’s engine mid-flight, while the plane kept speeding up.

Scion starts from a simple premise: clients are always online. From there, many decisions change.

• The server does the heavy lifting. History, blame, commits, merges and rebases happen on the server, not on each client’s machine.
• The client only downloads what it reads. Instead of cloning the whole repository, it fetches only the files it needs, on demand.
• There’s no full copy of the repository anywhere. Not even on the server. Data is distributed, and each part of the system scales independently.
• Commits are cheap and happen directly on the server. There’s no “push”. The cost of each operation depends on the size of the change, not the size of the repository.
• Source control becomes a service. Everything is exposed through an API, so many jobs, like automated bisect and revert, don’t even need a local repository.

There are also three server tiers that answer the same calls: one on each machine, one regional and the authoritative one. Each tier keeps a cache hit rate above 99%, and a regional failure doesn’t take down the rest.

The results

The final numbers are the kind of thing every infrastructure team would love to show in a presentation:

• about 200 times less CPU and memory than the old Git mirroring infrastructure
• CI and research checkouts that dropped from minutes to seconds, two orders of magnitude faster
• 25% of CPU capacity freed up in CI alone
• no repository maintenance on clients or caches

And one important detail: the team makes it clear that Scion is not a general replacement for Git. Adopting it would require migrating every piece of the development lifecycle, including code review, code search and CI. Their hope is that some of these ideas help evolve Git itself, and they say they want to work with GitHub, GitLab and the open-source community.

The part that caught my attention most

The architecture is beautiful. But the part that stuck with me was about the role of the engineers.

The team wrote that Claude was better than them at writing code. The human work became architecture, weighing tradeoffs and, very often, telling Claude “no” when it proposed something that broke the system’s rules. One example they gave: systems that scanned the commit history to find when a change landed on main, when the right move was to ask the code review tool.

They also tell how a hand-written prototype was rewritten by an early internal snapshot of Claude Mythos Preview, with no further instructions. The new version used 20 times less memory and ran 4 times faster.

And there’s one more interesting change: with the volume of changes, engineers stopped reviewing every line and started reviewing the intent of each change.

This connects directly with what I see day to day. In e-commerce, code is rarely the hard part. The hard part is knowing what a “simple” change will do in production, in an ERP integration, in a checkout on a peak day, in a process that runs at night that nobody remembers exists.

That judgment doesn’t come from a prompt. It comes from years of watching things break.

The bottleneck moved

The most important lesson of the article isn’t “build your own Git”. Please don’t do that on Monday. Almost no company has 30,000 merges a day.

The lesson is different: when AI speeds up writing code, the bottleneck moves to the next point in the chain.

First it was writing the code. Now it’s everything we built around human speed:

• code review, which waits for someone to have time
• CI, which is slow because every job downloads the whole world
• the merge queue with a global lock, which Anthropic itself dropped in favor of post-merge and pre-deploy testing
• the deploy process, which depends on manual approvals
• observability, which now even includes agents monitoring components and catching subtle problems that traditional alerts miss

If your team starts producing two, five or ten times more with AI, one of these pieces will jam before the others.

What I would do starting today

You don’t need to be Anthropic to use this lesson. A few practical questions to bring to your team:

• How long does a pull request wait for review? If AI doubles the number of PRs, does that wait double too?
• How much of your CI time is spent just downloading code and dependencies?
• Do your agents and pipelines really need a full clone, or would a partial checkout do?
• Who on the team has the authority and knowledge to say “no” to an AI-generated solution that looks good but breaks the architecture?

The last question is the most important. Tools will change, and Scion is proof that even Git can be rethought. What still matters is the ability to understand the whole system and make good decisions about it.

AI is writing more and more code. Whoever understands the system decides what goes in.

If your team’s output doubled tomorrow, what would break first? Tell me. I want to hear from people living this in practice.

Source: Anthropic, “Redesigning source control at Anthropic” (October 13, 2026).