For years, software teams had a familiar problem: not enough developers to build everything they wanted.
AI is starting to reverse that problem.
Now there can be too much code.
Anthropic has just provided one of the clearest examples of what that change looks like inside a real engineering organization. The company says its average daily volume of merged code changes climbed from roughly 2,500 in May 2026 to more than 30,000 by September.
The surprising part is what happened next.
Anthropic didn’t simply add more compute or ask developers to review faster. It rebuilt a piece of the infrastructure underneath software development.
The company created Scion, an internal source-control system, and migrated its monorepo from Git to the new system in five months. It also built a separate code-review system called Antique and related infrastructure around the new workflow.
That story is easy to summarize as “Anthropic replaced Git.”
It is also the wrong lesson to take from it.
The more important story is about AI source control: what happens when the machines producing software changes become dramatically faster than the human workflow that was built to organize those changes?
The Bottleneck Moved
Software development has always had bottlenecks.
Sometimes it is writing code.
Sometimes it is debugging.
Sometimes it is waiting for a build.
Sometimes it is getting a pull request reviewed.
Anthropic says its internal experience has reached a point where coding itself is no longer the main constraint. Claude can work through research loops, optimize programs and build services at a pace that changes the economics of the development process. The infrastructure around that work—source control, builds and CI—started becoming the limiting factor instead.
That is a subtle but important shift.
Imagine a factory where someone suddenly doubles the speed of every machine on the production floor.
The factory doesn’t automatically produce twice as much.
Sooner or later, something else gets overwhelmed.
Maybe the loading dock.
Maybe quality control.
Maybe inventory.
Maybe the workers who have to inspect every item.
AI coding agents create a similar problem in software.
Generating a change can become cheap.
Managing the consequences of thousands of changes becomes the difficult part.
Why Human-Scale Source Control Worked So Well
Git was designed around a very useful set of assumptions.
A developer has a working copy.
That developer makes changes.
The work is committed.
Branches allow different efforts to proceed independently.
Changes are merged.
History is preserved.
The model is extremely flexible, and it became the foundation for modern software development.
But it also reflects the way humans work.
People spend time reading code.
People decide when to commit.
People create branches.
People open pull requests.
People wait for reviews.
People wait for CI.
People resolve conflicts.
An AI agent doesn’t necessarily need to behave that way.
An agent can make changes continuously.
It can work on multiple tasks.
It can inspect a repository programmatically.
It doesn’t need to sleep.
It doesn’t need to wait until tomorrow to revisit a merge conflict.
And if one agent becomes cheap enough to run, organizations can run many of them.
That changes the assumptions underneath the workflow.
30,000 Changes a Day Is the Important Number
Anthropic’s headline figure is striking because of the distance between May and September.
Around 2,500 merged changes per day became more than 30,000.
That’s more than a tenfold increase in only a few months.
But the number isn’t interesting merely because it is large.
It tells us something about what happens when the cost of producing software falls.
There is a hidden demand for engineering work.
When coding is expensive, teams naturally limit how many changes they attempt.
When coding becomes cheaper, more ideas become worth trying.
More experiments happen.
More agents can work simultaneously.
More small improvements become economically sensible.
And suddenly the system responsible for moving those changes through development has a much larger workload.
In other words, AI doesn’t just accelerate the developer. It can increase the total amount of development happening.
That is the infrastructure problem Anthropic had to solve.
Scion Starts With a Different Assumption
One of the biggest differences between Scion and traditional Git workflows is the assumption about connectivity.
Git was designed around the idea that a client can possess a complete repository and perform many operations locally.
That is extremely powerful.
But if the majority of your clients are automated agents and jobs running in a controlled environment, you may not need every client to behave like a miniature server.
Anthropic designed Scion around an always-online model. Instead of requiring clients to carry the entire repository state, the server can answer questions about history and perform operations such as commits, merges and rebases.
That sounds like an implementation detail.
At scale, it becomes an architectural decision.
If thousands of agents are working against a large repository, repeatedly moving unnecessary data around is not free.
Network traffic costs time.
Repository operations consume compute.
Local storage grows.
Context retrieval becomes more important.
And every unnecessary operation gets multiplied by the number of agents performing it.
Source Control Becomes a Server Problem
This leads to one of the most interesting ideas in Anthropic’s experiment.
Traditional source control gives developers a lot of power locally.
Agent-scale source control can move more intelligence to the server.
Instead of asking every agent to understand everything about a repository, the infrastructure can answer more targeted questions.
An agent may need:
- the files relevant to a task
- the history of a particular component
- information about a merge
- the ancestry of a change
- the state of another branch
- the result of a previous operation
It doesn’t necessarily need the entire world copied onto its machine first.
This approach also fits a broader direction in the industry.
GitLab is developing next-generation source-code management aimed at agentic workloads, including server-side repository access rather than requiring every agent to operate through traditional full-repository workflows. GitLab says its work is designed around thousands of concurrent agents and the performance, context and governance problems that appear at that scale.
Anthropic is therefore not the only company asking this question.
The Pull Request May Not Be the Right Unit Anymore
There is another consequence that is easy to miss.
Human software development is organized around changes that people can reasonably inspect.
A developer opens a pull request.
Someone reviews it.
CI runs.
The change gets merged.
That works when the number of changes is manageable.
But what happens when hundreds or thousands of changes are moving through the system concurrently?
Anthropic says it has been rethinking the merge queue itself. Instead of relying on a traditional global repository lock while changes are being merged, the company has invested more heavily in automated testing before deployment and after changes land. Concurrent conflicts can happen, but agents can often resolve them faster than humans can identify them.
This is a significant philosophical change.
The system no longer has to prevent every conflict before it happens.
It can sometimes allow more concurrency and recover automatically.
That is a very different optimization target.
Code Review Changes Too
The obvious fear is that more AI-generated code means humans will drown in pull requests.
Anthropic’s experience suggests another possibility.
Its engineers still review every change request for Scion, but the focus has shifted.
Instead of attempting to read every line, engineers can concentrate more heavily on whether the change is conceptually correct.
That distinction matters.
An agent can produce a large amount of technically plausible code.
The difficult question is whether that code belongs in the system.
Anthropic describes engineers repeatedly having to tell Claude “no” when an implementation violated an important architectural constraint or added unnecessary complexity.
That may be one of the most important lessons in the entire story.
As agents become better programmers, engineers may spend less time acting as human syntax checkers and more time acting as system-level decision makers.
The code still needs review.
But the review happens at a different level.
More Code Does Not Automatically Mean Better Software
This is where the excitement around agentic development needs some restraint.
Anthropic reports that Scion became one of its most heavily tested and defended codebases. The team built simulations for complex infrastructure interactions, used fuzzing and rate limiting, and found significant performance opportunities through AI-assisted analysis.
But the same article describes cases where agents produced solutions that technically worked while violating important system assumptions.
That is not a contradiction.
It is exactly what you should expect from increasingly capable coding agents.
The machine can explore implementation space extremely quickly.
It doesn’t automatically know which parts of the design are sacred.
An engineer might know that a particular internal service is authoritative.
An agent may decide to independently reconstruct the same information because that pattern looks reasonable.
The resulting code can pass tests.
It can still be wrong.
This is why agent-scale development needs stronger architectural context, not merely stronger code generation.
CI Has a New Problem Too
Continuous integration was built around a world where code changes arrive at a rate humans can reasonably manage.
Agentic development can change that.
Suppose 500 agents are working simultaneously.
By the time one group of tests finishes, dozens or hundreds of new changes may already exist.
Now ask a simple question:
What exactly does “continuous” mean?
Anthropic explicitly raises this issue when discussing its new infrastructure. At agent scale, traditional CI and merge-queue assumptions start looking less obvious.
The answer may not be to make CI simply run faster.
It may require changing what gets tested, when it gets tested, how changes are grouped, and how much verification happens before versus after integration.
That is a much larger systems problem.
The Monorepo Gets More Interesting
Anthropic’s Scion work is also a reminder that huge repositories create their own engineering requirements.
A monorepo can make code sharing and cross-project changes easier.
It can also turn repository operations into infrastructure problems.
At small scale, searching history or checking ancestry is just a developer action.
At very large scale, the same operation may become something thousands of automated processes perform repeatedly.
Suddenly the efficiency of the underlying data model matters.
Anthropic says Scion drew on prior work from systems such as Google’s Piper and Meta’s Sapling, particularly around large-scale source control.
So Scion isn’t appearing from nowhere.
It is another step in a longer evolution from developer-oriented version control toward infrastructure designed for very large repositories and high concurrency.
Security Becomes Part of Source Control
Agent-scale development also changes the security question.
A human developer may have access to a broad repository because they need to navigate it manually.
Thousands of agents shouldn’t necessarily have identical visibility.
Anthropic built Scion with richer access controls, including permissions that can be applied at the repository and directory level. Its code-review tooling can also distinguish between different kinds of changes when determining approval requirements.
That is important because AI agents can operate at a speed where a bad permission model becomes dangerous very quickly.
The future of source control therefore isn’t only about faster merges.
It is also about answering:
Which agent is allowed to see what?
Which agent can modify what?
Which changes require a human?
What evidence should be retained about an agent’s actions?
Those questions belong to source control infrastructure just as much as commits do.
Anthropic Didn’t Build Scion Because Git Suddenly Failed
This distinction deserves emphasis.
Git remains enormously useful.
For most development teams, Git is not suddenly the wrong choice because Anthropic built Scion.
Anthropic operates at an unusual scale and has an unusual percentage of its software work performed with AI agents.
Its infrastructure problem is therefore not automatically everyone’s infrastructure problem.
The more useful lesson is to watch the direction of pressure.
If your organization moves from ten coding agents to one hundred, some workflow assumptions may start to bend.
If it moves from one hundred to thousands, different assumptions may break entirely.
That doesn’t necessarily mean replacing Git.
It may mean adding smarter systems around it.
Or using server-side operations.
Or changing how code is reviewed.
Or redesigning CI.
Or introducing agent-specific permissions and audit trails.
The architecture can evolve without throwing away everything that came before it.
Why This Matters Beyond Anthropic
The most important consequence of the Scion story is that source control is becoming part of the AI infrastructure conversation.
Git used to sit underneath software development almost invisibly.
Developers knew it was there, but the interesting work happened above it.
Agentic development changes that relationship.
If machines generate changes faster than humans can process them, the infrastructure underneath those changes becomes a competitive constraint.
That’s why companies beyond Anthropic are exploring the same territory.
GitLab is explicitly working on next-generation source-code management for agentic workloads, including repository access, concurrency and governance. Its public material describes a system intended to support thousands of concurrent agents while preserving controls familiar to software teams.
The industry is beginning to discover that AI coding is not only an IDE problem.
It is a software-systems problem.
What Developers Should Watch Next
The next generation of developer infrastructure may be defined by a few questions.
How much repository context should an agent receive?
Giving an agent everything can be expensive and unnecessary.
Giving it too little can cause incorrect decisions.
The useful middle ground may be intelligent, server-side context retrieval.
How should changes be reviewed?
Line-by-line review made sense when humans produced the changes.
Agent-generated changes may require more emphasis on intent, architecture, tests and policy.
How should CI work when changes arrive continuously?
A pipeline designed around dozens of daily changes may behave very differently when hundreds or thousands arrive.
Who controls the agents?
Identity, permissions, audit trails and approval policies become more important as agents gain the ability to modify production code.
What happens when fixing a conflict is cheaper than preventing it?
This may be one of the biggest conceptual changes.
Human workflows often try to prevent conflicts because resolving them is expensive.
If an agent can resolve many conflicts automatically, the optimal system may tolerate more concurrency.
That could change how software teams think about coordination itself.
The Bigger Shift Is From Developer Speed to System Throughput
For years, developer tools competed on one question:
How quickly can one developer write code?
AI agents are changing the question.
Now it becomes:
How much reliable software can an entire engineering system produce?
Those are not the same thing.
If an AI coding assistant makes one developer twice as fast, that’s useful.
If an organization can run hundreds of agents simultaneously, the limiting factor moves elsewhere.
Source control.
Testing.
Build infrastructure.
Review.
Security.
Deployment.
Observability.
Coordination.
The bottleneck becomes the system around the programmer.
That is what makes Anthropic’s Scion story much more significant than another announcement about an internal developer tool.
Final Thought
The headline is that Anthropic built its own source-control system.
The deeper story is that software development is beginning to operate at a speed its old infrastructure was never designed to handle.
Git was built for an extraordinarily successful model of collaboration: humans making changes, reviewing them, merging them and learning from the history.
AI agents don’t necessarily work at that rhythm.
They can operate concurrently.
They can keep producing changes.
They can resolve some problems automatically.
They can generate more demand for engineering work precisely because engineering work has become cheaper.
That doesn’t make Git obsolete.
It means the assumptions around Git are worth examining.
Scion is one company’s answer to that problem. GitLab is exploring another direction. Other infrastructure companies will almost certainly face the same question as agent adoption grows.
The future of AI development may therefore depend on something that gets much less attention than the latest coding model:
the infrastructure that decides what happens after the AI writes the code.
And source control may be one of the first places where that future becomes visible.