Claude writes so much code that Anthropic replaced git with its own system

For twenty years, git has been the one tool almost every software team agrees on. On Tuesday, October 13, 2026, Anthropic explained in a post on its engineering blog why it no longer uses git for its main codebase. The reason is not a flaw in git. It is the amount of code that Claude now writes inside the company.

In May 2026, Anthropic merged around 2,500 code changes per day into its monorepo. By September, it was merging more than 30,000 per day. To keep up, a team of seven engineers built a new version control system called Scion, plus a code review tool called Antique, and fully migrated the monorepo away from git in five months.

This article explains what broke, how Scion works, what it delivered according to Anthropic, and why the rest of the industry should pay attention even though Scion itself will not be released.

The bottleneck moved

Anthropic opens its post with a blunt claim: "coding is no longer the bottleneck to building systems or doing research." Claude can iterate on research loops, tune programs and build new services faster than people can. What slows everything down now, the company says, is "all of the developer infrastructure built for human scale: source control, builds, and CI."

The numbers make the point. Going from about 2,500 to over 30,000 merges per day is roughly a twelvefold increase in four months. At 30,000 per day, a change lands about every three seconds, day and night. Anthropic adds that it does not expect the curve to flatten, because "the latent demand for merging code is practically infinite." Every bottleneck it removes leads straight to more code.

A careful reading by On The Wire adds some useful nuance: the chart in Anthropic's post appears to show a single peak day at about 30,400 merges on September 9, while the seven day average stays below 20,000. Either way, the jump from May is enormous, and it happened in a single summer.

Why git stopped fitting

Git was designed in 2005 as a decentralized system. Every clone is a complete repository that can show history, compute diffs and check out any version while fully offline. For almost every project in the world, that is exactly the right design, and Anthropic says so clearly.

The trouble is the size and the traffic pattern of Anthropic's repository:

• The history of the main branch alone is almost 100 GB.
• A compressed working copy is over 25 GB.
• CI performs on the order of 25 million checkouts per day, before counting developer machines, agent sandboxes and research jobs.
• Fetched the naive git way, that would be more than 600 petabytes of traffic per day.

Anthropic already used the usual tricks for big monorepos: shallow clones, sparse checkouts, promisor remotes, internal mirrors and repository snapshots kept in blob storage. At the peak it ran several hundred internal git mirrors. That bought time but became harder to operate as the merge rate kept climbing. Snapshots fell further behind the tip of the main branch, and history based operations like blame got harder to keep working on partial clones.

Then came the key observation. Like most companies, Anthropic was really using git as a centralized system with one authoritative copy. And almost all of its clients were not people on laptops but agents and jobs that are online by definition. The features that make git great for offline work were now working against it.

What makes Scion different

Anthropic built Scion around a short list of principles. It openly credits prior art from Google's Piper and Meta's Sapling, two other in-house systems for giant monorepos.

Clients are always online. Scion assumes the server is reachable and lets clients fetch data only when they need it, instead of holding a full copy of everything.

The server does the heavy lifting. In git, every client can act as a full server. In Scion, the server answers questions about history and blame, creates commits and performs merges and rebases. The client keeps a bounded local cache, lays out files on disk and watches for changes. It can compute very little on its own, but it needs far less data.

Everything is an API. Every query the client can make is also available to other programs. A CI job that wants to know who last changed a line, or how two commits are related, can simply ask the server without a local checkout. Anthropic says its automated bisect and revert pipelines would not be practical at this scale without that cheap access.

Commits are cheap and lock free. In Scion, commits, rebases and merges all happen on the server, so there is nothing to push. The cost of a commit grows with the size of the change, not the size of the repository. Branches and tags are discouraged except for the main line and release branches, because global state that every server must agree on becomes a scaling problem.

Working copies are optional and sparse. When a job needs files on disk, it gets only the directories it asks for, or a virtual checkout that loads files on demand. Many read and write jobs skip the checkout completely.

Changesets instead of commits

Under the hood, the basic unit is a changeset, an entry in a write ahead log. Where a git commit points to a full tree, a changeset stores only the list of files that changed compared to its first parent, plus content addressed pointers to the compressed file contents in blob storage. Moving a reference is a single compare and swap on one row in Google's Spanner database, separate from creating changesets.

Everything else, such as blame data, path history and skip lists for walking the commit graph, is "derived data" computed from the changesets through one generic mechanism. That lets the team add new indexes when they need them and decide which ones to compute early and which ones on demand, without ever changing the client.

A checkout in five hops

When a machine in Anthropic's fleet needs code, the scn client talks to a local scion-daemon that stores objects for every job on that node. The daemon starts from a regularly refreshed snapshot and then asks a regional scion-cache for anything missing. Only on a cache miss does the request travel to the authoritative scion-server, which reads from Spanner or cloud storage.

Instead of telling the server what it already has, as git does, the client only asks for specific trees and blobs it wants. Because every object is content addressed and never changes, any cache can answer any request. Anthropic says every tier keeps a cache hit rate above 99 percent and needs no long lived state.

What it delivered

Anthropic reports large gains. These are company figures and have not been independently verified, but they are specific:

• The Scion infrastructure is 200 times smaller in CPU and memory than the old fleet of git mirrors.
• CI and research jobs check out code about two orders of magnitude faster, in seconds instead of minutes.
• CI alone gained 25 percent of its CPU capacity back.
• When an early internal snapshot of Claude Mythos Preview was asked to rewrite the handwritten git to Scion ingestion pipeline, it produced a version that used 20 times less memory and ran 4 times faster, while keeping all the ordering rules intact.
• A team of seven people built Scion, Antique and about half a dozen related systems, and finished the migration in five months while merge volume grew tenfold.

The human role is changing

The most interesting part of the post is not the architecture. It is how openly Anthropic describes the work of its engineers. Everyone on the team, the post says, would now rate Claude as better at writing code than themselves. Yet their judgment still mattered, and very often "the role of the engineers was to tell Claude no."

Agents sometimes broke core constraints to satisfy patterns that should never have existed. Several systems, for example, tried to find out when a change merged by reading the whole commit log instead of asking the code review tool. Automated adversarial reviews sometimes pushed Claude to over engineer defenses against hypothetical problems. Humans still review every change request for Scion, but they now focus on the intent of a change rather than reading every line.

Anthropic also describes Claude instances it calls "superfans." Each one sits in its own Slack channel, has access to telemetry and logs for a single component and does nothing except look for anything strange. The company says these watchers catch subtle issues that classic alerts miss.

Perhaps the boldest admission is about the merge queue. At agent scale, Anthropic could not keep the industry standard of a global repository lock. It relies instead on testing after the merge and before deployment. That means concurrent changes can conflict, but, according to the post, Claude can usually fix those conflicts faster than humans could even spot them.

Not a git replacement, and not open source

Anthropic is clear that Scion "is by no means a suitable replacement for git for general use." It only makes sense for enormous monorepos with tens of thousands of engineers or swarms of coding agents. It also requires its own code review, code search and CI, all highly customized. The company says it is hard to offer Scion in a form other organizations could use, and it does not plan a public version.

Instead, Anthropic wants to share its ideas so that git servers and forges can adopt the best parts: richer server side APIs, perhaps standardized across platforms, a different negotiation protocol, and sparse and shallow features that work well together. It says it wants to partner with GitHub, GitLab and the open source community, and it expects "this class of problems" to become common within the next six to twelve months.

How developers reacted

The post hit a nerve. On Hacker News it collected more than 850 points and close to a thousand comments within about a day. Many commenters questioned what 30,000 merges per day really means for quality. Some argued that a lot of that volume may be agents fixing each other's work, while others pointed to their own experience that review is still essential to keep AI written code clean. Developer and blogger Simon Willison noted that Scion sounds like a modern return to centralized version control, in the spirit of Subversion.

Both reactions are fair. Merge count is a weak measure of value, and a company that sells AI coding tools has every reason to present big numbers. But the infrastructure problem described in the post is real and easy to check against the physics of moving hundreds of gigabytes millions of times a day.

Why it matters

• It is an early signal. Anthropic likely runs more coding agents internally than almost anyone. Problems it hits now could reach other heavy users of AI coding tools within a year, which is exactly what the company predicts.
• Infrastructure is the new limit. When code gets cheap, source control, CI, code review and testing become the slow parts. Expect investment and new products in exactly those areas.
• Online first beats offline first for agents. Git's design assumes a human who may be on a plane. Agents are always connected, and tools built for them can push more work to the server.
• Review changes shape. Reading every line does not scale to thousands of changes per day. Reviewing intent, encoding constraints in tests and using automated monitors is how Anthropic says it keeps control.

Our take

I find this one of the most concrete stories about agentic coding this year, because it is not a benchmark. It is a company rebuilding a piece of plumbing that almost nobody rebuilds, because its own AI made the old plumbing too small. That says more about how much code agents already write than any leaderboard.

I would still read the numbers with care. Thirty thousand merges per day tells us how much changed, not how much of it was useful, and the critics on Hacker News are right to ask. The more convincing figures are the boring ones: a mirror fleet two hundred times bigger than needed, checkouts that took minutes, a quarter of CI capacity spent on fetching code. Those are real costs any big engineering organization will recognize.

The part I like most is the honesty about people. The engineers say Claude writes better code than they do, and in the same breath explain that their main job was saying no. That is a good description of where software engineering is heading: less typing, more judgment about what should never be built. For most teams, git will be fine for a long time. But if your agents start merging faster than your humans can read, you now know what the next bottleneck looks like.

Sources

• Anthropic Engineering: Redesigning source control at Anthropic (October 13, 2026)
• On The Wire: Anthropic moves its monorepo off Git to Scion, an in-house version control system
• The Terminal: Anthropic Scion: why it moved its monorepo off git
• Simon Willison: Redesigning source control at Anthropic (October 13, 2026)
• Hacker News discussion: Redesigning source control at Anthropic