Anthropic Scion Replaces Git as AI Agents Drive 30,000 Daily Merges

Then came the autonomous coding agents.

On October 13, 2026, Anthropic published an engineering breakdown detailing how its own Claude models generated such a massive deluge of code that the company had to abandon Git for its primary monorepo and build an in-house version control system called Scion. As reported by The Register and detailed in Anthropic’s engineering blog, the company’s daily merged code changes jumped more than twelvefold in four months—rising from roughly 2,500 merges per day in May 2026 to more than 30,000 per day by September 2026. Earlier in June 2026, VentureBeat and Tom's Hardware reported Anthropic's disclosure that Claude was already authoring more than 80% of the code merged into its production codebase.

For enterprise architects, DevOps engineers, and Windows developers relying on Git, GitHub, and Azure DevOps pipelines, Anthropic’s five-month migration is more than a Silicon Valley curiosity. It is an early stress test of what happens to standard software development lifecycle (SDLC) tooling—source control, code review, build systems, and continuous integration (CI)—when the primary consumer of your repository is no longer a human sitting at an IDE, but a swarm of always-online AI agents.

The Numbers Behind the Code Flood​

To understand why a company would take on the notoriously painful task of writing a custom version control system, you have to look at the geometry of Anthropic's monorepo. According to Anthropic’s engineering team, writing code is no longer their primary productivity bottleneck; managing, testing, and landing that code is.

By October 2026, Anthropic's repository metrics had reached scales usually reserved for the largest hyperscalers:

That 600-petabyte figure is a counterfactual estimate—what would happen if 25 million daily jobs pulled the repository naively—rather than actual network traffic across Anthropic’s switches. Before building Scion, Anthropic used the standard enterprise Git survival kit: shallow clones, sparse checkouts, promisor remotes, repository snapshots ("seeds") stored in blob storage, and, at peak, several hundred internal Git mirrors.

Why did those workarounds break down? In a traditional enterprise environment, commits trickle in at human velocity, giving mirrors and blob-storage snapshots plenty of time to synchronize. When AI agents began landing 30,000 changes a day, the "seeds" fell farther and farther behind the tip of the main branch between refreshes. Meanwhile, maintaining history-dependent operations like git diff and git blame on partial clones grew increasingly fragile, and the repository eventually outgrew the memory and disk limits of the mirror fleet.

Summary: The Breaking Point​

• The Bottleneck Shifted: AI agents removed code authoring as the rate limiter, turning source control, build pipelines, and CI into the primary choke points.
• Workarounds Saturated: Even with hundreds of internal Git mirrors, shallow clones, and blob-storage seeds, 30,000 daily merges caused snapshots to lag too far behind main.

Why Distributed Git Clashed with Always-Online Agents​

Git’s greatest strength is decentralization. Every clone is a peer capable of acting as a full server, holding the commit graph, computing diffs locally, and operating completely offline.

Anthropic’s engineers realized that their modern workload inverted every one of those assumptions. While companies almost universally treat Git as a centralized system with one authoritative trunk (usually hosted on GitHub, GitLab, or Azure DevOps), Anthropic’s clients were overwhelmingly CI runners, research jobs, and AI agent sandboxes. Those clients are online by definition. Paying the network, disk, and CPU tax to equip millions of ephemeral, always-connected containers with local repository state was actively sabotaging their infrastructure.

Anthropic is hardly the first tech giant to hit the wall with massive monorepos:

• Google operates Piper, a massive centralized monorepo system paired with CitC (Clients in the Cloud) and Gerrit for reviews.
• Microsoft tackled the Windows OS repository problem years ago by developing VFS for Git (formerly GVFS) and later Scalar, virtualizing the filesystem so Windows developers wouldn't choke their NVMe drives checking out millions of files.
• Meta built Sapling, a scalable, user-friendly source control system with a Mercurial-inspired architecture designed to handle massive repositories by fetching data on demand.

Drawing from the lessons of Google’s Piper and Meta’s Sapling, a seven-person team at Anthropic spent five months building and migrating to Scion, alongside a custom code-review interface named Antique, a code search engine, and a granular source-control Identity and Access Management (IAM) system. As software developer Simon Willison noted in his analysis of the announcement, Scion reads in some ways like a modern, cloud-scale reinvention of centralized version control along the lines of Apache Subversion—except tailored specifically for automated agent swarms.

Summary: Centralization Returns​

• Offline Capabilities Were Wasted: AI agents and CI jobs do not code on airplanes; they live inside data centers with persistent, low-latency links to backend servers.
• Standing on Prior Art: Scion follows in the footsteps of Google Piper, Meta Sapling, and Microsoft VFS for Git, trading local autonomy for centralized, API-driven scale.

Inside Scion: How Agent-Scale Source Control Works​

How do you design a version control system when 25 million jobs a day want to inspect or modify code? According to Anthropic’s engineering post, Scion throws out the symmetric client-server model and replaces it with strict asymmetry, immutable cloud storage, and Google Cloud Spanner.

1. Changesets Instead of Tree-Pointer Commits​

In Git, a commit points to a root tree object representing a full snapshot of the repository, and objects are periodically bundled into compressed packfiles. In Scion, there are no packfiles and no repository maintenance passes.

The atomic unit of work is a changeset—an entry in a write-ahead log created directly on the server. Instead of pointing to a full tree, a Scion changeset records only the list of files that changed relative to its first parent, paired with content-addressed pointers to the compressed file contents in blob storage.

Because changesets are created server-side without packfile generation or cross-server locks, commits become instantly available across the fleet. Scion largely avoids Git-style refs (branches and tags) for everyday work because forcing every server to agree on global mutable state creates a synchronization bottleneck. Moving the main ref is handled separately from changeset creation as an atomic compare-and-swap operation on a single Spanner row.

2. Recursive "Derived Data" on the Server​

If a changeset only lists changed files, how do you run blame or trace file history without traversing the entire log from the beginning of time?

Scion solves this on the server side using derived data. Whenever changesets land, Scion servers recursively compute auxiliary data structures from parent changesets—such as skip lists for the commit graph, path-history indexes, file-blame maps, and copy-detection indexes—and write them back to Spanner. Because clients never touch the raw internals of these structures, Anthropic’s engineers can add new index types or choose whether to compute them eagerly or lazily without updating the client software.

3. API-First Queries and Optional Working Copies​

In a standard Git CI pipeline, if an automated tool wants to know who last modified line 42 of a file or compute the diff between a commit and its merge base, it typically clones at least part of the repo or leans on vendor-specific web APIs.

In Scion, every source control query is a native RPC. Internal tools—such as automated bisect and auto-revert pipelines—query the server directly without ever creating a local repository. Even write workloads can often bypass checking out files to disk, operating purely via API. When a job does need files on disk, Scion defaults to sparse checkouts (fetching only requested directories) and virtualized checkouts (materializing files on demand when read).

4. Three-Tier Caching Without Packfile Negotiation​

When a Git client fetches updates, it engages in a chatty negotiation with the server to figure out which objects the client already possesses, after which the server dynamically builds and streams a packfile. That CPU-intensive compression and delta calculation is what brings Git servers to their knees during a CI thundering herd.

Scion’s scn client flips the protocol: it never tells the server what it has; it only asks for the specific, immutable, content-addressed trees and blobs it wants. Requests flow through a strictly enforced three-tier hierarchy designed to isolate failure domains:

1. scion-daemon (Node Level): Runs locally on each compute node over a socket, starting from a periodic snapshot and sharing cached objects across all CI jobs or agent sandboxes on that machine.
2. scion-cache (Regional Level): Streams requested objects straight from memory in the exact disk format the node daemon expects—zero delta compression or CPU-heavy packaging required.
3. scion-server (Authoritative Level): Handles cache misses by reading from Spanner or cloud blob storage.

According to Anthropic’s self-reported production figures, every tier in this hierarchy maintains a cache hit rate above 99%. Compared to its former fleet of several hundred Git mirrors, Scion’s infrastructure footprint uses 200 times less CPU and memory, checks out code in seconds rather than minutes (two orders of magnitude faster), and freed up 25% of total CI CPU capacity.

Summary: Architectural Tradeoffs​

• Server-Side Heavy Lifting: Commits, merges, rebases, blame, and history queries happen on the server via Spanner and derived data indexes.
• Dumb Fetch, Smart Cache: By requesting immutable content-addressed blobs rather than negotiating dynamic packfiles, Scion achieved a >99% cache hit rate and a 200x reduction in server footprint.

When the AI Writes the Infrastructure—and Humans Just Say "No"​

Perhaps the most revealing part of Anthropic’s report is how a team of just seven engineers managed to build a version control system, a custom code review portal (Antique), code search, and IAM controls—and migrate a 100 GB monorepo to them—in five months while daily merge volume grew tenfold.

The answer, unsurprisingly, is that they used internal builds of Claude Mythos Preview and Claude Tag to write the vast majority of the system.

In one concrete internal case study shared by the team, engineers had handwritten an early prototype of the Git-to-Scion ingestion pipeline. When an early internal snapshot of Claude Mythos Preview became available, they asked the model to rewrite the pipeline with no additional instructions. According to Anthropic, the model produced a replacement that ran four times faster and consumed 20 times less memory while preserving all implicit ordering and data-structure invariants. It also built hermetic simulations, fuzzing harnesses, and algorithmic optimizations for ancestry queries.

The New Engineering Job Description: Architectural Gatekeeper​

Does this mean human systems engineers are obsolete? Not quite—Even Anthropic’s own account paints a more nuanced picture of where autonomous coding models go off the rails.

While the seven engineers on the Scion team stated they now rate Claude as better at writing raw code than they are, they noted that their primary day-to-day role shifted to high-level architecture and repeatedly telling the AI "no":

• Violating System Constraints for Convenience: During the migration, multiple AI agents attempting to find out when a change merged to main wrote code that brute-forced a linear scan of the entire commit log rather than querying the Antique code review API. Left unchecked, an agent will happily DDoS your backend infrastructure just to make its local unit test pass.
• Paranoid Over-Engineering: Anthropic uses adversarial AI code reviews to catch bugs, but engineers found these reviews could become deeply myopic. In one instance, an adversarial review grew overly suspicious about trusting an internal service, prompting Claude to layer on massive, unnecessary validation logic and structural complexity until human engineers intervened.
• Reviewing Intent Over Syntax: Anthropic’s engineers still review every change request, but they no longer read every line of generated syntax; instead, they audit architectural intent, system boundaries, and security constraints.
• Abandoning the Global Merge Queue: At 30,000 merges a day, traditional pre-merge CI queues with global repository locks break down because hundreds of changes land while a single test suite is still running. Anthropic shifted toward post-merge and pre-deploy automated testing, relying on Claude to resolve conflicting concurrent merges faster than human developers could triage them—and deploying single-purpose monitoring agents (dubbed "superfans") into Slack channels to watch component telemetry.

Summary: The Human-in-the-Loop Reality​

• Raw Optimization vs. System Sanity: Models like Claude Mythos Preview excelled at localized algorithmic optimization (20x less memory on ingestion) and hermetic test generation.
• Architectural Guardrails: Human engineers remained essential to stop agents from introducing brute-force anti-patterns or defensive bloat triggered by overzealous AI code reviews.

What This Means for Microsoft, GitHub, and Enterprise IT​

Before you start planning a migration away from Git, take a breath: Scion is not open source, it is not a commercial product, and Anthropic explicitly warns that it is unsuitable for general use.

Anthropic openly acknowledges that its willingness to burn astronomical stacks of compute tokens on internal tooling is something almost no normal enterprise could justify economically, and adopting Scion would require ripping out your entire stack of Git-based CI, code search, and review pipelines.

So why does this matter to Windows developers, GitHub Enterprise administrators, and Azure DevOps architects?

Because the pressure wave is already hitting public developer platforms. As The Register pointed out, Microsoft’s GitHub published an engineering update back in April 2026 attributing availability hiccups in part to the exponential surge in pull requests, commits, and automated workflows driven by AI coding assistants. When every developer has GitHub Copilot, Claude Code, or autonomous background agents spinning up sandboxed branches, running cloud builds, and opening PRs, human-scale Git servers start to buckle.

Rather than replacing Git, Anthropic suggests the industry—including partners like GitHub, GitLab, and the open-source Git community—can adapt several of Scion’s architectural patterns directly into the existing ecosystem over the next six to twelve months:

1. Standardized Server-Side RPCs: Git hosting platforms can expose rich, standardized server-side APIs for blame, ancestry, and diff queries so CI runners and AI agents don't have to clone gigabytes of .git history just to ask a metadata question.
2. Smarter Fetch Protocols and Tiered Caching: Instead of stateful packfile negotiation for every disposable CI container, Git servers and clients can lean further into content-addressed, resumable object fetching and better composition of sparse-checkout and shallow-clone primitives.
3. Directory-Level IAM and Semantic Review Gates: As organizations consolidate code so AI agents have full-context visibility, monorepo security becomes critical. Anthropic built directory-level access controls into Scion and semantic approval rules into Antique (distinguishing a harmless comment tweak from a core logic change)—capabilities that enterprise Git platforms will increasingly need as synthetic code volume scales.

For decades, our developer tools were built around the ergonomics of a human typing into a text editor on a local hard drive. As AI agents transition from autocomplete helpers to autonomous commit generators, the plumbing underneath our repositories is overdue for an upgrade. Git isn't going anywhere, but the way our servers speak it is about to change.