Anthropic Replaced Git Because Claude Broke It

Anthropic published an engineering post on October 13 with an unusually direct opening claim: coding is no longer its bottleneck. What is, in the company's words, is all of the developer infrastructure built for human scale. Daily merges into its monorepo went from around 2,500 in May to over 30,000 by September, and the version control system underneath gave way.

What Anthropic reports

The supporting numbers give a sense of the load. Anthropic describes main-branch history approaching 100 GB, a compressed working copy above 25 GB, and continuous integration alone pulling roughly 25 million checkouts a day. Scion is built around an always-online client-server model with regional caches, so agents work against the server rather than cloning the repository locally.

The company also credits Claude with part of the fix, saying that when asked to rewrite the ingestion pipeline with no further instructions, it produced a version using 20 times less memory and running four times faster. These are all Anthropic's own figures from its own post, which is normal for an engineering write-up and worth holding as such.

The assumption that broke, not the software

Anthropic is careful about this, and the phrasing matters: the properties that make Git excellent for distributed, offline work were actively undermining its ability to scale as the repository grew. Git was not defective. It was built in 2005 around a user who clones a repository, works for a while, and pushes occasionally.

Anthropic's users are now mostly agents and automated jobs that stay connected continuously and work in parallel. Operations that cost a little when they happen occasionally become a constant tax when they happen constantly, and a design assumption from twenty years ago stopped matching the traffic.

Every tool your business runs carries assumptions of the same kind. A ticketing system assumes tickets arrive at the rate humans create them. An approval workflow assumes a manager sees a handful a day. Those assumptions are rarely written down, which is why they are discovered by being exceeded.

The sentence worth copying out

Anthropic writes that the latent demand for merging code is practically infinite, and that every bottleneck removed immediately leads to a further increase in the amount of code produced.

That is a statement about capacity planning rather than about software. Relieving a constraint does not settle a process; it reveals the next one, and in a system where demand is elastic it also generates more work to run into it. Planning an AI project as a single fix assumes the opposite, which is why so many of them report a saving in one step and no change end to end.

The practical consequence is to budget for rounds rather than for a project. Finding where the constraint went after each round is the exercise in locating the bottleneck after it moves, and the elapsed-time version of the same arithmetic is in why faster work did not shorten your lead time.

Your version, scaled down

The same sequence at ordinary scale looks like this. An AI tool lets two people produce the output that used to take five. The reviewer who was comfortably keeping up becomes a two-week queue, because their day did not get longer when the volume tripled.

Or the drafting gets fast and the weekly approval meeting stays weekly, so the floor on turnaround is now seven days regardless of how quickly anything is written. Or the output lands in a system where someone re-keys it by hand, and that person is now the constraint for the whole department.

None of these require anything to go wrong. They are the predictable consequence of improving one stage of a chain, and the warning sign is a team reporting genuine time savings while customers notice nothing, which is the gap described in what happens when AI scales a broken process.

What not to take from this

Scion is not available and Anthropic says plainly that it is not a suitable Git replacement for general use. The company is asking the Git community to improve server-side behaviour for agent-scale workloads rather than suggesting anyone copy what it built. Reading the story as a tooling recommendation gets it backwards.

Nor is it a signal that ordinary businesses should expect their tools to break. Anthropic operates at a volume essentially nobody else does, with almost all active users being agents. What transfers is the ordering of events, not the magnitude.

A reasonable response is to count how much agent and automated activity you actually have running, which most organisations cannot answer, as covered in do you know how many AI agents you are running, and to keep review capacity in view as output rises, which is the problem in quality assurance when AI writes the first draft.

Frequently Asked Questions