Why Anthropic replaced Git for AI-scale development

Git is today's de facto version control system, and a nice one, too. It has been the default source control system for many developers for a long time.

Git was obviously designed for human users. But what happens when most of the "developers" touching a repository are automated AI agents working continuously and creating changes at a rate humans never could?

Anthropic (the company behind Claude Code) has run into exactly this problem. Somewhere in 2026, the company built an internal source control system called Scion and migrated its large monorepo away from Git. Just recently, the published a post about it.

The reason they built Scion was not that Git suddenly became bad software. Instead, the problem was that Git was designed around a different set of assumptions. Let's see what those are.

First, Git is decentralized. Every normal clone of the repository can contain the repository history, calculate diffs, inspect blame, create commits, switch revisions, and continue working while offline.

Those properties are extremely useful for human developers. But Anthropic's workload is different. Most of its source control clients are AI agents, CI jobs, sandboxes, and research workloads that are online by definition.

At that scale, copying large parts of the repository to every client becomes very expensive. Anthropic says the history of its main branch alone is almost 100 GB. Compare this to the repos you work with.

Secondly, the company says it performs around 25 million code checkouts every day for CI before even counting developer environments and agent workloads.

Because of this scale, Scion starts from a different assumption:

• The client is already online.
• The server is authoritative.
• Fetch only what is actually needed.

Instead of every client being capable of acting like a complete source control server, Scion moves much of the work to the server. The server can then answer questions such as:

• what changed between two revisions?
• who last changed this line?
• what is the merge base?
• what is the history of this file?
• how are two changes related?

A client does not necessarily need a complete local repository just to answer those questions. And as you can guess, this is especially interesting for AI agents.

An agent that needs to inspect three directories should not necessarily have to download a 100 GB repository history first. Scion therefore makes sparse and virtualized working copies part of the basic design. For example, files are materialized only when they are actually needed.

Some operations do not need a working copy at all. A CI job can ask the source control service directly for a diff instead of checking out the repository just to calculate one at the client.

In Scion, commits are different too. With Git, you say things like:

git commit
git push

In Scion, commits are created on the server and immediately become available there. Merges and rebases are server-side operations as well.

Anthropic also deliberately minimizes global references such as branches and tags because global mutable state becomes another scaling problem when the number of changes becomes very large.

Anthropic reports that the Scion infrastructure uses around 200 times less CPU and memory than its previous Git mirroring infrastructure.

Still, this is not a reason to replace Git in your normal development project. Anthropic says that explicitly.

Scion was designed for extremely large monorepos with enormous numbers of automated clients. The design trades away some of Git's strongest properties, especially decentralized and offline operation. For a team of ten developers working on a normal repository, Git remains a very good fit.

What I find more interesting is what Scion says about the direction of development infrastructure.

Many of our current tools were designed around human limits:

• a developer checks out a repository
• a developer creates a branch
• a developer writes a manageable number of commits
• a CI system tests those changes
• a human reviews and merges them.

AI coding agents can change the scale of every one of those assumptions.

If hundreds or thousands of agents are producing changes continuously, source control, builds, CI, review queues, and even the concept of a working copy may need to evolve.

My prediction is that we will eventually see more of this work become available to the wider developer community.

Perhaps Git stays on developer machines, while the server side becomes much more capable of answering source control questions without requiring every agent and CI job to maintain a full repository.