Claude写代码太快，Anthropic 连源码系统都重造了！7人只用5个月
Claude writes code so fast that Anthropic had to rebuild its source code system! 7 people did it in just 5 months
Content Summary
Xinzhiyuan reports that more than 30,000 code merges happen in a single day, and Anthropic’s original development tools can’t keep up! On October 13, Anthropic disclosed in its official engineering blog: In May this year, the company averaged daily
Xinzhiyuan reports
Xinzhiyuan reports
</h3
More than 30,000 code merges in a single day overwhelmed Anthropic’s existing development tools!
On October 13, Anthropic disclosed in its official engineering blog:
This May, the company averaged about 2,500 code merges per day; by September, that number had exceeded 30,000, more than 12 times the original.
Anthropic’s daily code merge volume from January to September 2026. (Source: Anthropic)
To keep up with this explosive growth, a seven‑person team built a brand‑new version control system, Scion, in just five months and fully migrated the company’s monolithic codebase from Git to it.
Interestingly, this creates a rather magical closed loop:
Claude writes code so fast that it pushes existing tools to their limits; yet when the team rebuilds tools and solves problems, they still use Claude.
The problems caused by Claude have to be solved by Claude.
What does “30,000 merges per day” actually mean?
You can think of software as a book that many people edit together—some edit the first chapter, some add the final chapter, and others are responsible for standardizing the terminology throughout the book.
After each finishes their own tasks, the work isn’t done yet.
These changes still need to be aggregated and checked for conflicts; once issues are found, you also need to know who changed what and how to revert to a previous version.
A version control system handles storing change history and coordinating modifications. Whether the updated software runs correctly still depends on building and testing.
As AI continuously submits changes, the downstream steps must speed up as well. Otherwise, the faster code is generated, the more backlog of tasks accumulates.
This is precisely the pressure Anthropic is facing.
This is not Anthropic’s first time rebuilding tools for code scaling.
On September 14, the company disclosed in another official article:
The volume of continuous integration (CI) tasks grew to 25 times the original amount within six months.
Continuous integration can be understood as the automated build and verification process after code changes.
As tasks increased, the service responsible for determining “which tests should run for this change” began to fall behind the pace.
The team first increased processing capacity, then split the tasks across multiple worker processes, and later even tried restarting the service daily.
The three temporary fixes lasted for:
70 days, 29 days, and less than a day.
Obviously, the time bought by patching keeps getting shorter.
In the end, an engineer spent three weeks refactoring the service.
The new architecture has higher operating costs, but it is easier to scale and remains stable after tuning.
After testing the selected service refactoring and tuning, the backlog of pending events has stabilized. (Image source: Anthropic)
The post‑mortem also notes that Claude tends to submit smaller, more granular changes and works during nights and weekends.
The changes were broken down more finely, extending the work duration, so the downstream testing system naturally has to handle more tasks.
Looking at the two retrospectives together, the speed of AI code generation has increased, and the pressure on subsequent stages such as review, testing, and merging has also risen.
Facing bottlenecks in source code management, Anthropic chose to build its own Scion.
One major change is shifting more operations to the server, with the client fetching data on demand.
In plain terms, retrieve only the parts of the material needed for a task; if a question can be answered directly by querying the server, there’s no need to first move a large amount of data locally just for a single answer.
Scion provides code data to tasks on demand through hierarchical caching. (Image source: Anthropic)
Move less data, do less duplicate work, and more tasks can progress simultaneously.
According to Anthropic, measured by CPU and memory requirements, Scion’s infrastructure scale is about 1/200 of the previous Git mirror infrastructure.
This comparison is limited to the infrastructure used for source code management and cannot be directly translated into the company’s overall development costs.
During the rebuilding process, Claude also gave the team an unexpected speed boost.
The team had previously hand‑written the first prototype of the Git‑to‑Scion data import pipeline.
Later, they had Claude rewrite an early internal version of the Mythos Preview. According to the official statement, the rewritten version runs four times faster and uses about one‑twentieth of the original memory.
The code growth driven by AI demands tool upgrades, and AI’s programming capabilities help the team accelerate those upgrades.
This also explains why Anthropic’s seven-person team was able to complete this system build and migration within five months.
Of course, large companies building their own tools for massive codebases have long precedents.
When Meta introduced Sapling in 2022, it explained how it handles codebase growth and released a Git-compatible client.
This approach has long-term engineering accumulation, and different projects have varying starting points and scopes, so efficiency cannot be judged solely by development timelines.
Anthropic also makes it clear that Scion is designed for extremely large codebases and is not intended as a general‑purpose Git replacement.
For most teams, the more important question to consider is:
As AI‑generated changes increase, where will your existing workflow start to bottleneck?
In this project post‑mortem, Anthropic especially emphasized one task for engineers:
Tell Claude “No”.
After receiving a task, AI can propose a solution and write the implementation.
But a locally feasible approach, when integrated into the whole system, may introduce new complexity or violate existing constraints.
Therefore, engineers need to assess: why was it designed this way originally? Which conditions must be upheld? Could the time saved today become a maintenance burden tomorrow?
These judgments are hard to make based solely on a few lines of code.
You may encounter similar issues when using AI to build a small tool.
The more features are added, the more complex the interface becomes; a single change solves the immediate problem but also affects previously working parts.
At this point, continuing to let AI add code may not improve the result.
Removing unnecessary requirements, clarifying the relationships between features, or even discarding a solution that has already been written are also part of development work.
For ordinary people, the difficulty lies here: noticing that a feature is not user‑friendly is easy, but identifying where the problem is, which part to modify, and whether the change will affect other features still requires knowledge and experience to judge.
In this seven-person team at Anthropic, engineers also need to understand the relationships between systems, make architectural trade‑offs, and review changes submitted by AI.
With over 30,000 merges per day, the question “what to do after code is generated” becomes unavoidable.
Evaluating whether AI‑generated programming is useful requires not only looking at how fast code is written, but also whether the resulting product works correctly, meets functional requirements, and can be fixed when issues arise.
If downstream processes keep pace, the time saved by AI‑written code won’t be wasted on waiting and rework.
Reference:
Edited by: Yuan Yu
Get MirrorSpeed