Anthropic merged 30,401 changes into its monorepo on September 9, 2026. That’s not a typo. In May, the company was averaging around 2,500 merges per day. By September, that number had grown more than tenfold, and the tools built for human-scale development couldn’t keep up.
So Anthropic did what any reasonable company would do: it built its own version control system from scratch, migrated a 100 GB monorepo off Git in five months, and did it with a team of seven people. The system is called Scion, and it represents the first serious architectural rethink of source control since Git became the industry standard.
But here’s what’s actually interesting: the problem wasn’t that Git is bad. The problem is that AI agents fundamentally changed the assumptions source control was built on, and nobody had bothered to question those assumptions until they became a hard bottleneck.
When Your Codebase Outgrows the Tool That Made It Possible
Let’s get the numbers out of the way, because they’re genuinely staggering. Anthropic’s main branch history is almost 100 GB. A compressed working copy exceeds 25 GB. The company performs roughly 25 million code checkouts per day for CI alone, before counting developer environments, agent sandboxes, and research jobs. Fetched naively, that’s over 600 PB of Git traffic per day.
That’s not a scaling problem. That’s a physics problem.
Git is a decentralized system: every clone is a complete, self-contained repository that can compute diffs, read history, run blame, and check out any revision while fully offline. For the vast majority of repositories, this is the right design. It’s a large part of why Git became the standard in the first place.
But Anthropic was using Git the way most companies secretly do: as a centralized system with one authoritative copy. The difference is that nearly all of Anthropic’s clients are agents and jobs that are online by definition. The properties that make Git excellent for distributed, offline work, complete local copies, full history, packfile compression, were actively undermining the company’s ability to scale.
The company threw every workaround Git offers at the problem: shallow clones, sparse checkouts, promisor remotes, internal mirrors, and repository snapshots stored in blob storage. At peak, Anthropic operated several hundred internal Git mirrors. It bought time, but it couldn’t buy architecture.
The Six Principles That Killed Git at Anthropic
Scion’s design philosophy reads like a direct rebuttal to everything Git assumes about how software gets written. The engineering team, drawing on prior art from Google’s Piper and Meta’s Sapling, built the system around six principles:
Clients are always online. Git assumes offline capability. Scion assumes the opposite, agents and jobs live on the network, so clients fetch data when they need it rather than holding a complete copy.
Client-server asymmetry. In Git, every client is a potential server. In Scion, the server handles the heavy lifting: history, blame, commits, merges, rebases. The client maintains a bounded local object cache, lays out working copy files, monitors filesystem changes, and provides an ergonomic interface. It can compute almost nothing on its own, but it needs far less data locally.
Source control as a service. With Git, a CI job that needs to answer a question about the repository, who last changed a line, how two commits relate, has to maintain a local copy. With Scion, every query the client uses is exposed via API. That means many jobs don’t need a local repository at all.
Horizontal scalability everywhere. There is no fully materialized copy of the repository anywhere, even on the server. No packfiles, no repository maintenance. Every component scales independently.
Commits are cheap, incremental, and lock-free. Every commit, rebase, and merge happens server-side. Cost scales with the size of the change, not the size of the repository. Refs are discouraged except for main and release branches, because global state that every server must agree on is a looming scaling problem.
The working copy is optional and sparse by design. A CI job that needs the diff between a commit and its merge base can ask the server directly. Virtualized checkouts materialize files on demand, so clients only pay for what they actually read.
Changesets, Derived Data, and a Three-Tier Cache Architecture
The technical implementation is where Scion gets genuinely clever. The unit of work is a “changeset”, an entry in a write-ahead log. Unlike a Git commit, which stores a pointer to a tree, a changeset stores a list of files that changed relative to its first parent, along with content-addressed pointers to compressed file contents in blob storage.
This structure is what enables Scion’s high throughput. There are no packfiles to accept, no locking, no cross-server coordination, no refs to move around. Moving a ref is a compare-and-swap on a single Spanner row, completely separate from creating changesets.
But a changeset alone can’t answer questions like “who last edited this line?” or “which commits affected this file?” For that, Scion builds derived data, dedicated structures for file blame, path history, and skip lists for the commit graph. Each type is defined recursively, computed from its values for the changeset’s parents. This design lets the team add new derived data types without changing the client, and choose between eager or deferred computation for each type.
The checkout path looks like a classic tiered cache hierarchy. The scn client talks over a socket to scion-daemon, which stores objects for the entire node. The daemon fetches from regional scion-cache servers, which stream objects directly from memory in the disk format the daemon will consume, no delta compression, no computing missing objects. When a cache misses, it asks the authoritative scion-server, which reads from Spanner or cloud storage as needed.
Each tier maintains a cache hit rate above 99% and requires no long-lived state. The three tiers respond to identical RPCs, but Anthropic strictly enforces the hierarchy to isolate failure domains. A failing regional cache can’t overwhelm the upstream servers and take down the whole system.
The results speak for themselves:
| Metric | Result |
|---|---|
| Infrastructure footprint | 200x smaller than Git mirror fleet (CPU and memory) |
| Checkout speed | Two orders of magnitude faster (seconds vs. minutes) |
| CI capacity | 25% CPU capacity win |
| Cache hit rate | >99% at every tier |
Claude Built the Replacement for the System Claude Broke
Here’s where the story gets properly recursive. Scion wouldn’t exist without Claude, but Claude is also the reason Scion became necessary in the first place.
Anthropic started building Scion around the same time Claude Mythos Preview and Claude Tag became available internally. The team had handwritten the first version of the Git-to-Scion ingestion pipeline as a prototype, and they thought it was solid. Then they gave an early snapshot of Claude Mythos Preview the task of rewriting it, with no further instructions.
The result: a version that consumed 20x less memory and ran 4x faster, while preserving all the implicit invariants around ingestion ordering and data structures. A model casually outperformed what expert engineers had built by hand, and it did it in the time it takes to run a prompt.
This pattern repeated across the project. Claude found an algorithmic optimization to ancestry queries that had missed one of the team’s indexes, work that would have taken an expert days or weeks of analysis. Then it did it again the next day.
The team’s engineers now openly admit that Claude writes better code than they do. But that doesn’t mean the engineers became obsolete. Their role shifted from writing code to telling Claude “no.” Agents sometimes violate core system constraints to satisfy a pattern that shouldn’t exist. Adversarial review, while incredibly effective, can be myopic, pushing Claude toward over-engineering in response to hypothetical concerns.
One example from the post: multiple systems tried to brute-force lookup when a change merged to main by linearly reading the commit log, instead of asking the code review tool. The human engineers had to catch this and redirect the agents toward the proper API.
What Agent-Scale Development Actually Means
The most provocative part of Anthropic’s post isn’t the technical architecture, it’s the philosophical rethinking of what development infrastructure should look like when agents, not humans, are the primary writers of code.
Consider the merge queue. Anthropic discovered that a global repository lock doesn’t make sense at agent scale. When hundreds or thousands of changes can merge while tests are still running, the entire concept of a pre-merge gate breaks down. The company’s response was to invest heavily in post-merge and pre-deploy automated testing, accepting that concurrent changes will conflict. Claude can typically fix those conflicts faster than humans can even identify them.
What does CI even mean when changes merge faster than test suites can run? This is a question that most engineering organizations haven’t started asking, and Anthropic’s answer, shift testing to post-merge, rely on automated conflict resolution, runs counter to decades of received wisdom about how software should be delivered.
There’s also the question of human oversight. Anthropic’s engineers still review every change request, but they now examine the intent of the change rather than reading every line of code. That’s a fundamentally different job than what code review has meant for the past twenty years.
The Security Angle Everyone’s Missing
Lost in the discussion about merge rates and cache hierarchies is the fact that Scion was built with security as a first-class concern from day one. It supports rich access control on repositories, plus the ability to apply permissions to individual directories. That means the most sensitive code can be protected without losing the benefits of a monorepo.
The accompanying code review tooling (Antique) can express complex semantic constraints on approvals. It can differentiate simple comment-only changes from sensitive logical changes, so human reviewers can focus on the most consequential work.
This matters because the broader ecosystem is already seeing the consequences of AI pipelines without adequate guardrails. The security vulnerabilities in AI development tools and trust in pipelines that emerged after Microsoft’s open-source hack earlier this year are a warning shot. And the risks of accidental code exposure in AI development pipelines that Anthropic itself demonstrated with the npm source map incident show what happens when infrastructure outpaces security thinking.
The Operational Weirdness: “Superfan” Claudes
The most unusual operational practice to emerge from Scion is the “superfan” system. Anthropic uses Claude Tag to create Slack channels where dedicated Claude instances obsessively monitor individual components. There’s a scion-daemon superfan, a scion-cache superfan, an Antique merge queue superfan, each with access to telemetry and logs, each behaving like an experienced engineer whose only job is to refresh charts and look for anomalies.
Traditional alerts still exist, but the superfans can detect subtle and novel issues that one-dimensional alerting systems miss. It’s a genuinely new operational model: AI systems monitoring the AI systems that monitor the infrastructure that runs the AI systems that write the code.
What This Means for Everyone Else
Anthropic is explicit that Scion isn’t a general-purpose Git replacement. The concepts only make sense for truly enormous monorepos with tens of thousands of engineers or swarms of agents writing code. There’s no public release plan, and the company acknowledges that its internal versions of code review, code search, and CI are so bespoke that a public version wouldn’t be useful to anyone.
But the broader lessons apply well beyond Anthropic’s scale. The company expects this class of problem to become commonplace over the next six to twelve months, and it’s actively discussing collaboration with GitHub, GitLab, and the open-source community.
For teams adopting AI coding tools, the practical takeaways are these:
Measure your human-scale assumptions. CI wait times, review queues, branch protection rules, mirror setups, all of these were designed for people committing a few times a day. If you adopt agents, these systems will be your next bottleneck.
Make repository questions an API. Even without a new VCS, exposing blame, merge-base, and history through a service avoids every job cloning the repo. Anthropic’s automated bisect and revert pipelines wouldn’t be practical at scale without cheap programmatic access to source control.
Revisit the merge queue. Post-merge testing with fast automated repair is a different risk model from a pre-merge gate. It’s worth making that decision deliberately rather than inheriting an outdated default.
Keep humans on intent. Anthropic’s reviewers don’t read every line anymore. They examine what a change is trying to accomplish and whether the approach is sound. That’s a different skill than line-by-line review, and it’s one worth developing.
The broader industry shift is already underway. Cursor’s Origin git hosting for AI agents is a commercial attempt at the same problem, and the shift toward open-weight models in large-scale AI collaboration suggests that the tools supporting AI development will become as important as the models themselves.
Git isn’t dead, and Anthropic isn’t claiming it should be. But the company has demonstrated something important: when the fundamental assumptions of your tools stop matching the reality of how you work, you have two options. You can keep applying workarounds and hoping the problem resolves itself. Or you can ask what the right tool looks like when designed from first principles for the world you actually live in.
Anthropic chose the second path, and it did it in five months with seven people. That’s the real story here, not that Git broke, but that a small team, empowered by the very agents that caused the problem, could redesign a foundational piece of developer infrastructure faster than anyone thought possible.
The next bottleneck isn’t going to be source control. It’s going to be whatever assumption about human-scale development hasn’t been questioned yet. The teams that start questioning those assumptions now, before the agents make them unignorable, are the ones that won’t need to build their own version control system in a panic.
