A software company merging 2,500 code changes a day already sounds busy. Anthropic was doing roughly that in May 2026. Four months later, its engineers were merging more than 30,000 changes a day. Same company, a very different problem. The code was arriving so quickly that the tools responsible for storing it, reviewing it, and getting it into production had started to become the slow part.
On October 13, Anthropic published an engineering account explaining what happened next. The company had built an internal source-control system called Scion and moved its large shared code repository away from Git in five months. A team of seven engineers also developed a review tool called Antique and several related services. Much of that work was done with help from Claude, the coding AI whose output had helped create the capacity problem in the first place. These are Anthropic’s reported figures and experiences, not results from an independent audit. The original engineering post was updated on October 15 to credit earlier source-control work that influenced Scion.
The headline almost writes itself: AI generated so much code that its own maker had to replace Git. But that headline can give the wrong impression. Git hasn’t suddenly stopped working for normal teams, and Anthropic has not announced that every repository it owns has moved to Scion. The company says its monorepo, a huge repository containing many projects, became a special case. What happened inside it may tell us more about the next problem in software engineering than another demonstration of an AI agent writing a complete app in ten minutes.
Access without medium partner: Anthropic Built Its Own Git
A Twelvefold Increase in Four Months
There is a number I keep coming back to: 30,000 merged changes per day. Divide that by 24 and you get 1,250 changes per hour if the activity were spread evenly across the day. It isn’t, of course. But even as a rough average, that is more than 20 changes every minute. In May, the reported figure was around 2,500 per day, or a little under two changes per minute. That’s a twelvefold jump in daily merged volume in about four months.
It would be easy to mistake that for twelve times more useful software. We don’t know that. A merged change could be tiny, large, valuable, routine, or later reverted. Anthropic hasn’t published a comparable figure for defects, customer-facing features, or engineering output per dollar across this period. Merge count measures traffic through a development process. It does not measure business value. Still, the traffic itself has to be handled. Every change has a history, a set of affected files, an approval path, and tests that may need to run.
At Anthropic’s scale, the surrounding numbers are unusual. The company says the history of its main branch alone was approaching 100GB, with a compressed working copy larger than 25GB. Its continuous-integration systems performed around 25 million code checkouts per day, excluding developer machines, AI sandboxes, and research jobs. If each job naively transferred the complete compressed working copy, the total would exceed 600 petabytes daily. That’s a hypothetical transfer figure, not Anthropic’s actual network usage, because it was already using caching and other shortcuts.
And the shortcuts were getting messy. Anthropic says it operated several hundred internal Git mirrors at its peak, alongside snapshots, sparse checkouts, and partial clones. Those tools bought time. But constantly updating so many copies while new commits kept arriving meant more maintenance, more disk and memory pressure, and awkward problems when jobs needed accurate history or blame information. A setup that had once helped engineers work faster was becoming its own project to keep alive.
This isn’t a complaint about Git being badly designed. Git was created around a sensible idea: each developer can hold a complete repository and keep working without an internet connection. Commits, branches, comparisons, and history are available locally. That makes Git useful on a laptop with bad Wi-Fi, in open-source work across time zones, and in practically every ordinary development team. Anthropic’s problem was that it had millions of short-lived online jobs treating a very large shared repository as if each job needed the capabilities of an independent developer laptop.
Scion Changes Where the Work Happens
Scion takes a different bet. Anthropic says its clients are almost always connected to a server, because the clients are often AI agents and automated jobs running in its own infrastructure. So the client doesn’t need to carry a full copy of the repository or perform every history operation itself. It can ask the source-control service for exactly the data it needs.
With Git, you normally commit locally and push your work. With Scion, the server creates commits and handles merges and rebases. The client keeps a limited cache, watches local files when a working copy exists, and fetches missing files on demand. Many automated tasks don’t need a working copy at all. A CI job asking which files changed can query an API instead of downloading a large repository just to calculate a diff.
There is a price for this design. The central service needs to be available, because the client can’t do much by itself. Git’s offline independence is a feature, and Scion gives up much of it on purpose. For Anthropic’s internal agents, this trade makes sense. For a developer on a train with unreliable connectivity, maybe not so much.
The storage design is different as well. Scion records changesets in a write-ahead log and stores pointers to changed file contents, rather than building each commit around the same tree structure Git uses. It calculates other information, such as file history and blame, through separate derived data structures. A set of scalable servers and caches answer requests, with persistent data stored in systems including Spanner and cloud object storage. Anthropic says there is no complete materialized copy of its huge repository anywhere, even on the server.
That last detail took me a moment to understand. We normally picture a source-control server as the place holding the complete repository. Here the repository is a logical view assembled from distributed content and metadata. If an agent wants five files, it should receive those five files. If another process wants the merge base between two changes, it asks for that answer. You no longer pay the full cost of a giant repository every time you ask a small question about it.
None of this appeared from nowhere. Anthropic’s October 15 update explicitly acknowledged earlier designs from Google’s Piper and Meta’s Sapling, especially the Mononoke server and Bonsai data model. Scion is an adaptation built for Anthropic’s workload. Calling it a completely new invention would miss years of work by other teams that ran into huge-repository problems long before today’s coding agents arrived.
The Performance Numbers Are Big, but They Need Labels
Anthropic reports that Scion’s source-control infrastructure now uses 200 times less CPU and memory than its previous Git mirroring setup. It also says CI and research jobs fetch working code roughly two orders of magnitude faster, moving from minutes to seconds. For CI specifically, Anthropic reported a 25% CPU capacity saving. Each cache tier reportedly records hit rates above 99%.
Those figures are striking, but they are comparisons against Anthropic’s old internal architecture, not a universal test showing Scion is 200 times faster than Git on every project. The old setup included hundreds of mirrors and all the overhead needed to keep that architecture operating. A five-person startup running a 2GB Git repository won’t see similar savings by copying Scion’s design. There probably isn’t enough waste in its system to remove.
Also, the benchmarks come from Anthropic itself. The company hasn’t released a generally usable Scion distribution or a public reproduction package for these exact measurements. Independent developers can study the design choices but cannot download the system, replay the same workload, and verify each number. That’s fine for an engineering experience report. It matters when people turn an internal comparison into a broad claim that Git has become obsolete.
One more figure needs some care. An engineer hearing ‘200 times smaller’ may think of storage size. Anthropic specifies CPU and memory requirements for its source-control infrastructure. It isn’t claiming that a Git repository containing 100GB of history has somehow become a 500MB repository. Different metric, very different conclusion.
What looks useful to me is the change in the shape of the work. A large fraction of short-lived jobs only needed to ask a question or read a narrow part of the tree. When those jobs no longer make an expensive local copy first, infrastructure savings follow. That is an idea Git-hosting platforms can borrow without asking the entire developer world to abandon Git.
Claude Helped Build the Tool That Claude Made Necessary
There is a slightly absurd part to the story. Anthropic says its coding models helped create so much development activity that source control became a bottleneck. Then Anthropic used those same models to write a replacement. The team built Scion, Antique, code search, permissions, and other related systems while the daily merge volume continued to rise. Seven engineers did the work over five months, according to the engineering report.
A particularly concrete example involves the tool that moved data from Git into Scion. Anthropic says engineers had handwritten an early version. They later gave an internal Claude Mythos Preview model the task of rewriting it. In the company’s reported test, the rewritten version used twenty times less memory and ran four times faster, while preserving the required ordering and data behavior. That is a project-specific example, not a published average for all code written with Claude.
It also wasn’t a case of pushing a button and walking away. Anthropic describes engineers making architecture choices, defining constraints, reviewing changes, and rejecting bad ideas. Sometimes an agent tried to solve a history question by scanning a long commit log instead of calling an existing service. Other times, a defensive review led Claude to add unnecessary validation and complexity. Those are real failures of judgment, even when the generated code compiles. The company’s engineers needed to recognize them before they spread.
This part deserves more attention than the headline number. Writing code is one activity. Deciding whether it belongs in the system is another. A model can produce an elaborate fix for a problem that shouldn’t be solved that way. Human reviewers still have to know when a ‘clever’ implementation has crossed an architectural boundary. Anthropic says its reviewers now spend more time evaluating the intention of a change than reading each line, but they still review every change request for this system.
That makes the seven-person achievement more interesting, not less. Claude reduced the amount of manual implementation work; the engineers still carried responsibility for the design. The work shifted toward specifying rules, evaluating risk, running tests, and saying no when an AI suggestion looked attractive but violated the system’s assumptions.
And then there’s the question of testing. Anthropic says the extra coding capacity allowed the team to build detailed simulations, fuzz tests, and rate-limiting protections in a short period. That’s one of the better potential uses of AI-assisted programming. If machines produce code faster, they should also help produce checks that catch failures. More code without more verification would just move the headache from the editor to production.
Traditional Code Review Starts Looking Strange at 30,000 Changes a Day
Git itself wasn’t the only part that needed adjustment. Anthropic built Antique, its own code-review interface, and changed how large numbers of reviewed changes reach the main branch. The old idea of a single global queue protecting the repository doesn’t fit neatly when hundreds or thousands of changes can land while a long-running test suite is still executing.
Anthropic says it has leaned more heavily on testing after merge and before deployment. That is a serious tradeoff. A strict merge queue can lower the chance that untested combinations reach the main branch, but it can also become a long bottleneck. Letting changes land sooner increases throughput, yet it shifts responsibility onto automated detection, rollback, and repair. Anthropic says Claude can often resolve conflicts quickly, but it doesn’t publish a complete breakdown of incidents or costs arising from this new strategy.
I wouldn’t suggest that an ordinary team copy this setup. Most teams have other bottlenecks first: unclear requirements, poor tests, slow reviews, and production incidents. Moving to post-merge testing before improving those basics could create a mess. Scion solves an unusually large traffic problem. It doesn’t make software correctness free.
The security implications are interesting too. Anthropic says Scion can enforce access at the directory level, and Antique can express different approval rules for different kinds of changes. That matters if thousands of agents are producing modifications across one large codebase. A change to documentation should not have the same approval expectations as a change to a sensitive internal service. Large-volume automation makes this kind of access control harder to treat as an afterthought.
It may also change what ‘code ownership’ means. When a model touches a subsystem at 2 a.m., responsibility still needs a human address. Who authorized the change? Which tests covered it? Can it be traced and reverted? An automated developer can’t be the final person accountable for a security incident. The source-control and review system needs to preserve enough context for someone to reconstruct what happened.
The Next Bottleneck Might Be Trust, Not Storage
Anthropic’s report gives us a useful view into the near future, but I wouldn’t assume every company will eventually merge 30,000 changes a day. Anthropic operates at an unusual scale and says its internal token spending is far beyond what most businesses would reasonably pay. Its needs are shaped by the fact that it also develops and evaluates the AI models doing the coding.
Still, the direction is worth watching. The cost of producing an initial code change is falling. The cost of understanding a system, deciding what should change, testing the result, and operating it safely has not fallen in exactly the same way. That creates a strange outcome: more code can mean more pressure on the parts of engineering that used to sit quietly in the background.
If you’re managing a small or medium-sized development team, I would track two numbers before worrying about replacing Git. First, how long does a change wait between being ready and getting safely deployed? Second, what percentage of changes require rework, rollback, or extra investigation? Those tell you whether AI coding is helping the full process or merely generating a queue of tasks for reviewers.
You can also steal the smaller ideas from Scion. Keep CI checkouts narrow. Avoid downloading an entire repository for a single metadata question. Make code search and change history available to agents through controlled APIs. Separate low-risk changes from changes that need careful approval. Measure your build and test infrastructure under real load before rewriting it. Most of these improvements don’t require a new version-control system.
Git hosting providers have room to evolve here. Anthropic itself suggests that smarter server-side APIs, better sparse operations, and new ways of serving repository data could address many of the same needs without dropping the Git model. A developer could keep familiar commits and branches while a server handles expensive queries for automated jobs. That’s a much more likely path for most teams than adopting an internal system that was designed for one company’s enormous monorepo.
And what if the next generation of agents makes 30,000 daily merges look ordinary? We don’t know. More generated changes could represent real productivity, or they could reflect smaller commits, extra iteration, and more automated busywork. A chart rising to the top right isn’t enough to tell us which one is happening. We need defect rates, production outcomes, reviewer effort, and spending alongside that merge count.
Git Isn’t Dead. The Assumptions Around It Are Changing.
The part of Anthropic’s announcement that will probably age best is not the claim that a small team created Scion in five months. It is the decision to redesign source control around the clients it actually had. Those clients were mostly online agents and jobs asking repeated, narrow questions of a repository too large to copy casually. The old architecture kept treating them like independent human developers. Eventually that became too expensive.
For most of us, Git remains the sensible choice. Anthropic says so itself. Scion is not publicly available as a drop-in replacement, and adopting it would require different review, search, and CI tools. That is an enormous migration cost for a problem that the average repository doesn’t have.
But I do think this is a warning worth remembering when we celebrate AI writing more code. Every extra change travels through source control, reviews, builds, tests, deployment, and monitoring. Speeding up the first step can expose costs hidden in the next five. Anthropic ran into those costs early because it used Claude at a scale most teams haven’t reached.
The lesson isn’t to throw away Git tomorrow. It’s to measure what happens after an AI agent finishes typing. Anthropic’s 30,000 daily merges are a useful number, but the more interesting number will be how much reliable software those merges actually deliver.