Anthropic drops git for its monorepo: meet Scion, version control built for agents

Yesterday I wrote about a Harvard study showing that AI agents write far more code, but the gain gets lost in review. Today Anthropic published Redesigning source control at Anthropic, which tells the other side of the same story: what happens when a company pushes agents to the limit and what breaks is no longer review, but git.

The post opens with a sentence that sums up everything else: “At Anthropic, coding is no longer the bottleneck”. The problem now is all the infrastructure designed for teams of people: version control, builds and continuous integration.

The numbers

Growing daily changes twelvefold in four months is wild. And Anthropic says it doesn’t expect the pace to slow down: every bottleneck they remove leads to even more code being produced.

Why git can’t keep up

Git is a distributed system: every clone is a complete repository that can compute diffs, read history or run blame offline. For almost every repository that’s exactly what you want, and it’s one of the reasons git won.

But in practice almost every company uses git centrally, with one reference copy on GitHub or GitLab. And in Anthropic’s case, nearly all the clients of that repository aren’t people, but agents and CI jobs that are always online. For them, having every clone be a full repository adds nothing and costs a huge amount.

Before building anything of their own, they tried everything usually done with large monorepos: shallow clones, sparse checkouts, promisor remotes, internal git mirrors and repository snapshots kept in object storage. At their peak they ran several hundred git mirrors. It bought them time, but it got harder and harder to maintain.

So they asked themselves a very good question: if you designed version control knowing from the start that the clients are always-online agents, what would it look like?

Scion’s principles

The answer is Scion, an in-house system inspired by Google’s Piper and Meta’s Sapling. Its principles are almost the opposite of git’s:

• Clients are always online. The client doesn’t hold a full copy: it asks the server for data when it needs it.
• The server does the work. History, blame, commits, merges and rebases happen on the server. The client just keeps a bounded local cache, lays files out on disk and watches for changes.
• Everything is available through an API. A CI job that needs to know who changed a line or the diff between two commits asks the server, without cloning anything. Their own tools, like automated bisect and reverts, wouldn’t be viable otherwise.
• Everything scales horizontally. There’s no full copy of the repository anywhere, not even on the server. There are no packfiles either, so no repository maintenance is needed.
• Cheap, lock-free commits. Creating a commit costs in proportion to the size of the change, not the size of the repository. And they discourage branches and tags, except main and release branches, because any global state every server has to agree on ends up being a scaling problem.
• The working copy is optional. Many read and write jobs work through the API alone. When files on disk are needed, the checkout is sparse or virtualized: files are fetched when they’re read.

How it works inside

The basic unit is the changeset, an entry in a write-ahead log. Unlike a git commit, which points to the full tree, a changeset only stores the list of files that changed relative to its parent, with pointers to their contents in object storage. Branches, when they exist, are moved with an atomic operation on a single Spanner row.

Since a changeset only knows what changed, everything else (blame, per-file history, the commit graph) is computed separately as derived data, through one generic mechanism. Each type can be computed eagerly or later, and since the client never sees those structures, they can be optimised without touching it.

The checkout part is the one I liked most. The client doesn’t tell the server what it already has, as in git, but asks one by one for the trees and files it’s missing. Since everything is content-addressed and never changes, any cache can answer, and the architecture ends up looking like a classic CDN:

flowchart LR
    A["Job or agent · scn client"] --> B["scion-daemon · node cache"]
    B --> C["scion-cache · regional cache"]
    C --> D["scion-server · source of truth"]
    D --> E[("Spanner · object storage")]

All three tiers answer the same calls, so the client doesn’t need to know what’s behind them. Each tier has a cache hit rate of over 99%. The result:

Seven people and five months

What stands out most is who did it and how fast: a team of seven people built Scion, Antique (their code review tool) and half a dozen other systems, and migrated the whole monorepo off git in five months. Meanwhile, the volume of code merged each day grew tenfold.

They say they wrote the first prototype of the git import by hand, and when they asked an internal version of Claude Mythos Preview to rewrite it, with no further instructions, the result used 20x less memory and was 4x faster.

But what I find most interesting in the post is how they describe the engineers’ work:

• Their role was often to tell Claude “no”. Agents sometimes break core system constraints to follow a pattern that should never have been allowed, like walking the commit history one by one instead of asking the review tool.
• Adversarial reviews overshoot too. They rely heavily on agent-to-agent review, but sometimes it fixates on hypothetical problems and ends up adding unnecessary validation and complexity.
• They still review every change, but they review the intent, not every line of code.

That last sentence is Anthropic’s answer to the bottleneck in yesterday’s study. And it’s a big shift: review the intent and rely on tests, simulations and fuzzing for the rest. They say Scion is among the best-tested codebases they’ve worked on, and that’s believable, because writing exhaustive tests now costs almost nothing. But it’s not a recipe any team can adopt overnight.

There are more interesting ideas. They have Slack channels with a Claude dedicated to watching the health of a single component, which they call “superfans”: one for the daemon, another for the cache, another for the merge queue. And they admit that a merge queue with a global lock makes no sense when hundreds of changes merge while tests are running, so they’ve moved to testing after merge and before deploy. Conflicts between concurrent changes are fixed by Claude.

What it isn’t

Anthropic is very clear about this: Scion isn’t a replacement for git for general use. It only makes sense for huge monorepos, with tens of thousands of engineers or swarms of agents, and it requires its own code review, search and CI. They don’t plan to release it either, because it’s too tailored to them. They also admit they spend far more on tokens for internal use than any other company would want to.

It’s also worth reading with some distance: it’s a post by Anthropic about how well Claude works inside Anthropic. The figures are theirs and there’s no way to check them from outside.

What they do propose is bringing some ideas to git without changing its model: servers that don’t have to work like clients, server-side APIs to query the repository, perhaps standardised across forges, and making sparse checkouts and shallow clones work well together. They expect this kind of problem to become common within 6 to 12 months, and want to work with GitHub, GitLab and the git community.

My takeaway

A couple of weeks ago I wrote about Git 3.0 and the move to SHA-256, a change that will take the whole ecosystem years. And now a company builds and migrates to its own version control in five months with seven people. Put together, the two stories say a lot about how fast everything is changing.

Few teams will have 30,000 merges a day, but the underlying idea affects all of us: the tools we use were designed for the pace of people. When agents write the code, the bottlenecks move to review, to CI, to version control… and each company will run into them at its own scale. The post is a good guide to where they’re going to show up.

Source: Redesigning source control at Anthropic, Anthropic Engineering.