Anthropic Builds Scion to Replace Git: Daily Merges Surpass 30,000

When the rate of code changes outpaces the capacity of the tools themselves, switching tools becomes the only option. In an official blog post, Anthropic's engineering team disclosed the full motivation and implementation process behind their self-built version control system, Scion—the company's core codebase merge volume surged more than tenfold in six months, and their existing Git infrastructure could no longer keep up.

Tenfold Increase in Six Months: Git Can't Keep Up

Anthropic's published figures are strikingly direct: in May 2026, the company merged approximately 2,500 code changes per day on average; by September, that number had exceeded 30,000. In just four months, the pace of scaled code production underwent a leap of an order of magnitude.

Simon Willison analyzed Anthropic's published merge volume chart on his blog, overlaying the company's model release dates onto the graph. The trend shows that three sharp increases in merge volume correspond to the releases of Fable 5 and Mythos 5 (June 9), Opus 5 (July 24), and Fable 5.1 and Mythos 5.1 (September 1). Willison concludes that internal deployment of the Fable and Mythos series models was the key catalyst for the jump in coding speed.

What truly pushed Git to its limits wasn't the merge volume itself, but the scale of checkouts. Anthropic provided a staggering figure in their post: the main branch history is approximately 100 GB, and the compressed working copy exceeds 25 GB. In CI scenarios alone, roughly 25 million code checkouts are performed daily. Excluding developer environments, agent sandboxes, and research tasks, naive fetch operations alone would generate over 600 PB of Git traffic per day.

Why does Git become a bottleneck under high-frequency checkout scenarios? Git is a distributed version control system (DVCS), designed around the principle that each developer holds a complete repository copy, with operations performed locally and synchronized over the network. This model is extremely efficient under the premise of "limited commit frequency from human developers," but when checkout operations jump from millions to 25 million per day, the server side must repeatedly handle clone, fetch, and pack operations, placing enormous pressure on network bandwidth and storage IO. While Git's packfile object storage offers high compression efficiency, each checkout still requires decompression and rebuilding of the working tree—especially with a 100 GB-level main branch history, where a single full clone can consume tens of gigabytes of bandwidth. Furthermore, Git's reference management and index design are geared toward medium-scale repositories. When facing extremely large histories and high concurrency, it lacks the natural advantages of centralized systems—"fetch only what's needed, cache on demand." This is precisely the fundamental reason Anthropic chose to return to a centralized architecture.

Scion and Antique: A Complete Replacement Solution

Anthropic didn't just replace Git itself—they rebuilt the entire chain from version control to code review in one go.

The new version control system is named Scion, and its design approach was described by Simon Willison as "a centralized source control reinvention along the Subversion line"—not an improvement on the distributed model, but a return to centralized architecture to solve scale problems. The code review system is named Antique, which began appearing in merge data at the end of May and had largely replaced the original Pull Request workflow by mid-July.

The entire migration was completed by a team of seven, with the switch from Git to Scion taking five months. For a system carrying all of the company's core code and handling tens of millions of checkouts daily, this pace is quite aggressive.

Key differences between centralized and distributed version control. Centralized version control (such as Subversion and Perforce) relies on a single central server to store all history and files; clients only retrieve the working copy they need, and both commits and checkouts interact directly with the server. This approach offers clear advantages in ultra-large repositories and high-frequency checkout scenarios: the server can uniformly optimize caching, transfer at file granularity, and precisely control permissions and auditing, without requiring every client to maintain the full history. Distributed version control (such as Git) includes the complete history in every copy, offering great flexibility for offline operations and branch merging, but synchronization costs rise sharply when repositories are enormous and concurrency is extremely high. Scion being described as "a centralized reinvention along the Subversion line" means it's closer to Perforce or Google's internal Piper approach: using centralized storage and intelligent caching to support massive checkouts, rather than relying on local operations on distributed copies.

Adversarial Review Works Well, But Can Go Off Track

Anthropic also revealed an engineering practice detail worth noting: during the construction of Scion, they made extensive use of adversarial review—having models actively seek out flaws in design proposals.

Simon Willison corroborated similar personal experiences on his blog—he recently tried having Claude and GPT critique each other on his own projects. This approach is indeed extremely effective in many scenarios, but Anthropic also acknowledged its side effect: adversarial review is "effective in many ways, but can also be narrow-sighted," forcing engineers to spend effort steering Claude away from over-engineering certain parts of the system in response to hypothetical problems.

This observation deserves attention from all teams introducing AI review into their engineering workflows: models are good at finding flaws, but lack the judgment to determine "which flaws are worth fixing." Human judgment remains irreplaceable in the loop.

The mechanism and limitations of adversarial review. Adversarial review refers to having a model or agent specifically play the role of "critic," actively seeking out defects, edge cases, and potential failure modes in design proposals, code, or architecture. A common approach is having two models review each other, or having the same model reason in reverse under the premise that known answers contain flaws. This method works because generative models tend to be sharper in "finding problems" mode than in "writing code" mode, capable of identifying assumptions that human reviewers easily overlook. But its core weakness is the lack of prioritization: the model treats all potential issues equally, including hypothetical defects that are nearly impossible to trigger in actual operation, thereby driving over-engineering. Anthropic engineers needed to provide extra guidance to prevent Claude from restructuring systems around imaginary problems—demonstrating that the output of adversarial review must be filtered through human judgment before it can translate into effective decisions.

What This Really Demonstrates

Anthropic's story of building its own version control system appears on the surface to be an infrastructure engineering case study, but in essence reflects a broader trend: AI-assisted coding is shifting the bottleneck of software engineering from "writing code" to "managing code."

When models can generate code changes at extremely high rates, traditional code review, version control, and CI checkout processes all become new constraints. Anthropic's approach was to build an entire toolchain in-house, but this isn't realistic for the vast majority of teams. The more universal question may be: how fast an AI coding pace can existing development infrastructure actually sustain?

The phased migration of software engineering bottlenecks. Over the past two decades, the primary bottleneck in software engineering has shifted multiple times—from "writing code" to "integration and delivery" to "observability and operations." Each shift was driven by the evolution of toolchains: IDEs and high-level languages lowered the barrier to coding, CI/CD solved integration efficiency, and cloud-native and observability tools alleviated operational pressure. AI-assisted coding is now driving a new round of migration: when models can generate code changes at extremely high speeds, the "downstream" links—version control, code review, CI checkout—become the new constraints. Anthropic's case shows that if these links aren't upgraded accordingly, the coding acceleration brought by AI will be canceled out by infrastructure bottlenecks. For most teams, building an entire toolchain in-house isn't realistic; the more feasible path may be optimizing existing workflows, introducing more efficient caching layers, or re-examining the granularity and automation level of code review.

One-line Summary

Anthropic's merge volume surged due to faster AI coding, prompting them to build Scion as a Git replacement.

Paragraph Summary

Anthropic's engineering team disclosed that their core codebase's daily merge volume surged from about 2,500 to over 30,000 in four months, with main branch history at approximately 100 GB and roughly 25 million CI checkouts per day—Git infrastructure could no longer keep up. To address this, a seven-person team spent five months building a centralized version control system called Scion, along with a code review system called Antique, which largely replaced the original Pull Request workflow by mid-July. Internal deployment of the Fable and Mythos series models is considered the key factor behind the leap in coding speed. Anthropic also shared their experience with adversarial review: models are good at finding flaws but lack prioritization, easily over-engineering around hypothetical problems and requiring engineer intervention. This case demonstrates that AI-assisted coding is shifting the software engineering bottleneck from "writing code" to "managing code."