Anthropic published Redesigning source control at Anthropic on 13 October 2026. I read it expecting an infrastructure flex – seven people, five months, built their own version control system, migrated an entire monorepo off git. That is a flex. But it is not what held my attention.
What held my attention is that the wall they hit is not in the model layer. It is in the plumbing I have spent twenty years assuming was a solved problem.
What they actually built
They built Scion: a centralised, server-authoritative version control system that shares almost none of git’s design assumptions. Around it they shipped Antique for code review, code search, a source-control IAM system with directory-level permissions, and the machinery to land large volumes of reviewed code. Then they cut the monorepo over completely – not a long coexistence period, a full migration.
Five months, seven people, while the volume of code merged per day grew tenfold underneath them.
The two numbers that forced it
- May 2026: roughly 2,500 changes merged per day.
- September 2026: over 30,000 per day.
Everything else in the post is downstream of those two lines.
The repo was also genuinely huge – main’s history is near 100 GB, and a compressed working copy is over 25 GB. But I do not think size is the interesting part, and neither do they. Google and Meta survived size. What broke was the rate, and specifically the rate of reads.
They run on the order of 25 million checkouts per day for CI alone, before developer environments, agent sandboxes and research jobs. Fetched naively from git, that is over 600 petabytes of traffic per day. They were running several hundred internal git mirrors at peak to absorb it, plus repository snapshots parked in blob storage. Shallow clones, sparse checkouts, promisor remotes, mirrors, seeds – every standard monorepo workaround was already deployed. It bought time, then stopped buying time. As the merge rate climbed, the snapshots drifted further from the tip of main between refreshes, and keeping history-dependent operations like diff and blame correct on partial clones took more and more care.
Why I think this is a design mismatch, not a scale story
“We got too big for git” is the shallow reading, and it is the one I would have reached for before reading the post carefully.
Git is a decentralised system. Every clone is a complete, self-contained repository that can compute diffs, read history and blame, and check out any revision with no network at all. That property is why git won, and for almost every repository I will ever touch it remains the right design.
Anthropic’s observation is that they were already using git as a centralised system with one authoritative copy – as I suspect most large companies are. And their clients were no longer people on laptops in airports. Nearly all of them were agents and CI jobs that are online by definition.
So they were paying git’s entire distribution tax – full local copies, client-side computation, packfile negotiation, repository maintenance – to buy offline autonomy that none of their clients wanted. The properties that make git excellent were, in their words, actively undermining their ability to scale.
That is the reframing I keep coming back to. Not “git is slow.” Rather: git’s cost model is priced for a client that no longer exists in our fleet.
How Scion works
Six principles, each a direct inversion of a git assumption:
- Clients are always online. Fetch data when you need it; do not pre-stage a copy of everything.
- Client/server asymmetry. The server answers file history and blame, creates commits, performs merges and rebases. The client keeps a bounded object cache, lays out working-copy files, watches the filesystem and provides ergonomics. It can compute very little alone – and in exchange, it needs very little locally.
- Source control is an API, not a directory. Every query the client can make is also an RPC, so a CI job asking “who last touched this line” needs no local repository at all. Their automated bisect and revert pipelines exist because of this.
- Everything horizontally scalable. There is no fully materialised copy of the repo anywhere – not even on the server. No packfiles, so no repository maintenance.
- Commits are cheap, incremental and lock-free. Every commit, rebase and merge happens server-side, so there is nothing to push, and the cost of a commit scales with the size of the change rather than the size of the repo. The lifecycle actively discourages refs beyond main and release branches, because global state every server must agree on is a latent scaling bomb.
- The working copy is optional and sparse by design. Sparse checkouts fetch only requested directories; virtualised checkouts materialise files on demand.
The data model is where it got concrete for me. Scion’s unit of work is a changeset – an entry in a write-ahead log. Where a git commit points at a tree, a changeset stores a list of files changed relative to its first parent, plus content-addressed pointers to compressed contents in blob storage. Nothing to accept, no cross-server locking, no ref to move. Refs do exist, but moving one is a compare-and-swap on a single Spanner row, decoupled from creating changesets entirely.
A changeset alone cannot answer “who last edited this line,” so Scion computes derived data – blame structures, path history, skip lists over the commit graph – through one generic recursive mechanism: a type’s value for a changeset is computed from its value for that changeset’s parents. Three payoffs, and I think the third is the one that matters most. New derived types are cheap to add. Each can be eager or deferred, so unneeded data is never materialised. And because the client never sees the internals, the server can re-optimise them without touching the client. They have cashed that in repeatedly – copy detection and path-based file search both arrived as new derived types.
The fetch path is the other inversion. Git negotiation is the client telling the server what it already has so the server can compute a bespoke packfile. Scion’s scn client never does that. It asks for specific objects, walking down from a root tree, checking its local store, requesting what is missing – trees first, then blobs. Because every request names an immutable, content-addressed object, any cache can answer it. That turns a hard problem into a boring one: a tiered cache.
Which is what they built. scion-daemon holds objects for a whole node, starting from a periodically refreshed snapshot and talking only to regional scion-cache servers, which stream objects straight from memory in the disk format the daemon will consume – no missing-object computation, no delta compression. On a miss, the cache asks the authoritative scion-server, which reads Spanner or cloud storage. All three tiers answer identical RPCs so the client is topology-blind, but the tiering is strictly enforced to isolate failure domains and stop a regional cache failure from stampeding the authoritative servers.
Their reported results: every tier sustains a >99% cache hit rate; the infrastructure footprint is 200x smaller than the old git mirror fleet in CPU and memory; checkouts are two orders of magnitude faster, seconds instead of minutes; and CI alone recovered 25% of its CPU capacity.
The lessons I would steal even without a monorepo
The engineer’s job shifted to saying no. Every engineer on the team now rates Claude as better at writing code than they are. What they supplied instead was cross-system understanding, design-level tradeoffs and – repeatedly – refusal. Agents will violate a core system constraint to satisfy a local pattern that should never have been allowed in the first place. Multiple systems tried to brute-force “when did this change merge to main” by linearly reading the commit log instead of asking the code review service. Their adversarial review process works, but it also skews myopic: one review was so defensive about trusting an internal service that Claude piled on validation and complexity to appease it. Reviews now examine the intent of a change rather than every line.
Speed bought quality instead of spending it. Because writing code got cheap, they built hermetic simulations of every non-trivial infrastructure and source-control interaction they had ever hit, plus fuzzing and sophisticated rate limiting – on a five-month timeline. One anecdote is the whole thesis in miniature: they had handwritten a git-to-Scion ingestion pipeline and were happy with it, then handed it to an early internal Mythos snapshot to rewrite. With no further instruction it came back 20x leaner on memory and 4x faster, with every implicit ordering and data-structure invariant intact.
Monitoring took a shape I have not seen before. They created Slack channels each staffed by a Claude instance tasked with obsessing over the health of exactly one component – a scion-daemon superfan, a scion-cache superfan, an Antique merge-queue superfan. Given telemetry and logs, they behave like an experienced engineer with nothing better to do than refresh charts looking for something odd. Conventional alerts still exist and now look one-dimensional beside them.
The merge queue stopped making sense. This is the quietly radical line. At agent scale a global repository lock on a merge queue is not replicable – hundreds or thousands of changes can land while a test run is in flight, which forces the question of what CI even means. Their answer was to drop the lock and invest in post-merge and pre-deploy automated testing instead. Concurrent changes do conflict. Claude usually resolves the conflict faster than a human would notice it happened.
Does it apply to the rest of us?
They are admirably direct that it mostly does not, yet. Scion is not a git replacement for general use; the design only pays off for genuinely enormous monorepos with tens of thousands of engineers or swarms of prolific agents. They also concede they are an outlier in a way few will replicate – their willingness to spend tokens on internal development far exceeds what an ordinary business would rationally choose, partly because exercising Claude is part of the point.
They are not open-sourcing it either. Scion diverges far enough from git that adopting it means migrating every stage of the development lifecycle, and it needs its own code review, code search and CI, all bespoke internally. Their judgement is that a public version trying to please everyone would not be useful to anyone, and I think that is right.
What they are offering instead is the design insight, aimed squarely at the forges: a git server does not have to work the way a git client does. Platforms can expose comprehensive server-side RPCs – ideally standardised across forges, so the git client itself could learn to speak them. The negotiation protocol can change. Sparse and shallow can be made to compose properly. None of that requires leaving git’s model. It requires taking the server seriously as a different kind of thing.
Their stated timeline for everyone else is six to twelve months before this class of problem becomes commonplace.
So the takeaway I am holding onto is not “consider replacing git.” It is the diagnostic underneath. Anthropic’s bottleneck moved from writing code to merging, building and testing it, and every tool in that path was designed around a human typing. When your agents start generating changes faster than your pipeline can absorb them, the first thing to break will not be the model. It will be a mirror fleet, a merge queue, or a CI job that still thinks it needs a full clone.
