30,000 merges a day: what happens when your biggest user isn't human
Anthropic went from 2,500 to 30,000+ merges a day and replaced git for its monorepo in five months. Here's what actually broke, what surprised me, and what it means if you build with agents.
30,000 merges a day: what happens when your biggest user isn’t human
In May, Anthropic merged about 2,500 code changes a day. By September, that number grew to over 30,000.
Nobody hired 12x more engineers. Claude wrote most of the code. And at that volume, the oldest tool in the stack finally cracked: git.
On October 13, Anthropic published a post explaining how they replaced it for their monorepo in five months, using a team of seven. I read it, and the interesting part is not the headline numbers…
The assumption that broke
Git is built around a beautiful idea: every clone is a complete repository. You can diff, read history and check out any revision on a plane with no wifi. For almost every repo on Earth, that’s the right design. You know that joke that says “there is no way this actually breaks in production” and then it always does? Well with git you would normally never even have to think about that, and yet it still broke.
But Anthropic’s clients are almost all agents and CI jobs, and those are online by definition. They don’t need an offline copy of 100 GB of history, they need a few directories, right now.
The scale is what hurts. The main branch history is almost 100 GB. CI alone does around 25 million checkouts a day, which fetched naively would be over 600 PB of git traffic daily. They tried the standard workarounds (shallow clones, sparse checkouts, seed snapshots) and at peak ran several hundred internal git mirrors. That bought time, but the mirrors got harder to operate as merges kept climbing.
So they flipped the design. Their new system, Scion, is server-centric. The server handles commits, merges, rebases and blame, and clients keep a small cache. A CI job that wants a diff just asks the server and often never clones anything. Reported results: roughly 200x less CPU and memory than the mirror fleet, checkouts in seconds instead of minutes, and a 25% CPU capacity win for CI.
The interesting bits
1. The engineers’ job became saying no. All of the engineers on the project now rate Claude as a better writer of code than themselves. What they still supplied was system-level judgment. The post gives concrete examples: agents violating core constraints to fit a familiar pattern, like several systems brute-force reading the commit log instead of asking the review tool. Adversarial AI review also over-engineered things, piling on validation to guard against hypothetical risks. Humans still review every change, but they now review intent rather than every line.
2. A rewrite nobody asked for. The team had hand-written the first git-to-Scion ingestion pipeline and thought it was good. Then they gave it to an early internal snapshot of Claude Mythos Preview and asked for a rewrite with no further guidance. It came back using 20x less memory and running 4x faster, with the subtle ordering invariants intact.
3. The merge queue stopped making sense. If thousands of changes land while tests are still running, a global lock is a fantasy. So they moved to post-merge and pre-deploy testing and accepted that concurrent changes will sometimes conflict, betting that Claude fixes conflicts faster than humans can even spot them. That’s a real tradeoff, not a free lunch.
4. Claude monitors the system, too. The team set up Slack channels where one Claude is obsessively focused on a single component, which they call “superfans”. There’s a scion-daemon superfan, a cache superfan and so on, watching telemetry like an engineer with nothing better to do than stare at charts. Kinda reminds me of those people who simulate fruit flies in torture chambers.
Before you panic about your own repo
Anthropic is clear that Scion is not a general git replacement. It only makes sense for enormous monorepos with huge numbers of engineers or agent swarms, and they note their internal token spend is far beyond what most businesses would spend. They’re not releasing it. Instead they want GitHub, GitLab and the open-source community to adopt the transferable ideas, such as richer server-side APIs and better-composing sparse/shallow features, because they expect others to hit this wall within six to twelve months.
The skeptics have fair points, too. Developer commentary on Hacker News (as summarized by Developers Digest) argued that doing every commit server-side gives up git’s local, rework-before-sharing workflow, that 30,000 merges a day isn’t extreme per employee, and that the savings figures are self-reported and can’t be checked from outside. I think both things can be true: the numbers are directional, and the design lesson still holds.
What I’m taking from it
I am currently building AI agents for a living, so one line from the post stuck with me. Anthropic says “the latent demand for merging code is practically infinite”, and every bottleneck removed just produces more code.
Generation got cheap. Everything downstream of generation (source control, builds, CI, review) was built for human speed, and it’s now the constraint. If you work with agents, the question stops being “can the model write this?” and becomes “what in my pipeline assumes a person is waiting?”
You probably don’t have 30,000 merges a day. But if your agents spend time cloning history they never read, git clone --filter=blob:none --sparse plus one worktree per agent is a good place to start.
Git isn’t dead. Its assumption that the client is a person with a laptop just got a lot less universal.
Sources:
- Anthropic Engineering, Redesigning source control at Anthropic (Oct 13, 2026)
- Developers Digest, Anthropic Scion: Why Anthropic Replaced Git for Agent-Scale Merges (summary and Hacker News reaction)