Claude writes code so fast that Git can't keep up: Anthropic rebuilt a version control system with only 7 people in 5 months

In May this year, Anthropic merged about 2,500 code modifications on average every day. By September, this number had exceeded 30,000. In just four months, the volume of code merges has increased by more than 12 times

Number of daily code changes merged in Anthropic's single code repository (Monorepo) from January to September 2026

This growth largely comes from Claude. The AI Coding Agent can independently modify code, execute tests, optimize programs iteratively, and even build services from scratch. As the code production speed rises, the software development infrastructure originally serving human engineers is gradually failing to keep up.

The first to hit a serious bottleneck was Git. The main branch history of Anthropic's Monorepo (single code repository) is close to 100GB, and the compressed working copy exceeds 25GB. The continuous integration (CI) system alone needs to perform about 25 million code checkouts every day. If a naive Git data acquisition method is adopted, more than 600PB of data transmission demand may be generated every day.

Anthropic has previously used a variety of optimization methods such as Git shallow clone, sparse checkout, internal mirroring, and object storage snapshots. At its peak, it even maintained hundreds of Git mirror servers, but as the volume of code merges continues to grow, this set of solutions is becoming increasingly difficult to sustain.

Therefore, Anthropic made a rather radical decision: to redevelop a version control system.

On October 13, Anthropic disclosed this project on its official engineering blog. A team of only 7 engineers developed a new version control system named Scion within five months, and completed the migration of the entire Monorepo. At the same time, they also developed the code review tool Antique, code search system, permission management and other supporting infrastructures.

After the migration, the CPU and memory footprint of Scion's infrastructure dropped to about 1/200 of the original Git mirror solution, the code checkout speed for CI and research tasks increased by about two orders of magnitude, and CI alone saved about 25% of CPU capacity.

More interestingly, Claude is not only an important cause of this infrastructure pressure, but also an important tool to help Anthropic complete the system transformation.

1

30,000 code merges per day, where exactly can't Git hold up?

The reason why Git has become the standard tool in the software development industry is largely due to its distributed design. Developers can save repository history locally, create commits, compare differences, and complete most operations even without a network connection.

For the vast majority of software projects, this is a very successful design. But it also means that the client needs to have fairly complete version control capabilities and save the repository data required to perform related operations.

The workload Anthropic faces has changed significantly.

First of all, the code repository itself is getting larger and larger. The main branch history close to 100GB and the compressed working copy exceeding 25GB make frequent creation of development environments, CI environments and Agent sandboxes expensive. Secondly, the code checkout frequency is extremely high. The about 25 million checkouts per day do not even calculate the additional demand generated by developer environments, Agent sandboxes and research tasks.

More critically, the speed of code changes far exceeds that of traditional development teams. Anthropic stated in its official article that every time a development bottleneck is eliminated, the code output will further increase. The development infrastructure needs to continuously cope with this growth.

In order to keep Git running, Anthropic once deployed hundreds of internal mirror servers and saved repository snapshots in object storage. These solutions can reduce repeated downloads, but they also introduce new maintenance burdens. Mirrors need to be synchronized continuously, snapshots quickly fall behind the main branch, and it is becoming increasingly complex to keep operations that rely on historical information such as diff and blame working properly in a partial clone environment.

Anthropic thus re-examined a long-standing design assumption: since most code operations are completed by always-online Agents and automated tasks, why does each client still need to have the ability to independently process the full repository history like a traditional Git client?

This became the starting point for Scion's design.

Of course, the conflict between ultra-large-scale Monorepo and Git is not new. Google developed its internal centralized version control system Piper very early, and Meta has also invested years in building Sapling. The problems Anthropic encountered this time are similar to those of these large technology companies, but the driving forces are different: in the past, it was mainly the huge engineer organization and code repository scale, and now a large number of parallel working Coding Agents are also generating similar pressure.

2

How is Scion designed? Move most of the version control work to the server

The most important design change of Scion is to shift version control from the local repository-centric working mode to an always-on client-server architecture.

In Git, the client can independently create commits, perform rebases, query history, and then push modifications to the remote end. Scion places major operations such as commit, merge, rebase, and history query on the server side. The client is mainly responsible for maintaining a limited local cache, managing the working directory, and monitoring file changes.

Since commits are created directly on the server side, Scion no longer needs the push step in the traditional Git workflow. The client also does not need to download a large amount of repository data that is irrelevant to the current task.

This change also allows version control capabilities to be directly provided to other systems through APIs. For example, if a CI task only needs to calculate the difference between a certain commit and the merge base, it can directly request the server to return the result without checking out the entire code repository first. Tools such as automated rollback and locating problematic commits can also query version history through APIs.

From the perspective of engineering architecture, Scion tries to make the cost of version control operations depend more on the amount of data actually modified, rather than the size of the entire repository.

To achieve this, Scion redesigned the underlying data structure.

In Git, a commit references the corresponding directory tree. Scion adopts a change record named Changeset, which is written to the Write-Ahead Log. Each Changeset records the files that have changed relative to the first parent commit, as well as the content-addressable reference pointing to the compressed file content.

Data structure of Changeset in Scion

File content is stored in Blob Storage, and version relationships and related metadata are managed by the backend system. Scion uses Spanner to store part of the metadata that needs to be coordinated, and minimizes cross-server synchronization when creating commits as much as possible.

This design enables commits to be created and distributed quickly, and also avoids part of the packaging, negotiation and maintenance overhead brought by the Git Packfile mechanism.

Scion still supports references (ref) similar to Git branches and tags, but minimizes dependence on them. Anthropic believes that if a large number of operations need to update the global shared state, coordination bottlenecks will easily be reintroduced. Therefore, regular commit creation in Scion does not depend on moving refs, and only scenarios such as the main branch or release branch need to update these references.

However, moving operations to the server does not mean that the problem is naturally solved. The server needs to bear requests from a large number of Agents and CI tasks at the same time. If all clients directly access the central storage, the system may still be overwhelmed by traffic.

Anthropic therefore designed a layered cache architecture.

Scion's code checkout architecture

On the compute node, scion-daemon is responsible for sharing the file object cache for multiple tasks on the same node. The scion-cache server in the region provides the second layer of cache, and then connects to the authoritative scion-server upwards. Only when there is a cache miss, it is necessary to continue to access Spanner or cloud storage.

The client requests specific immutable objects. Since objects are content-addressed, the cache does not need to repeatedly confirm whether the objects have changed, and each layer of services can also be scaled out independently.

Anthropic disclosed that the cache hit rate of each layer of this architecture exceeds 99%. It also isolates faults through a clear cache hierarchy to avoid a large number of requests from directly pouring into upstream services when a regional cache fails.

Scion also takes sparse checkout and virtualized checkout as basic capabilities. The client only obtains the directories and files it needs, and some files are not loaded until they are actually accessed. For tasks that only require version metadata, even the creation of the working directory can be skipped entirely.

Eventually, Anthropic reported that Scion's infrastructure CPU and memory footprint is reduced by about 200 times compared to the original Git mirror solution, code checkout is shortened from the minute level to the second level, and CI gains about 25% CPU capacity savings.

It should be noted that these indicators correspond to different optimization dimensions. The 200x refers to the difference in infrastructure resource occupancy, the two orders of magnitude refers to the code checkout speed, and 25% is the CI capacity benefit. It cannot be simply understood that Scion is 200 times faster than Git in all operations.

3

Seven people, five months, Claude also increased the speed of rewriting the infrastructure

If the architectural design of Scion reflects the system changes brought about by the scaling of Agents, then its development process shows another impact of Coding Agents on the way software engineering organizations operate.

Anthropic disclosed that Scion and the supporting code review tool Antique were developed by a 7-person team. The team completed the system construction and the migration of the entire Monorepo within five months, and also delivered multiple related systems such as code search and permission management.

In this process, Claude undertook a lot of code implementation and optimization work.

The official article introduced a specific case: the early Git data import pipeline of Scion was mainly handwritten by engineers, and the team originally thought the performance was already good. Later, they asked the early internal version of Claude Mythos Preview to reimplement the entire pipeline.

Without further instructions, the new version generated by Claude reduced memory consumption by 20 times, increased execution speed by 4 times, while retaining the original data import order and data structure constraints.

The significance of this case is that Agents have been able to participate in performance optimization of complex infrastructures, rather than just completing the writing of local functions, interfaces or business code.

But Anthropic also emphasized that this does not mean that the role of engineers has disappeared.

Team members believe that Claude has surpassed themselves in code writing, but system-level design decisions still rely on engineers, including understanding the relationship between different components, judging architectural trade-offs, and deciding which problems are worth solving.

There is a very interesting detail in the official article: one of the important tasks of engineers is to tell Claude "don't do this".

This is related to the actual characteristics of the Scion project. There are a large number of trade-offs between high throughput, low latency, horizontal scaling, fault isolation and data consistency. Even if an implementation has good code quality, it may not meet the long-term operation requirements of the system. Engineers need to decide which solutions are acceptable based on the overall architecture and production environment constraints.

Claude is also used for daily system operation and maintenance. The Anthropic team created a group of Claude Agents called "superfans", each focusing on different components of Scion. For example, one Agent continuously monitors scion-daemon, another focuses on scion-cache, and a dedicated Agent observes the Antique merge queue.

Number of weekly merged code changes in the Scion and Antique codebases from January to September 2026

These Agents can read telemetry data and logs, continuously check system status, and look for anomalies that are not easily detected by traditional monitoring rules. Anthropic did not cancel regular alerts as a result, but used Agents as an additional analysis layer.

From code implementation, performance optimization to operation monitoring, Claude has been deeply involved in the entire engineering lifecycle of Scion.

4

When Agents keep writing code, even CI and code merge rules have to be redesigned

Scion solves the scaling problem of the version control system, but Anthropic found that many links in the existing software development process are built on the work rhythm of human engineers. A typical example is the Merge Queue.

The traditional merge queue coordinates the order in which code enters the main branch to ensure compatibility between commits as much as possible, and executes tests before merging. This mechanism can reduce the risks brought by concurrent modifications, but it also introduces waiting and coordination costs.

When the number of code merges reaches tens of thousands per day, the problem becomes complicated.

While a test is still running, hundreds or even thousands of modifications may have been merged into the main branch. There may have been significant differences between the code state corresponding to the test result and the current main branch. If all modifications are strictly forced to pass through the unified merge queue serially, the throughput will be limited.

Anthropic stated that the team has not yet found an effective way to replicate the industry-common global repository lock-style merge queue at this scale. Therefore, they have invested more resources in post-merge testing and pre-deployment automated testing.

This means that conflicts between some concurrent modifications may only be discovered after merging. Anthropic believes that Claude can usually fix these conflicts faster than human engineers.

However, this approach also raises new engineering problems.

When merged code may contain undiscovered conflicts, how can the team ensure the availability of the main branch? How should the division of labor between post-merge testing and pre-deployment testing be arranged? If multiple Agents continuously modify the same batch of files, how to control the scope of fault propagation?

Anthropic's article does not fully disclose the solutions to these problems, nor does it give data on defect rate, rollback rate or production incidents under the new process. Therefore, it can be confirmed at present that Anthropic has adjusted the code integration and verification mechanism, but it is still uncertain whether this model is comprehensively better than the traditional process in terms of quality and reliability.

Nevertheless, this is still a noteworthy change. In the past, software engineering infrastructure was mainly built around the process of developers submitting code, executing tests, waiting for review and merging. As Agents take on more and more actual development work, code generation and submission may become continuous background activities, and version control, CI, code review and release systems all need to adapt to the new throughput and concurrency patterns.

5

Will Git be replaced? Anthropic itself doesn't think so

Seeing Anthropic rebuild the version control system, many people may easily draw a conclusion: in the era of Coding Agents, Git may be eliminated.

But Anthropic did not come to such a conclusion.

In fact, large technology companies have long had precedents for developing dedicated version control systems for ultra-large-scale Monorepo.

Google uses its internal centralized version control system Piper, while Meta has been building Sapling for a long time. When Meta publicly introduced Sapling in 2022, it pointed out that traditional open source version control systems cannot meet the needs of its super-large repositories with tens of millions of files and commits. Sapling solves the scaling problem through mechanisms such as dedicated servers, virtual file systems, and on-demand acquisition of historical data, while retaining the ability to interact with Git repositories.