DEV Community: Himanshu Chauhan

Anthropic Replaced Git Because AI Agents Were Writing Code Too Fast

Himanshu Chauhan — Wed, 14 Oct 2026 12:26:01 +0000

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

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?

Google's New AI Agent Can Use Claude Too — Is This the Future of AI Development?

Himanshu Chauhan — Tue, 13 Oct 2026 09:22:14 +0000

I didn't expect Google to make one of the more interesting announcements in the AI agent space by bringing a competitor's models into the picture.

But that's exactly what happened.

On October 8, at Gemini at Work 2026, Google introduced its new Gemini agent. It can work across business applications, write and run code, and coordinate complex tasks.

That's interesting on its own. But one detail caught my attention.

The Gemini agent can use Anthropic's Claude models alongside Google's own Gemini models.

Yes, Google is building an AI agent that doesn't have to rely exclusively on Google's AI models.

And I think that says something important about where AI development is heading.

So, what exactly did Google announce?

Think about how most of us interact with AI today.

We open ChatGPT, Gemini, or Claude, describe a problem, get a response, and then figure out what to do with that response.

Even when AI writes useful code or analyzes a document, we usually handle the next steps ourselves.

Google's new Gemini agent is trying to move beyond that.

Instead of simply responding to prompts, it's designed to complete tasks across the tools people already use.

According to Google's announcement, the agent can:

Work across Gmail, Docs, Sheets, Drive, and Calendar.
Write and execute code.
Connect with third-party tools and business systems.
Coordinate specialized AI agents for different tasks.
Maintain context across devices and longer-running workflows.
Select different AI models depending on the task.

The last point is what makes this particularly interesting.

Wait... Gemini can actually use Claude?

Apparently, yes.

Google confirmed that its new agent can orchestrate tasks using both Gemini and Anthropic's Claude models.

That doesn't mean Claude is replacing Gemini, or that every Gemini product automatically gives users access to Claude.

The important distinction is that the agent and the underlying AI model are separate parts of the system.

The agent manages the workflow.

The model handles the reasoning or generation required for a particular step.

Google's approach allows the system to choose between supported models based on what it needs to accomplish.

For example, imagine an agent working on a software project.

It might need to:

Understand the requirements.
Read documentation.
Generate or modify code.
Review the changes.
Prepare a summary for the developer.

Different models may perform differently across these tasks.

Instead of forcing every step through one model, a multi-model system can select a more suitable option.

That's the idea behind model orchestration.

And personally, I find that more interesting than another benchmark comparison.

Why this matters for developers

We've spent the last few years comparing AI models.

Which one writes better code?

Which one has stronger reasoning?

Which one is faster?

Which one costs less?

Those questions still matter, of course.

But when you're building an actual product, choosing the best model isn't always as simple as picking the one at the top of a leaderboard.

A model that's excellent at complex reasoning might be unnecessary for a basic classification task.

A faster, cheaper model might be perfectly suitable for summarizing short documents.

And a coding-focused task might benefit from a different model than the one used for general conversation.

This is why I think multi-model development deserves more attention.

1. Less dependence on one model provider

Imagine building an application where every AI feature depends on a single provider.

If pricing changes, performance drops, or a particular model becomes unavailable, your application might be affected.

Having a model-independent architecture gives developers more flexibility.

It doesn't eliminate vendor lock-in completely. The orchestration platform itself can become a dependency.

But it potentially makes changing the underlying model easier.

2. Better cost management

Not every user request needs the most expensive model.

For example, a support application might handle thousands of simple questions every day but only occasionally receive a complicated technical issue.

Using an expensive reasoning model for every request could become costly.

A routing system could use a lightweight model for straightforward tasks and a more capable model when needed.

Of course, routing decisions also have a cost. You need to account for latency, token usage, and the complexity of evaluating different models.

Still, it's a promising design pattern.

3. More freedom to experiment

This might be my favorite part.

Developers shouldn't have to rebuild entire applications every time a better model becomes available.

Ideally, we should be able to test multiple providers, compare their outputs, and choose what works best for our specific use case.

Not what works best in a generic benchmark.

What works best in our actual application.

A simple example of how model routing works

Let's say we're building an AI-powered developer assistant.

It handles documentation questions, code reviews, and complex debugging problems.

A simplified routing system could look something like this:

// Conceptual example, not Google's actual API

function selectModel(task) {
  switch (task.type) {
    case "documentation":
      return "fast-model";

    case "code-review":
      return "coding-model";

    case "complex-debugging":
      return "reasoning-model";

    default:
      return "general-model";
  }
}

async function handleTask(task) {
  const model = selectModel(task);

  return await runModel(model, task.prompt);
}

Nothing revolutionary about the code itself.

The interesting part is the architecture.

Instead of building your entire application around one model, you build a system that can work with different models.

In production, things get more complicated.

You'd need authentication, provider adapters, retry handling, structured outputs, cost tracking, and proper evaluations.

You'd also need to make sure that switching models doesn't silently break features that depend on specific output formats or tool-calling behavior.

But the basic idea remains useful.

The application should own the workflow. The model should be a replaceable component whenever practical.

There's another part of this announcement worth discussing

Google isn't just talking about switching models.

The new Gemini agent is also designed to coordinate multiple specialized agents.

This is where things get a little more complicated.

Imagine asking an AI assistant to prepare a technical report about your application.

One agent could analyze code changes.

Another could examine issue-tracking data.

A third could prepare a summary.

The main agent would coordinate the work and bring the results together.

That sounds convenient.

But anyone who has built even a relatively simple automation knows that connecting several systems introduces new ways for things to fail.

What happens when one agent returns incorrect information?

What if two agents reach conflicting conclusions?

What if an agent accidentally gets access to information it shouldn't have?

These aren't small implementation details.

They're exactly the problems developers need to solve before autonomous agents can be trusted with important workflows.

The part I'm still skeptical about

I'll admit that the idea of AI agents coordinating tools and models is exciting.

But I'm not convinced that adding more agents automatically makes a system better.

Sometimes a straightforward script with a few API calls is more reliable than a complicated agent workflow.

And sometimes a single model is perfectly adequate.

There's also the question of transparency.

If an AI platform automatically chooses a model, how much visibility does the developer have into that decision?

Can we inspect which model handled a particular task?

Can we measure the cost and latency of each step?

Can we reproduce the same workflow when debugging a failure?

Can we control where sensitive information is sent?

For enterprise applications, those questions are just as important as raw AI performance.

Model orchestration is useful only when developers can understand, evaluate, and control it.

Is this the future of AI development?

I think it could be part of it.

Not because Google has suddenly solved AI agents, and not because using multiple models is a completely new concept.

Developers have already been experimenting with model routing and multi-agent systems.

What's interesting is seeing a major AI provider explicitly position its own agent as something that can operate across competing models.

It suggests that the competition may gradually shift.

Instead of competing only on who has the smartest model, companies may also compete on who can build the most useful systems around those models.

Systems that understand context, connect to real tools, execute tasks reliably, and give developers meaningful control.

That's a much bigger engineering challenge than building a chatbot interface.

And it's probably where some of the most interesting developer problems will emerge.

Final thoughts

The biggest takeaway from Google's announcement isn't simply that Gemini can use Claude.

It's that the AI model and the AI application are becoming increasingly separate decisions.

For developers, that could mean more flexibility when designing AI-powered products.

But it also means we'll need to get better at orchestration, evaluation, security, and understanding how our systems behave when things go wrong.

I'm curious to see how well Google's approach performs outside controlled demonstrations.

Because supporting multiple models sounds great on paper.

Making them work together reliably in production is the real challenge.

What do you think?

Would you rather build an application around one powerful AI model, or use multiple specialized models for different tasks?

I'd love to hear how other developers are approaching this.

Sources

Based on Google's October 8, 2026 announcement. The code example is conceptual and does not represent Google's official implementation.