30,000 Merges a Day Broke Git at Anthropic — So It Built Scion

The most worth-reading engineering blog post of 2026 in the AI coding world might not be about a new model at all. On October 13, Anthropic's engineers laid their cards on the table: they replaced Git. Not because Git is bad, but because Claude writes code so fast it blew Git's pipes apart.

Don't dismiss this as big-tech humblebragging. What gives this post real weight is that it uses one company's actual production data to draw, for the first time, the wall that every vibe coder will eventually hit in 2026: when the people writing code go from a few hundred engineers to thousands of tireless agents, the first thing to break isn't model capability — it's the developer infrastructure "built for human scale": version control, builds, CI. Anthropic simply uses Claude to write code more than any other company on earth, so it hit the wall first, and was forced to build a new wall first.

And the way the wall got built is the post's most elegant footnote: a seven-person team, five months, built Scion — an in-house version control system replacing Git — plus a brand-new code review surface called Antique, and completed the migration of the entire monorepo. And the thing that helped them build Scion was Claude itself.

A ridiculously steep curve: from 2,500 merges a day to 30,000

Start with the numbers. In May 2026, Anthropic's monorepo averaged around 2,500 code changes merged per day; by September, that number was over 30,000 per day. On September 9, a single day saw 30,401 merges — the peak. From May to September, four months, 12x.

What does 12x actually mean? Anthropic's post gives a few more tangible yardsticks. The main branch's history alone is nearly 100GB; a compressed working copy is over 25GB; CI alone performs on the order of 25 million code checkouts per day — and that's just CI, not counting developer environments, agent sandboxes, and research jobs. Fetched naively, that's over 600PB of git traffic per day. 600PB — that's 600,000 terabytes, just to pull code down every day.

They tried every textbook answer, of course. Shallow clones, sparse checkouts, promisor remotes — all the git-native tools were in play; internal git mirrors were stacked up, several hundred at peak; repository seed snapshots in blob storage were kept ready. Those tricks bought time, but as the merge rate kept climbing, maintenance costs started rising exponentially: seeds fell further behind the tip of main, history-dependent operations like diff and blame got harder to keep working on partial clones, and the several hundred mirrors themselves became a beast that needed tending.

So they stepped back and asked a first-principles question: if we designed source control from the start with the fact that clients are always online, what would it look like?

Scion: "clients are always online" as a first principle

The answer to that question is Scion. Anthropic's observation is sharp: nominally everyone uses git's decentralized design, but in practice nearly every company uses it as a centralized system — one authoritative copy. And at Anthropic, that "in practice" goes one step further: nearly all of their clients are agents and CI jobs, clients that are "online by definition." The elegant properties git designed for offline work — every clone a complete self-contained repository, diffs and blame computable locally — became, under this workload, the shackles on scaling.

So Scion inverts several of git's core principles:

• Clients are always online. No more assuming clients need to work offline; the protocol is designed around a server that is always reachable, with clients fetching data when they need it.
• Client-server asymmetry. In git, every client can be a full-fledged server; in Scion, answering file history and blame, creating commits, performing merges and rebases are all the server's job. The client only maintains a bounded local object cache, lays out working-copy files on disk, and watches the filesystem. It can compute very little on its own — in exchange, it needs far less data locally.
• All version-control capability exposed as APIs. In the git era, a CI job asking "who last changed this line" had to maintain a local repository or hope a vendor API happened to cover it. In Scion, every query the client uses is also exposed via API, so many jobs don't need a local repository at all — Anthropic's automated bisect and revert pipelines couldn't run at scale without this cheap programmatic access.
• Everything horizontally scalable. Repository data is distributed, every component scales independently; there is no fully materialized copy of the repo anywhere, not even on the server. No packfiles (git's compressed object bundles), so no repository maintenance either.
• Commits must be cheap, incremental, and lock-free. There's no push in Scion — commits, rebases, and merges all happen server-side. The unit of work is the changeset, essentially an entry in a write-ahead log: unlike a git commit storing a tree pointer, a changeset stores the list of files changed relative to its first parent, plus content-addressed pointers to compressed contents in blob storage. The cost of creating a commit scales with the size of the change, not the size of the repo.
• The working copy is optional, and sparse by design. A CI job that needs a diff can just ask the server — checkout skipped entirely. When files really need to land on disk, sparse checkouts contain only the directories the client asks for, and virtualized checkouts materialize files on demand — "the client only pays for what it actually reads."

A changeset in Scion: only the list of files changed relative to the parent plus addressed pointers to compressed contents; blame and path history are derived data computed on demand. Image: Anthropic engineering blog.

Under the hood, Scion is a tiered caching architecture: the client talks over a socket to a per-node scion-daemon, which streams objects from memory on regional scion-cache servers, falling back to scion-servers (reading Spanner and cloud storage) only on cache misses. Every tier holds a cache hit rate above 99% with no long-lived state, so scaling up is easy. The results are striking: Scion's infrastructure footprint is 200x smaller than the old git-mirroring setup in CPU and memory; checkouts went from minutes to seconds — two orders of magnitude; CI alone freed up 25% of CPU capacity.

Scion's checkout architecture: scion-daemon, scion-cache, and scion-server tiers, with all objects content-addressed and immutable so any cache can answer. Image: Anthropic engineering blog.

Seven people, five months — and Claude itself

Beyond the numbers, the most savor-worthy part of the post is who built it and how. Scion plus Antique (the new review surface), plus code search, a fine-grained source-control IAM system, and novel machinery for landing large amounts of reviewed code — all from a seven-person team, in five months, with the full monorepo migrated off git.

And the finest detail hides in the "what we learned" section. Earlier in the year, the team had hand-written the first prototype of the git-to-Scion ingestion pipeline and felt good about it — until they got an internal build of Claude Mythos Preview (yes, the internal release named after their own model family) and asked it to rewrite the whole thing, with no further instructions. The result: 20x less memory, 4x faster, with every implicit invariant around ingestion ordering and data structures preserved.

Savor that loop: Claude's code-writing speed broke Git; then Claude helped seven people write Git's replacement in five months. The post's line — that Claude's ability to write code was both what put them in this situation and how they built a high-quality, scalable system to deal with it — isn't rhetoric. It's literal fact. This may be 2026's most honest field report on "AI writing code": it doesn't stop at the shallow narrative of "AI makes programmers faster," but shows what the entire engineering stack gets forced into once AI genuinely becomes the main producer of code.

"Coding is no longer the bottleneck" — worth reading word by word

The post opens with a passage I'd recommend every vibe coder read three times. Anthropic writes that, at their company, coding is no longer the bottleneck to building systems or doing research — Claude can autonomously iterate on research loops, micro-optimize complex programs, and build new services from the ground up at unprecedented speed and scale. The bottleneck, now, is "all of the developer infrastructure built for human scale: source control, builds, and CI."

When code output is no longer limited by typing speed, the bottleneck moves to every link designed for humans. The flood of merges won't slow itself down — it will simply wash away the weakest link next.

That nails the engineering reality of 2026. For a decade, developer infrastructure defaulted to one assumption: humans commit code, humans write a few hundred lines a day, humans need sleep, meetings, and reviews. The whole toolchain — branching models, PR flows, CI minutes, review queues — was tuned to that assumption. Agents just multiplied the "code output" variable by an order of magnitude or more, the assumption collapsed, and the toolchain has to be retuned. Anthropic puts it even more bluntly: the latent demand for merging code is "practically infinite," and every bottleneck removed immediately pushes code production to another level. This isn't a problem that converges; it's a process that keeps raising the ceiling.

Notably, Anthropic admits it's an extreme sample: it uses Claude to write software far more than almost any other company, so it's always the first to see where human-scale tools start to strain. But its judgment is that other organizations using AI coding tools will hit the same pressure points before long. This post is the wall-impact report, published in advance.

What it means for vibe coders: where's your next wall?

Back to those of us who don't work at Anthropic. What's this got to do with you? The direct answer: the reason agent-written code feels great today is that your merge rate is still low. But extend the curve — today one person directing 3 agents writing code in parallel, next year maybe 30 agents touching 30 branches at once, the year after an agent fleet refactoring your whole codebase 24/7. PR queues, CI minutes, review bandwidth, conflict resolution — the bottlenecks will surface one layer at a time. Anthropic's today is the high-intensity vibe coder's next year.

Three judgments you can borrow for your workflow right now:

• Think sparse: don't hand agents the whole repo. One of Scion's core insights is that agents usually don't need a complete repository. Give agents the minimal necessary context — it saves tokens and it saves infra. In a monorepo, check out only the directories being changed; in CI, query diff/blame via API instead of full clones. Your .gitignore and sparse-checkout setup deserve a re-review with "the reader is an agent" in mind.
• Separate "asking the repo questions" from "changing the repo." Many automation tasks (auto-bisect, auto-revert, change-impact analysis) only need read-only queries against the repo, which Scion turned into cheap APIs. You can apply the same thinking in your own CI: don't pull an entire repo to blame one line — use the GitHub API, shallow fetches, sparse checkouts.
• Design processes for agents, don't stuff agents into human-designed processes. Branching strategy, landing cadence, review mechanics all default to "a few co-located humans." When the committers become "online, concurrent, sleepless agent fleets," branch protection rules, required reviewer counts, and CI trigger policies all deserve a rethink. That's exactly why Anthropic built Antique: the old review surface was built for human eyes; the new one has to swallow 30,000 changes a day.

Zoom out one more level: version control may be the first thing to get rebuilt, but it won't be the last. Build systems, CI, code review, issue tracking, docs — the entire toolchain "built for human scale" is about to be revalued against agent concurrency. From late 2026 into 2027, we'll likely see a wave of "agent-native developer infrastructure" startups and rebuilds. Scion isn't open source (at least nothing says so yet), but its design principles are in the blog post — client-server asymmetry, incremental changeset commits, API-first, sparse working copies. Copying the thinking isn't illegal; waiting for others to finish copying is how you become the next "human-scale assumption" to be optimized away.

Git isn't dying. Anthropic says so itself: for the vast majority of repositories, git's decentralized design remains the right one. But "just use git" as the default option has its first crack. On the other side of the crack is the agent-scale continent — and Anthropic has already scouted it with seven people, five months, and 30,000 merges a day, then published the field guide for free. Anyone serious about vibe coding should read it.