The Interview Edge Blog
← Back to all guides
Claude · Source control at agent scale

Scion: Anthropic’s AI Wrote So Much Code It Broke Git — So They Replaced Git

In four months, Anthropic’s daily merges jumped from 2,500 to 30,000+ — mostly written by Claude coding agents. Git, built for humans on laptops, couldn’t keep up. A 7-person team built Scion, an in-house version-control system, and migrated the entire monorepo in five months. Here’s what broke, how the replacement works, and what it means for the rest of us.

Explain it like I’m five

Imagine a library where, every time you want to read one book, the librarian first hands you a photocopy of every book in the building — including all the books ever written there. That’s Git. It was designed so you could work on an airplane with no internet, and to make that possible, your laptop keeps the entire history of the repository.

That design is wonderful when a few dozen humans each grab the library a few times a day. Now imagine the library hires thousands of tireless robots that check books in and out 25 million times a day. Suddenly the librarians are spending all their time photocopying the whole building for robots that only wanted one book. That’s what happened at Anthropic — and Scion is their answer: a new library system where you ask for the book you want, the librarian finds it, and nobody photocopies anything else.

The numbers that forced it

Forget the architecture for a second — the growth curve is the whole story. In May 2026 Anthropic merged about 2,500 code changes a day. By September it was merging over 30,000 a day, a 10x+ jump in four months. The company attributes it directly to Claude-powered coding agents generating and submitting changes at machine speed — writing code is no longer the bottleneck, managing the code afterward is.

  • Main-branch history alone: nearly 100 GB.
  • Compressed working copy: over 25 GB — bigger than most laptops’ patience for a fresh clone.
  • ~25 million automated checkouts per day for CI and research jobs. Fetched the naive way, Anthropic says that would be 600+ petabytes of Git traffic per day.
  • Engineer output: the typical Anthropic engineer merged about eight times as much code per day in Q2 2026 as in 2024 — and automated review coverage was estimated to catch roughly a third of the bugs behind earlier incidents.

Here’s the part Anthropic keeps coming back to: the growth isn’t expected to slow. Removing a bottleneck just reveals more latent demand for merging code. Whatever system they built had to survive the next 10x, not just this one.

Why Git couldn’t scale

Nothing about Git is broken for you and me. What broke is an assumption Git makes about who is using it.

Git assumes clients work offline and need a complete copy of the repository. That’s what makes it pleasant on a laptop — full history, instant git log, work on a plane. But it’s a terrible assumption when the “client” is a CI job that only needs one directory and will never read the history. Every one of those 25 million daily checkouts had to negotiate with history it would never touch. Anthropic had been absorbing that load with a fleet of Git mirrors — and by their own description, that mirroring infrastructure was the thing about to fall over.

The honest framing

Anthropic isn’t claiming Git is bad — they’re saying it was built for human scale: a developer cloning a repo, working offline, pushing a few times a day. An agent fleet that merges 30,000 changes a day is a different species of user. When the species changes, the plumbing has to change with it.

How Scion works

Scion flips Git’s assumption. Instead of the client holding everything and syncing, the client holds almost nothing and asks the server — an online client-server design.

The unit of work: the changeset

Scion organizes around a changeset — one entry in a write-ahead log of changes, rather than Git’s commit graph of full snapshots. Think of it as the difference between a ledger of transactions and a stack of whole-account photos. The ledger records what changed; everything else (what the code looked like at any point) is computed from it on demand.

The server does the heavy lifting

Commits, merges, rebases, file history, blame — all of it happens server-side. Your checkout doesn’t need to contain the machinery to answer “who changed this line?” because it can just ask. This is the core of the flip: work moved from thousands of beefy clients to a central server built for it.

Checkouts that fetch only what they touch

Scion supports sparse and virtualized checkouts: your working directory pulls files on demand, the moment something reads them. A CI job that needs three files in one directory fetches three files — not 25 GB of history it will never open. Distributed caches then serve repository objects across the fleet without anyone keeping a full local copy. And because source-control data is exposed through an API, automated jobs can query repository state — “what does this path look like at this changeset?” — without any checkout at all.

Old world

Clone the whole repo, keep full history locally, run merges and blame on your machine. Great for a human on a laptop.

New world

Checkout is a window into the server: files stream in when read, merges and history run server-side, caches serve hot objects. Great for 25 million automated checkouts a day.

The one-line version: Git is a filing cabinet you carry with you. Scion is a librarian you call.

What Anthropic got

The reported payoff numbers are striking — and they’re the reason this story traveled.

  • ~200x smaller CPU/memory footprint than the previous Git-mirroring infrastructure it replaced.
  • Checkouts went from minutes to seconds for research and CI jobs — roughly a 100x speedup on the thing developers felt most.
  • ~25% of CI CPU capacity freed up — the migration effectively bought back a quarter of their CI fleet.
  • >99% cache hit rates claimed across their coverage, which is what makes the on-demand fetching actually fast instead of just theoretically fast.

And the build itself is part of the story: seven people, five months, start to full monorepo migration. The company has been upfront about the poetic loop here — Claude’s code-writing ability is what created the 10x merge surge, and it’s also what made it possible to build the replacement so quickly. The bottleneck moved upstream, from writing code to managing it, and the tool that caused the move also helped dig the new channel.

Scope note

Anthropic is explicit that Scion is not a general-purpose Git replacement and is not being open-sourced — it’s bespoke to their agent-scale monorepo. They say they plan to share the approach with GitHub, GitLab, and open-source projects, but broad adoption would require major toolchain changes.

What came with it

Scion didn’t ship alone. The migration produced a small ecosystem of new tooling, all built in the same five-month window.

  • Antique — a new code-review interface. When 30,000 changes land a day, the review surface has to change too: humans don’t read diffs one by one anymore; they supervise, set objectives, assess results, and correct agent shortcuts.
  • A new code-search system — searching a repo that changes 30,000 times a day needs infrastructure built for that write rate.
  • A source-control identity and access-management system — deciding which agent, job, or human can touch which paths at machine speed.
  • Large-scale landing and merge tooling — new machinery for safely landing huge volumes of reviewed code onto the main branch.

The pattern is the point: at agent scale, source control isn’t one tool — it’s a platform. The write-up treats Scion, Antique, search, and IAM as one project because at 30,000 merges a day, they genuinely are.

Where this matters in real work

You almost certainly won’t adopt Scion — you can’t, it isn’t available. But the forces that built it are coming for your tooling too. Here’s where the lesson lands.

Agent fleets

If your team is running coding agents at any real scale — nightly agent runs, agent-driven refactors, fleets of parallel agents — watch your CI and source-control costs per merge. Anthropic’s lesson is that the per-merge overhead of human-era tooling becomes the dominant cost long before the agent output itself does. Measure merges/day and cost/merge now, while the numbers are small.

Monorepo teams

Anyone on a large monorepo with heavy CI has felt the Git-mirror tax. Scion’s design vocabulary — sparse checkouts, virtualized files, server-side blame and history, object caches — is the checklist to evaluate your own setup against. You may not need a new VCS; you may need VFS for Git, partial clone, or better cache hit rates.

Interviews

This story is catnip for system-design interviews: “design a version-control system for 30,000 merges a day” is a concrete, bounded design question with real constraints (write-ahead log vs snapshot graph, client-server tradeoffs, cache design, IAM). The Scion post is effectively a reference solution. Expect it to show up in loops at the companies running agent fleets.

Tooling builders

If you build dev tools, the takeaway is directional: every tool in the inner loop — search, review, CI, identity — gets redesigned for the assumption that most commits are machine-authored. The companies that ship those redesigns first set the defaults for the next decade.

The industry pattern

Anthropic isn’t the first company to outgrow stock Git — they’re the first to do it because of AI agents. The lineage is worth knowing.

  • Google — Piper: Google’s centralized monorepo system, the classic example of one repo for an entire company, with a custom client-server design.
  • Microsoft — VFS for Git: the virtualized-filesystem approach that lets Windows-scale checkouts fetch files on demand — the closest existing cousin to Scion’s virtualized checkouts.
  • Meta — Sapling: Meta’s VCS, open-sourced, built for enormous monorepos with a design that trades away some of Git’s guarantees for scale.
  • GitHub, April 2026: GitHub itself noted that PR and commit growth was straining availability — the human-era infrastructure was already creaking before agents poured fuel on it.

The through-line: every generation of scale has produced a bespoke answer to “Git, but bigger.” Scion is the first answer to “Git, but written by machines.”

FAQ

FAQ
Is Scion open source? Can I use it?

No. Anthropic has said it’s bespoke to their agent-scale monorepo and not a general-purpose Git replacement. They plan to share the design approach with GitHub, GitLab, and open-source projects, but you can’t download it.

FAQ
Did Anthropic really replace Git because of AI agents?

That’s their own account: merges went from ~2,500/day in May 2026 to 30,000+/day by September, driven by Claude-powered coding agents, and the human-scale source-control infrastructure became the bottleneck. Writing code stopped being the constraint; managing the code afterward became it.

FAQ
How can a 7-person team replace Git in five months?

They didn’t replace all of Git — they replaced the parts their monorepo needed, built around a narrower design (online client-server, changeset log, server-side operations). And they had Claude writing code alongside them, which is the poetic part: the tool that created the bottleneck helped build the replacement.

FAQ
Should my team leave Git?

Almost certainly not. Scion solves a problem you get at ~30,000 merges a day from machine authors. If your team merges dozens or hundreds of changes a day from humans, Git plus good CI is still the right answer. The useful question is whether your per-merge overhead is growing — that’s the early warning sign.

FAQ
What’s the interview angle?

“Design a version-control system for 30,000 machine-authored merges a day” is now a legitimate system-design question with a published reference solution. The key moves to name: write-ahead changeset log instead of snapshot graph, server-side merges/history/blame, sparse and virtualized checkouts, distributed object caches, and source-control-as-API for automated jobs.

FAQ
Why does this matter for Claude Code users?

It’s the clearest signal yet of where the industry is going: the companies building the coding agents are already rebuilding the infrastructure underneath them. Your inner loop — search, review, CI — will look different in two years, and this post is the roadmap.

Sources

The numbers and design details above come from these reports — all original wording here, facts credited below.

Anthropic engineering blog: “Redesigning source control at Anthropic” (Oct 13, 2026) — the primary source ↗
The Register: Anthropic reinvents source control as Claude floods the world with code ↗
Tech Insider: Anthropic Scion — 30,000 code merges a day explained ↗
Crypto Briefing: Anthropic’s code merges jump 10x, Scion replaces Git ↗
AI Brief: Anthropic replaces Git with Scion for its monorepo ↗
DEV: Claude took Anthropic from 2,500 to 30,000 merges a day — then it moved off Git ↗

Published October 13, 2026 — the same day Anthropic’s post went up. Figures are Anthropic’s own reported numbers; industry context (Piper, VFS for Git, Sapling) is background knowledge.

Key takeaways

  1. Anthropic’s merges went from ~2,500/day (May 2026) to 30,000+/day (September) — mostly written by Claude coding agents. Writing code is no longer the bottleneck; managing the code is.
  2. Git broke because it assumes offline clients with complete repo copies — the wrong assumption when 25 million automated checkouts a day only touch a few files each.
  3. Scion flips it: an online client-server design where the changeset is the unit of work, the server handles merges/history/blame, and checkouts fetch files on demand through distributed caches.
  4. The payoff: ~200x smaller CPU/memory footprint than the Git-mirror fleet, checkouts in seconds instead of minutes, ~25% of CI CPU capacity freed — built by 7 people in 5 months.
  5. It shipped with Antique (code review), new code search, source-control IAM, and large-scale landing tooling — at agent scale, source control is a platform, not a tool.
  6. It’s not open source and not a general Git replacement — but it’s the first published answer to “Git, but written by machines,” and a ready-made system-design interview reference.
Read nextSkills vs Subagents vs Hooks: Three Claude Code Features, Three Different Jobs →