Andy Garcia · freelance dev
FRENES
Back to the blog
AI & Dev

Anthropic Went From 2,500 to 30,000 Merges a Day and Moved Its Monorepo Off Git. The Engineers Who Built the Replacement Review Intent, Not Every Line.

October 19, 2026 8 min read

On Tuesday, October 13, 2026, Anthropic published an engineering post called "Redesigning source control at Anthropic," updated on October 15. Its first numbers are the ones everyone repeated: in May 2026 the company averaged around 2,500 code changes merged per day, and as of September it merged over 30,000 per day. To cope, it built Scion, an in-house version control system, and fully migrated its monorepo from git in five months. In the same period it shipped a code review tool called Antique, code search and a source control access system. According to the post, a team of seven people built Scion and Antique.

The sentence that frames everything comes before any number. Coding, Anthropic says, is no longer the bottleneck: "The bottleneck, now, is all of the developer infrastructure built for human scale: source control, builds, and CI."

I am CTO of a LegalTech built on Claude, and I orchestrate my own work with Claude Code. My repositories are a rounding error next to this one. The version control system is the least transferable part of the post. What transfers is where the pressure showed up and what the engineers stopped doing by hand.

The numbers, and what they add up to

The main branch history is almost 100 GB. A compressed working copy is over 25 GB. Anthropic performs on the order of 25 million checkouts a day for CI alone, "before counting developer environments, agent sandboxes, and research jobs." Fetched naively, the post says, that would be over 600 PB of git traffic per day. The arithmetic holds: 25 million times a working copy of about 25 GB is about 625 PB.

A few divisions put it in human terms. Going from 2,500 to 30,000 merges a day is a factor of 12 in about four months. Spread over 24 hours, 30,000 merges is about 21 a minute. 25 million checkouts a day is about 290 a second. And if both figures describe the same weeks, that is more than 800 CI checkouts for every change that lands.

Git has tools for this: shallow clones, sparse checkouts, internal mirrors, snapshots in blob storage. Anthropic used them all and, at its peak, ran several hundred internal git mirrors. That bought time.

After the move, the post reports a Scion footprint 200 times smaller than the old git mirroring setup in CPU and memory, checkouts for CI and research jobs that take seconds rather than minutes, a cache hit rate above 99 percent at every tier, and a 25 percent CPU capacity gain for CI.

Why git stopped fitting

Git is decentralized: every clone is a complete repository that works offline. Anthropic's observation is that, like most companies, it was using git as a centralized system with one authoritative copy, while nearly all of its clients were agents and jobs that are online by definition.

So Scion assumes the client is always online. The server answers history and blame queries and performs commits, merges and rebases. The client keeps a bounded cache and fetches only what it needs. The same queries are exposed through an API, so many CI jobs need no local repository at all. Asked on Hacker News about offline support, Nick G., one of the post's authors, replied, as Simon Willison relayed: "Since Claude is by far the heaviest user of Scion and is necessarily online, this just wasn't important to do."

Much of this has precedent, and the post credited Google's Piper and Meta's Sapling as prior art from the start. That credit was challenged. On October 14, Rain, who helped build Mononoke, Sapling's server component, on Meta's source control team, wrote that crediting Sapling only for "hard-won lessons," without naming Mononoke, "borders on plagiarism," and called Scion a ripoff in a follow-up on October 15. That day Nick G. answered on Hacker News that Anthropic had credited Sapling because that is how Meta itself names the whole system, and the post gained a footnote saying Mononoke "pioneered many of the techniques we use in Scion," in particular its Bonsai data model. Rain then wrote that sufficient attribution had been added, while standing by both posts as of the time they were written. Anyone retelling the "seven people, five months" story should add that the data model at its core is one Anthropic now credits to Meta.

The line I underlined is about review

Here it is: "Our team members still review every change request for the system, but they now examine the intent of the change as opposed to reading every line of code."

Note the scope. That sentence describes the Scion codebase and its team, not a policy for all of Anthropic. But the company-wide arithmetic shows why it will not stay a one-team habit. At ten minutes of careful reading per change, which is generous for anything non-trivial, 30,000 changes a day would be 5,000 hours of review, or 625 people reading eight hours a day and doing nothing else. Past a certain volume, line-by-line review stops being a process and becomes a queue.

What surrounds it is spelled out elsewhere in the post, and it is not "trust the model." Scion supports permissions on individual directories, to protect the most sensitive code. The review tool can express semantic constraints on approvals, so a comment-only change is treated differently from a sensitive logic change and humans focus on the consequential ones. The team built hermetic simulations and fuzzing. It uses adversarial review, which the post calls effective but "myopic": one review was so defensive about trusting another internal service that Claude added excessive validation and complexity.

Then this: "Very often, we found that the role of the engineers was to tell Claude 'no.'" The example is concrete. Several systems tried to find when a change merged to main by reading the commit log linearly, instead of asking the code review tool that already knew. Every engineer on the project, the post says, would now rate Claude as better at writing code than them. What they still supplied was the system-level understanding and the design trade-offs.

The same post has an anecdote from the other side. Asked to rewrite the git-to-Scion ingestion pipeline, an early internal snapshot of Claude Mythos Preview produced, with no further instructions, a version that used 20 times less memory and ran 4 times faster, while preserving the invariants around ingestion ordering. Writing the code was not the hard part. Knowing what it must never do was. That time the model kept the invariants; in the commit log case, the agents did not.

The merge queue they gave up

Second surprise: "A proper merge queue, for example, doesn't make much sense at agent scale." Anthropic could not replicate the usual global repository lock on the merge queue, so it invested in post-merge and pre-deploy automated testing instead. The post accepts the consequence. Concurrent changes can conflict, and Claude can typically fix those conflicts faster than humans can identify them. On Hacker News, Nick G. specified that textual conflicts are never allowed; the ones that get through are semantic, for example a new call to a function landing while someone else changes that function's logic and updates its existing callers.

A change can now land before every test covering it has finished, and the gate that matters becomes the one before deploy. That is a reasonable trade at 30,000 merges a day. In software that holds clients' legal files, I would want to know exactly where that last gate sits before borrowing the idea.

What Anthropic says not to copy

The post is unusually direct. "Scion is by no means a suitable replacement for git for general use." The concepts only make sense for "truly enormous monorepos, with either tens of thousands of engineers or swarms of agents prolifically writing code." And: "Anthropic is unique in that our ability to spend tokens for internal use far exceeds what any other business would realistically want to spend."

It is not a product. What Anthropic offers instead is a forecast and a wish list. It expects "this class of problems" to become more common "over the next six to 12 months," and suggests that git platforms provide server-side APIs like Scion's, perhaps standardized across hosts, and make git's sparse and shallow features compose well. It names GitHub, GitLab and the open source community as the partners it wants.

What I would check, at a normal scale

Nobody reading this needs a new version control system. The useful part is the list of what strained: checkouts and CI, review, the merge queue.

Track merges per day and CI minutes per merged change, month by month. If agents double the first number, the second decides the bill.

Look at what each CI job fetches. If it clones full history to test the tip, the shallow and sparse options Anthropic outgrew are still the right size for most teams.

Write down which paths a human reads line by line. On GitHub, a CODEOWNERS file plus the "Require review from Code Owners" option in branch protection makes a code owner's approval mandatory before a change to those paths can merge (for private repositories, on a paid plan). Everything else gets an intent review: what the change is for, and which constraint it could break.

Put your "no" in writing for the agent. Anthropic's commit log example is the pattern: the agent recomputes what a system of record already knows. A rule like "ask, do not recompute" belongs in the instructions the agent reads at the start of every session, not only in a reviewer's head.

If you buy software from a vendor whose agents write most of its code, ask two questions: what a human still reads line by line, and where the last test gate sits before production.

Anthropic did not take its monorepo off git because agents write bad code. It did so because they write a lot of it, and everything downstream was sized for people. In a small team, the first thing sized for people is the reviewer.

Sources

A project like this one?

I design and deploy products like this. Let's talk.

Let's talk