Anthropic Builds Scion as AI Coding Pushes Git to Its Limits

Anthropic Builds Scion as AI Coding Pushes Git to Its Limits

As AI coding agents become capable of generating, testing, and modifying software at unprecedented speed, a new bottleneck is emerging in software engineering: the infrastructure responsible for managing the code itself.

Anthropic has responded by building Scion, an internal version control system designed for AI-driven software development, and migrating its entire monorepo away from Git in just five months.

The scale of the challenge is striking. According to Anthropic’s engineering team, the company merged approximately 2,500 code changes per day in May 2026. By September, that figure had exceeded 30,000 per day—a more than tenfold increase in four months. At that rate, an accepted change entered the company’s codebase approximately every three seconds.

The problem was no longer simply how quickly Claude could write code. Git repositories, checkout operations, internal mirrors, code review, and continuous integration (CI) were increasingly struggling to keep pace with the resulting workload.

Anthropic addressed the problem with a seven-engineer team working alongside Claude. In five months, they built Scion, a replacement code review interface called Antique, code search, access-control infrastructure, and associated tooling, while migrating their primary repository to the new system.

The company describes the project in its official engineering article, Redesigning source control at Anthropic.

Importantly, Anthropic is not announcing the industry-wide deprecation of Git. The company explicitly says Scion is not a general-purpose replacement for Git. Instead, it is a specialized response to an unusually large monorepo and a development environment in which AI agents continuously generate and modify code.

The broader lesson is that as AI accelerates software production, the infrastructure around coding may need to evolve just as dramatically as the coding process itself.

📈 Why AI Coding Turned Source Control Into a Bottleneck

#

Anthropic’s experience illustrates what happens when software production accelerates faster than the systems designed to support it.

From 2,500 to more than 30,000 merged changes per day

#

Anthropic reported the following growth in its monorepo workload:

The interval figures are approximate averages calculated from the reported daily totals across 24 hours. They do not imply that changes arrive at uniform intervals.

The increase reflects a change in how software is developed. AI agents can work continuously, investigate unfamiliar code, implement modifications, run tests, and propose additional changes without following the working hours or typing speed of human developers.

As more of these tasks run in parallel, the number of changes requiring storage, validation, review, and integration increases rapidly.

The consequences extend beyond writing code. Each task may require a repository checkout, historical queries, dependency resolution, test execution, and access to build infrastructure.

When those operations become expensive, engineers and agents spend more time waiting for the development environment rather than making progress.

Git’s repository model becomes expensive at monorepo scale

#

Git was created by Linus Torvalds in 2005 to support distributed software development, particularly the development of the Linux kernel.

Its fundamental design allows each clone to maintain repository history locally. Developers can inspect commits, compare revisions, create branches, and work offline without constantly contacting a central server.

For most projects, these properties remain major advantages. Git’s decentralized architecture is a key reason it became the dominant version control system.

Anthropic, however, operates a repository with unusual scale and workload characteristics.

According to its engineering article, the history of the main branch alone approaches 100 GB, while a compressed working copy exceeds 25 GB.

The company performs approximately 25 million code checkouts per day for CI, even before accounting for developer environments, AI agent sandboxes, and research jobs.

If those operations naively fetched the full repository data, Anthropic estimates that they could generate more than 600 PB of traffic per day.

That figure is a projected worst-case workload without optimizations, not Anthropic’s actual daily network traffic.

The scale nevertheless demonstrates why repeatedly preparing local repositories can become expensive when millions of automated jobs need access to a rapidly changing codebase.

Why Git optimizations were no longer sufficient

#

Anthropic did not simply ignore existing Git capabilities.

The company had used shallow clones, sparse checkouts, partial clones with promisor remotes, internal mirrors, and repository snapshots stored in object storage.

At peak scale, it operated several hundred internal Git mirrors to distribute repository traffic.

These techniques helped reduce the load on the primary repository, but they introduced additional operational complexity. As the merge rate increased, maintaining up-to-date snapshots became harder, and operations involving repository history could become more difficult with partially materialized clones.

The company also had to ensure that mirrors stayed sufficiently synchronized with the latest changes while thousands of automated processes continued requesting repository data.

The underlying mismatch remained: Git was designed to give distributed clients substantial independence, while most of Anthropic’s automated consumers were online agents and jobs operating against one authoritative codebase.

This did not make Git obsolete. It meant Anthropic’s particular workload had reached a point where a different architecture was worth the cost of migration.

🧠 Scion: A Version Control System Designed for Always-Online Agents

#

Scion rethinks several assumptions that underpin traditional version control systems.

Rather than treating every client as a complete repository capable of independently managing history, Scion places more responsibility on centralized, horizontally scalable services.

Clients retrieve data when needed, while repository operations such as committing, merging, rebasing, and historical queries are exposed through server-side interfaces.

Server-side operations replace the need for complete local history

#

In a conventional Git workflow, a developer commonly creates a local commit and pushes it to a remote repository. The local clone contains the objects needed to inspect history and perform many operations independently.

Scion uses a different model.

A client can request changesets, calculate diffs, identify merge bases, inspect file history, and retrieve file contents through APIs. The server performs operations that would otherwise require the client to maintain a substantial local repository.

This enables automated jobs to query repository metadata without first downloading and maintaining all the data needed for a conventional checkout.

For example, a CI job that only needs to determine the difference between two revisions can request that information directly instead of initializing a full working copy.

The same principle applies to automated bisect and revert workflows: when repository operations are available programmatically, infrastructure can perform them without running a conventional Git command against a complete local clone.

The design is particularly suited to agents that operate continuously and have reliable access to centralized infrastructure.

Changesets make commits incremental

#

Scion’s core unit of work is a changeset, which records the files changed relative to its first parent and contains content-addressed references to the corresponding compressed file contents.

This differs from Git’s commit representation, which references a tree representing the repository state.

Scion creates changesets on the server and makes them available through its service architecture.

The design avoids several costs associated with preparing and transferring large Git object packs. Instead of requiring a large repository-wide packaging operation, the system can store and retrieve individual content-addressed objects.

The cost of creating a changeset and updating associated data structures is designed to scale primarily with the change itself, rather than the total size of the repository.

This is important for an environment where small changes arrive continuously. If committing a handful of modified files requires work proportional to an enormous repository, the version control system can become a bottleneck regardless of how quickly the code was generated.

Scion also minimizes dependence on globally coordinated references, such as branches and tags, which can introduce shared mutable state. Where references are needed, updates can be handled separately from the creation of changesets.

Content-addressed storage enables scalable caching

#

Scion distributes repository data across multiple services, using content-addressed objects that remain immutable once written.

Because an object does not change after creation, caches can store it and serve requests without repeatedly checking whether its contents have changed.

This architecture reduces coordination between servers and makes it easier to scale storage and retrieval independently.

The system also maintains derived data structures for operations that need additional indexes, including file history, blame information, path searches, and commit ancestry.

These structures can be computed eagerly or on demand, depending on the operation and its performance requirements.

The result is a source control architecture in which repository metadata and file contents are served through APIs rather than requiring every consumer to maintain a complete local representation.

⚡ Virtualized Checkouts Eliminate Unnecessary Repository Transfers

#

One of Scion’s most important optimizations is its approach to working copies.

Traditional source control workflows often materialize a working directory before a build or test begins. Even with sparse-checkout techniques, automated jobs can spend significant time preparing the files required for execution.

Scion introduces a model that supports sparse and virtualized checkouts by design.

Fetch files only when they are needed

#

With a sparse checkout, a client requests only selected directories or portions of the repository.

With a virtualized checkout, files can be materialized on demand, when an application or process attempts to read them.

For example, if a test job requires only one component of a large monorepo, it does not necessarily need to download every file in the repository before the test can start.

The client requests the relevant trees and blobs. Missing objects are retrieved through the cache hierarchy, while objects already present locally can be reused.

This reduces unnecessary transfers and makes the process more efficient when thousands of jobs use overlapping portions of the same codebase.

The architecture also avoids relying on one large, compressed repository response. Individual object requests are resumable and can be served by different cache tiers.

Shared node caches reduce duplicated work

#

Scion uses a local daemon called scion-daemon to maintain a bounded object cache shared by jobs running on the same machine.

A node generally needs access to the same monorepo as other jobs on that node, so retaining reusable objects prevents each job from fetching identical data independently.

The daemon starts from a periodically refreshed snapshot and communicates with regional cache servers, called scion-cache.

When a regional cache misses an object, it can request the data from authoritative Scion servers, which retrieve it from the underlying database or cloud storage as needed.

The client does not need to understand the internal topology of the cache hierarchy. The daemon, regional cache, and authoritative server use compatible interfaces, allowing the system to route requests through multiple layers without changing the client protocol.

The tiers are deliberately separated to contain failures. For example, an overloaded regional cache should not automatically overwhelm authoritative servers and take down the entire source control service.

Cache hit rates exceed 99%

#

Anthropic reports cache hit rates above 99% at each tier of the Scion infrastructure.

High cache hit rates matter because repository workloads frequently request overlapping content. If most requests can be served from a nearby cache, the system reduces repeated storage access and the amount of work performed by authoritative servers.

Combined with demand-driven file retrieval, this allows CI and research jobs to access code without repeatedly rebuilding large local repositories.

The broader design principle is that automated jobs should pay the cost of obtaining the data they actually need, rather than paying repeatedly to reconstruct a complete repository state.

📊 Scion’s Reported Performance Improvements

#

Anthropic reports substantial improvements in resource usage and checkout performance after migrating its monorepo.

The reported 200× figure describes the infrastructure footprint in terms of CPU and memory compared with the previous Git-mirroring system. It should not be interpreted as a 200× reduction in all infrastructure costs or total power consumption.

Similarly, the checkout improvement applies to the measured CI and research workloads, not necessarily every repository operation or interactive developer workflow.

The 25% CI CPU capacity gain is particularly relevant. Faster checkouts can reduce the time that build machines spend preparing source files, freeing compute capacity for compilation and testing.

For a company running millions of automated jobs, small improvements to each job can translate into substantial aggregate savings.

Why the gains compound at AI scale

#

Suppose an engineering organization launches thousands of agent tasks simultaneously. Each may need to inspect source files, create changes, run tests, and compare results against the current codebase.

If repository preparation consumes even a small fraction of each task’s total runtime, that overhead can multiply across the entire fleet.

Reducing checkout time from minutes to seconds improves more than individual developer responsiveness. It can also increase the fraction of available compute dedicated to actual work.

This is part of a broader shift in AI infrastructure engineering: the most important optimization may not be making the model itself faster, but removing the overhead surrounding the model’s execution.

KAD explores a related transition in its analysis of AI agent runtimes and the infrastructure surrounding autonomous coding.

🛠️ Seven Engineers Built Scion in Five Months With Claude

#

Perhaps the most striking part of the story is how quickly Anthropic developed and deployed the system.

The project involved seven engineers and took approximately five months. During that period, the team built Scion, its code review interface Antique, code search, an access-control system, and additional infrastructure for managing and integrating large numbers of changes.

The migration also took place while the volume of merged changes grew more than tenfold.

Claude helped rewrite a critical ingestion pipeline

#

Anthropic says it began with a largely handwritten prototype for ingesting Git data into Scion.

After gaining access to an early internal snapshot of Claude Mythos Preview, the team asked the model to rewrite the ingestion pipeline.

According to the engineering post, the rewritten version used approximately 20 times less memory and ran four times faster while preserving important invariants governing ingestion order and data structures.

This is a particularly meaningful example of AI-assisted engineering because it involved improving an existing implementation with complex correctness requirements, rather than simply generating a new function.

The work also highlights the value of providing an agent with a concrete objective and a testable reference implementation. The existing pipeline supplied a behavioral baseline against which the rewritten version could be evaluated.

Engineers shifted from writing every line to making architectural decisions

#

Anthropic says the engineers involved in Scion increasingly regarded Claude as better at writing code than they were.

However, the company does not claim that human engineers became unnecessary. Instead, their responsibilities shifted toward system architecture, design decisions, correctness constraints, and evaluating whether the model’s proposed solutions were appropriate.

The team frequently had to tell Claude “no.”

For example, automated code reviews sometimes encouraged the model to add elaborate safeguards against hypothetical risks, producing unnecessary validation logic and additional complexity.

In other cases, the model proposed inefficient ways of answering questions that could already be resolved through existing internal services.

Human engineers had to recognize when an implementation violated an architectural principle or solved a problem at the wrong layer.

This is an important limitation of autonomous coding agents: the ability to produce plausible code quickly does not guarantee that the code is necessary, maintainable, or consistent with the overall system design.

Code review became more focused on intent

#

Anthropic still has engineers review every change request in Scion. The difference is that reviewers can focus more heavily on what the change is intended to accomplish and whether the implementation respects system-level constraints.

The company also invested in hermetic simulations, fuzz testing, rate limiting, and automated checks, building a more extensive testing foundation than the short project timeline might otherwise suggest.

The model’s speed made this work more feasible, but it also increased the importance of ensuring that rapid changes did not undermine reliability.

The experience illustrates a potential direction for software engineering teams: humans concentrate on architecture, priorities, and correctness, while AI agents perform more of the implementation and repetitive investigation.

For further context on the challenges of maintaining AI-generated code, see KAD’s analysis of machineslop and the growing software quality problem.

🔐 Scion Also Reworks Code Review, Search, and Permissions

#

Anthropic did not treat version control as an isolated component. The migration also included surrounding systems that consume repository history and govern how changes are reviewed and accepted.

Antique: A code review interface for high-volume changes

#

The team built Antique, an internal code review surface designed to operate alongside Scion.

At agent scale, code review becomes more than a presentation layer for line-by-line diffs. It must help reviewers identify the intent, scope, risk, and consequences of each change while handling a much higher volume of proposed modifications.

Anthropic also developed methods for managing and landing large numbers of reviewed changes.

This does not eliminate the need for human oversight. Instead, it changes how review systems must organize work when the number of candidate changes grows faster than the number of human reviewers.

Repository search and access control

#

The migration included code search and a more comprehensive source control identity and access management system.

Scion supports fine-grained permissions, including access controls for individual directories within a monorepo.

This is important because large repositories often contain code with different sensitivity levels. Companies may want to preserve the productivity benefits of a shared codebase without granting every developer or agent unrestricted access to every directory.

The code review system can also enforce different approval requirements for changes with different semantic impact. A comment-only edit may require less scrutiny than a change that modifies sensitive program logic.

These capabilities help separate high-volume routine development from changes that require stricter human review.

The lesson is that an AI-scale source control system needs to address the complete development lifecycle, not merely optimize the commit operation.

⚖️ Why Scion Is Not a General Replacement for Git

#

Despite the scale of the migration, Anthropic explicitly states that Scion is not suitable as a general-purpose Git replacement.

The distinction is important because Git’s decentralized architecture remains valuable for many developers and organizations.

Git remains effective for conventional development

#

Git allows developers to work offline, maintain independent clones, create local branches, inspect history, and collaborate across distributed environments.

Those characteristics are beneficial for open-source projects, small teams, distributed development, and organizations without the infrastructure required to operate a centralized source control service.

Scion makes a different set of trade-offs. Its clients are designed around the assumption that the server is available, and many source control operations are performed remotely.

This is attractive when automated jobs continuously access a large authoritative repository, but it is not an automatic improvement for a developer who values offline work or needs a self-contained repository.

Migration requires replacing the surrounding toolchain

#

Adopting Scion would require much more than changing a version control command.

An organization would need to integrate or replace its code review, code search, access-control systems, build pipelines, and CI workflows. Developers and automated tools would also need to adapt to different assumptions about commits, working copies, and server availability.

These costs can outweigh the benefits for repositories that do not experience Anthropic’s scale of automated activity.

Anthropic also acknowledges that its internal willingness to spend substantial amounts of model tokens on software development is unusual. Most companies do not operate AI coding agents at the same scale or with the same cost structure.

The company’s objective was to address its own infrastructure constraints and explore what increasingly capable AI models make possible, not to establish a universal successor to Git.

🔮 What Scion Signals About the Future of Software Engineering

#

Scion is an example of a broader architectural transition: the tools surrounding software development may need to change as the rate of code production increases.

Traditional development infrastructure assumes that human engineers create a limited number of changes, review them, run tests, and integrate them through coordinated workflows.

AI-driven development introduces a different workload. Hundreds or thousands of agents may work concurrently, generate competing changes, run tests, and attempt to merge results.

Continuous integration may need a new operating model

#

A conventional merge queue tries to serialize changes and validate them against a known repository state before integration.

At extreme agent concurrency, globally coordinating every change can become a source of delay.

Anthropic says it has invested more heavily in post-merge and pre-deployment testing rather than attempting to reproduce the industry-standard global repository lock at its previous scale.

This approach allows changes to proceed concurrently but increases the importance of detecting regressions after integration and resolving conflicts quickly.

Such a model is not appropriate for every system. Safety-critical software, regulated systems, and applications with strict deployment guarantees may require more restrictive controls.

Nevertheless, it illustrates how AI-generated code volume can force engineering organizations to reassess workflows that were designed around a much lower rate of change.

Infrastructure becomes part of the AI productivity equation

#

When developers discuss coding agents, attention often focuses on model quality, context windows, and benchmark results.

Anthropic’s experience shows that these improvements can expose limitations elsewhere in the development stack.

Source control, build systems, test infrastructure, code review, repository search, and monitoring all affect how much useful work an agent can complete.

As a result, improving the model may produce diminishing returns if the surrounding infrastructure cannot absorb the resulting output.

Scion represents one attempt to address that problem by redesigning source control around the assumption that clients are always online, changes arrive continuously, and large portions of the workflow can be performed through APIs.

Other organizations will need to determine whether similar approaches make sense for their own repositories and workloads.

✅ Conclusion: AI Is Forcing Developer Infrastructure to Evolve

#

Anthropic’s migration from Git to Scion is not a declaration that Git is obsolete. It is evidence that an infrastructure design optimized for distributed human development can become inefficient when applied to an exceptionally large repository operated by a massive fleet of AI agents.

By building a server-oriented source control system with incremental changesets, content-addressed storage, virtualized checkouts, and scalable caches, Anthropic reports reducing its Git-mirroring infrastructure footprint by approximately 200 times in CPU and memory requirements. Checkout performance improved by up to two orders of magnitude in the tested CI and research workloads, while CI alone gained approximately 25% in CPU capacity.

The development process is equally revealing. Seven engineers worked with Claude to build Scion and its surrounding tools in five months, even as the company’s merged-change volume increased more than tenfold.

Human engineers remained essential, but their work increasingly centered on architecture, trade-offs, security, and deciding when generated code was too complicated or violated system constraints.

For the wider industry, the important question is not whether every company should replace Git. Most should not. It is whether software development infrastructure can keep pace when AI agents create code faster than conventional review, build, and integration systems can process it.

As AI coding becomes more autonomous and parallelized, the bottleneck may move from code generation to everything required to turn generated code into dependable software. Anthropic’s Scion project provides an early, concrete example of how that next phase of software engineering infrastructure may look.