Anthropic Replaced Git Because AI Agents Were Writing Code Too Fast

Imagine telling a developer in 2020 that one day an AI company would have to build its own version control system because its AI agents were producing too much code.

They'd probably laugh.

Yet here we are.

On October 13, 2026, Anthropic published something I found more interesting than another AI model announcement.

They explained why they'd moved their internal monorepo away from Git and built an entirely new source control system called Scion.

Not because Git suddenly became bad.

Not because Git was outdated.

But because their development workload had changed so dramatically that the assumptions behind their existing infrastructure were starting to break.

And the numbers are pretty wild.

From 2,500 to 30,000+ merges a day

In May 2026, Anthropic averaged around 2,500 merged code changes per day.

By September, that number had climbed past 30,000.

That's more than 12 times the previous volume in roughly four months.

Think about what that means for the systems around the code.

Every change can involve repository operations, testing, review, merging, and deployment.

Now multiply those operations across thousands of agents and automated jobs working simultaneously.

At that scale, generating code isn't necessarily the expensive part anymore.

Everything that happens around the code starts becoming the problem.

Anthropic's engineering team described exactly that situation.

And it led them to question something most of us take for granted.

Does every developer really need a local Git repository?

Git wasn't designed for this kind of developer

Git is brilliant at what it was designed to do.

A developer clones a repository, works locally, makes commits, checks history, creates branches, and pushes changes.

You can work offline. You don't need a server to examine your local history. Your repository contains the information needed for a wide range of operations.

For humans working on normal-sized projects, that's incredibly useful.

But think about an AI coding agent running inside an automated cloud environment.

It might need to modify three files, run tests, submit a change, and disappear.

Does it really need access to an enormous repository history?

Does a CI job that only wants to calculate a diff need to reconstruct a large portion of the repository?

Not necessarily.

At Anthropic, these questions became very real.

Their main branch history was approaching 100 GB.

A compressed working copy was over 25 GB.

And their CI infrastructure was performing roughly 25 million checkouts every day.

They'd already tried the usual scaling techniques:

• Shallow clones
• Sparse checkouts
• Repository snapshots
• Internal Git mirrors

At one point, Anthropic operated several hundred Git mirrors.

These approaches helped, but their maintenance costs kept growing along with the merge volume.

Eventually, the company decided that continuing to optimize the same architecture wasn't enough.

They needed something built around a different set of assumptions.

Enter Scion

Scion is Anthropic's internal source control system, designed around agent-heavy development.

The key idea is surprisingly straightforward.

Most agents are always online. So why design their source control around offline independence?

Instead of requiring every client to perform complicated repository operations locally, Scion moves much of that work to the server.

Here's a simplified comparison:

Operation	Git	Scion
Repository history	Stored in local clones	Primarily server-side
Commits	Created locally	Created on the server
Merges and rebases	Can happen locally	Handled by the server
History and blame queries	Computed locally or via platform APIs	Available through server APIs
Checkouts	Can materialize entire working trees	Sparse and virtualized by design
Offline support	A core capability	Assumes online clients

Of course, Git supports sparse checkouts and remote services too.

The difference is that Scion treats lightweight clients and server-side operations as foundational design choices.

That opens up some interesting possibilities.

For example, a CI job that needs to compare two changes can request the diff through an API.

It doesn't need to check out an entire working tree first.

An agent that only needs a few directories can fetch those directories rather than materializing everything.

And when thousands of jobs repeatedly access similar files, a layered caching system can make those reads much cheaper.

The architecture is where it gets interesting

Scion isn't just Git with a faster server.

Anthropic redesigned some important data structures.

Its unit of work is a changeset.

A changeset records the files modified relative to its first parent, along with pointers to file contents stored separately.

This differs from Git's familiar commit-and-tree representation.

Scion also maintains derived data structures for operations such as file history, blame, and commit ancestry.

These can be computed as needed or prepared in advance.

The system is designed so that adding a commit doesn't require work proportional to the entire repository.

That's an important detail.

When your monorepo contains an enormous history, you want the cost of a small change to stay small.

Scion's storage and caching architecture also relies heavily on immutable, content-addressed objects.

Multiple servers can safely cache the same objects without constantly coordinating changes to them.

The result is a system where different components can scale independently.

This is particularly useful when the workload consists of huge numbers of relatively small operations.

And Anthropic says the payoff was substantial.

200x smaller infrastructure. 100x faster checkouts.

According to Anthropic's internal measurements, Scion delivered:

• 200x lower CPU and memory requirements for its source control infrastructure compared with the previous Git mirroring setup.
• Roughly 100x faster checkouts for CI and research jobs, reducing minutes to seconds.
• 25% CPU capacity savings in CI alone.
• Cache hit rates exceeding 99% across its caching tiers.

These results are specific to Anthropic's infrastructure, so they shouldn't be interpreted as a universal Scion-versus-Git benchmark.

But they demonstrate something worth paying attention to.

Sometimes the biggest performance improvement doesn't come from making an existing operation faster.

It comes from designing a system that avoids doing that operation unnecessarily.

Seven engineers built all this in five months

This might be the most surprising part of the whole story.

Anthropic says a team of seven engineers built Scion, its code review tool called Antique, and multiple supporting systems.

They then migrated the monorepo.

In five months.

Anyone who's worked on infrastructure knows how ambitious that sounds.

Source control needs to be extremely reliable. Losing a piece of code history or introducing subtle consistency problems isn't an acceptable trade-off for speed.

And migrating an active monorepo while its workload is growing rapidly makes the problem even harder.

So how did they move so quickly?

Unsurprisingly, Claude played a major role.

Anthropic shared an example involving its Git-to-Scion ingestion pipeline.

The engineers had written an initial prototype themselves.

They then asked an early internal version of Claude Mythos Preview to rewrite it.

Anthropic reports that the rewritten version used 20x less memory and was 4x faster, while preserving the necessary correctness constraints.

That's an impressive result.

But it also reveals a strange feedback loop.

Claude's growing coding capabilities helped create the source control bottleneck.

Then Claude helped the engineers build the infrastructure that removed it.

And removing that bottleneck makes it possible to produce even more code.

I suspect we'll see this pattern again.

The engineer's job is changing

One particular detail from Anthropic's article stuck with me.

The team described how a significant part of their work involved telling Claude "no."

Not because Claude couldn't write code.

But because writing technically valid code is only one part of engineering.

An agent might introduce a solution that works locally but breaks a larger architectural constraint.

It might optimize a path that doesn't need optimizing.

It might add unnecessary complexity to address a hypothetical edge case.

Or it might solve a problem in a way that becomes impossible to maintain at scale.

The human engineers still needed to understand the architecture, evaluate trade-offs, and maintain system-wide consistency.

Anthropic says its engineers continue reviewing every change request, but increasingly focus on the intent of changes instead of reading every line.

That raises an interesting question.

If an AI can write code faster than we can read it, what does effective code review look like?

I don't think anyone has completely solved that yet.

And the challenge gets bigger when the system is merging tens of thousands of changes per day.

CI might be the next thing we need to rethink

Consider a familiar development workflow.

You open a pull request.

CI runs.

The tests pass.

The change gets merged.

Simple enough.

But what happens when hundreds or thousands of other changes merge while your tests are running?

The codebase can evolve substantially between the moment a test begins and the moment its results become available.

Traditional merge queues can serialize changes to maintain stronger guarantees about what gets tested before merging.

But serializing everything can become expensive at enormous throughput.

Anthropic says it has been investing in post-merge and pre-deployment testing rather than relying on a global merge-queue lock.

That introduces different engineering trade-offs.

Concurrent changes can conflict. Failures need to be detected and handled quickly. Testing must remain meaningful despite constant changes to the repository.

And there's a bigger problem beneath all of this.

Generating 30,000 changes isn't the same as proving that 30,000 changes are correct.

AI may dramatically increase the amount of code we can produce.

But confidence, reliability, security, and maintainability still require serious engineering.

The faster we generate code, the more important those systems become.

Should we all stop using Git?

Absolutely not.

Anthropic is very clear that Scion isn't intended as a general-purpose Git replacement.

Most teams aren't processing 25 million checkouts per day.

Most repositories aren't hundreds of gigabytes.

And most developers still benefit greatly from local history, offline commits, and Git's mature ecosystem.

There are also trade-offs to Scion's architecture.

A server-centric system introduces stronger dependencies on network availability and central infrastructure.

Building a new source control system also means maintaining compatible workflows for code review, CI, permissions, and developer tooling.

For most companies, that's an enormous amount of complexity to take on.

And scalable source control beyond traditional Git isn't new. Google has Piper, and Meta has invested in Sapling.

So Scion isn't proof that Git is obsolete.

It's evidence that agent-scale development can create workloads where a different architecture becomes attractive.

That's a much more useful takeaway.

What this means for the rest of us

You probably don't need to build a new version control system.

But I think there are several lessons worth carrying into our own development workflows.

First, optimize the entire development process, not just code generation.

A faster coding assistant doesn't help much if every change waits an hour for tests or review.

Second, treat agent workloads differently from human workloads where it makes sense.

An ephemeral agent performing a small task doesn't necessarily need the same environment as a developer working on a repository all day.

Third, build systems that make correctness easier to verify.

More generated code means more opportunities for subtle integration problems. Better tests, observability, and architectural constraints become increasingly valuable.

And finally, don't confuse code output with engineering progress.

The number of merged changes is an interesting measure of throughput.

It's not, by itself, a measure of product quality or customer value.

That distinction matters even more when machines can generate changes at enormous speed.

The bigger picture

What fascinates me about Scion isn't the idea that Anthropic replaced Git.

It's the reason they had to do it.

We've spent decades building developer tools around the pace and behavior of human programmers.

An engineer writes some code, runs a few tests, creates a commit, and asks someone to review it.

Our workflows evolved around that rhythm.

AI agents are changing the rhythm.

They can operate continuously, work in parallel, and generate changes much faster than traditional human teams.

Eventually, the supporting infrastructure becomes the limiting factor.

Source control was one bottleneck for Anthropic.

For other teams, it might be CI, review capacity, debugging, security, or production deployment.

And once those bottlenecks start moving, software engineering could begin to look very different.

Maybe the most valuable engineer won't be the person who can write the most code.

Maybe it'll be the person who can design a system where enormous amounts of code can be generated, verified, and changed without losing control of the bigger picture.

That's the part of Anthropic's announcement I think is worth watching.

The future of software engineering might not be about writing code faster.

It might be about building systems that can keep up with how fast code is being written.

And we're only starting to figure out what those systems should look like.

---

References

• Anthropic Engineering: Redesigning source control at Anthropic
• Developers Digest: Anthropic Scion and agent-scale source control

---

I'm curious what other developers think:

If AI agents become responsible for most routine code generation, which part of our development workflow will become the biggest bottleneck next?

Code review? CI? Debugging? Or something we haven't anticipated yet?