AI coding agents have changed how fast you can write code. But what happens when the infrastructure underneath can’t keep up with that pace?

GitHub recently shared numbers that show how big this shift is. In September 2026 alone, developers and agents made 7.38 billion commits on GitHub. That is more than five times the number from a year earlier.

Between September 2025 and August 2026, it more than doubled, from 218.2 billion events per month to 473.3 billion.

GitHub says agentic development is driving this growth, and it is now rebuilding the Git infrastructure behind the platform to handle it. In this article, you’ll learn what is changing, why the old design struggles with agents, and how GitHub plans to fix it, in simple terms.

(Source: GitHub Engineering Blog)

Table of Contents

• Why AI Coding Agents Are Changing Software Development
  • How AI Agents Change the Development Workflow
  • How One Push Triggers More Work
• Why GitHub's Existing Architecture Struggles to Scale
  • How GitHub Stores Git Repositories
  • The Architectural Bottleneck: Why Scaling Reads Makes Writes Harder
  • Where the Old Architecture Hits Its Ceiling
  • What Happens When a Fileserver Fails?
• How GitHub Is Redesigning Its Git Infrastructure
  • Separate Storage From Compute
  • How GitHub Plans to Make Pushes Faster
  • How GitHub Moves Maintenance Off the Serving Path
• Adapt or Get Left Behind

---

Why AI Coding Agents Are Changing Software Development

How AI Agents Change the Development Workflow

Humans and AI coding agents do not use Git in the same way. A developer might push a few times a day. If a push takes a second or two, you will not even notice it.

An agent works differently. It saves its progress after almost every small step, so it commits and pushes again and again. Each time, it has to wait for the push to finish before moving ahead.

Imagine waiting two seconds after typing every sentence in a document. You would feel it very quickly. This is what an agent faces. The time a push takes becomes the speed limit for the whole workflow.

How One Push Triggers More Work

The problem does not end after the push. Many automated systems react to every new commit. For example:

• A continuous integration (CI) pipeline clones the repository to run tests.
• Security scanners clone it to check for vulnerabilities.
• Other agents fetch the new changes to continue their own work.

Cloning means downloading the full repository, and fetching means downloading only the latest changes.

GitHub says CI and code scanning alone can clone or fetch the same branch thousands of times per minute. This pattern, where one action spreads into many, is called fan-out. GitHub Actions ran 3.26 billion times in September 2026, which is more than four times the number from a year earlier.

So every push (a write) creates a large number of reads. These reads must stay fast and cheap, otherwise everything slows down.This is where the old design starts to struggle

---

Why GitHub's Existing Architecture Struggles to Scale

To understand why the old architecture struggles, let's look at how GitHub stores repositories and why that design becomes a bottleneck for agentic workflows.

How GitHub Stores Git Repositories

GitHub uses a system called Spokes to store and manage Git repositories across multiple fileservers. It keeps copies of each repository in sync so GitHub can handle operations like cloning, fetching, and pushing code.

When a repository is created on GitHub, Spokes assigns it to a set of fileservers - five by default. Each fileserver stores a complete copy of the repository on its local disk. Spokes coordinates these copies to keep the repository data consistent across the fileservers.

When a push arrives, Spokes coordinates the write across the repository's replicas using a quorum-based protocol.

The Architectural Bottleneck : Why Scaling Reads Makes Writes Harder

Now that we understand how GitHub stores repositories, let's look at a problem with this architecture.

Agentic workflows can generate more repository activity than traditional development workflows. CI pipelines, security scanners, and other agents may repeatedly clone or fetch the same repository. As this read traffic grows, GitHub needs a way to serve more requests without slowing down the systems that accept new changes.

In the existing architecture, one way to increase read capacity is to add more fileservers and replicate repository data across them. More replicas can help distribute read traffic, but they also introduce a trade-off.

Remember how Spokes coordinates writes across repository replicas using a quorum-based protocol ?

When a developer or an AI agent pushes new changes, Spokes has to coordinate the write across the fileservers.

When a push updates a reference, Spokes uses a three-phase commit protocol and a quorum to keep repository state consistent. Because the replicas participate in the write, the push can be limited by the slowest replica. Adding replicas to handle more reads can therefore increase the cost of writes.

Now, if GitHub adds more fileservers to handle more read requests, it also has more replicas to manage. This can make writes more complicated and increase the time needed to complete them.

In simple terms, adding more fileservers can help handle more reads, but it can also make writes slower.

The infrastructure used to increase read capacity is also involved in the process of accepting writes. Optimizing one side of the workload can therefore make the other side more expensive.

This becomes a bigger problem when AI agents push changes frequently while CI pipelines and other systems keep reading the repository.

So, the question is: Can GitHub handle more read requests without making writes slower?

That's exactly what GitHub wants to solve with its new architecture.

Where the Old Architecture Hits Its Ceiling

The ceiling comes from a fundamental design choice - durability and scale are the same mechanism. The fileserver replicas are both your serving fleet and backup plans.

This creates three problems:

• Scaling reads hurts writes.
• Scaling writes hurts reads.
• You can't optimise one at a single time without hurting other.

What Happens When a Fileserver Fails?

Let's say one of the five fileserver holding your repository dies. Whether it's disk crashes , the machine lose power or for any other reason.

Now you lose two things :

• You lose one read server - only four machines can serve clone and fetch requests for that repo. Read capacity dropped by 20%
• You lose one durable copy - only four copies of your repo exists instead of five. Your safety margin shrank.

---

How GitHub Is Redesigning Its Git Infrastructure

Now, let's see how GitHub plans to handle the growing demands of agentic workflows.

Separate Storage From Compute

One of the major changes is separating the storage layer from the compute layer.

In the new architecture repository data will be stored in Azure Blob Storage, which handles data durability and replication. Lightweight compute workers will handle incoming Git requests. The workers will cache data locally to serve requests faster and fetch it from Azure Blob Storage when needed.

Now, when GitHub needs to handle more read traffic, it can simply add more compute workers without adding more replicas to the write path. This means it can increase read capacity without adding the same overhead to writes.

And if a compute worker fails, the repository data is still safe because the actual data lives in Azure Blob Storage. Another worker can take over the requests.

How GitHub Plans to Make Pushes Faster

In the old system, a push involved several operations before GitHub could confirm that it was complete. These included storing Git objects, checking whether they were connected correctly, running secret scanning, and updating the reference.

Not all these operations need to wait for each other. GitHub's new approach is to reduce the work that must finish before a push can be acknowledged.

The key step is updating the reference, which tells Git where the latest commit is. This update needs coordination to keep the repository consistent. Other work, such as storing objects, checking their connectivity, and scanning for secrets, can happen in parallel with other writes.

By reducing the work that has to wait for coordination, GitHub aims to make pushes faster. For AI agents that commit frequently, even a small reduction in push latency can help them move through their workflows faster.

How GitHub Moves Maintenance Off the Serving Path

Previously, repository maintenance tasks, such as compaction and garbage collection, ran on the same fileservers that handled live Git requests. This meant background tasks could compete with incoming requests for CPU, memory, and other resources.

To solve this, GitHub plans to introduce separate workers to handle repository maintenance directly on data stored in Azure Blob Storage. This keeps maintenance work separate from the workers handling live Git requests.

Now, live Git requests and background maintenance run separately, so cleanup tasks are less likely to compete with live requests for the same resources. This helps keep repository operations responsive even as the workload grows.

---

Adapt or Get Left Behind

AI coding agents are evolving faster than ever. They're changing how we write code, build software, and think about development itself. Tasks that once took hours can now be completed in minutes.

But the bigger lesson isn't just about writing code faster. It's about how the entire software development ecosystem needs to evolve alongside these tools.

GitHub's infrastructure redesign is a great example. As developers change how they work, the systems supporting them must change, too.

Either you evolve with time, or time leaves you behind.

Happy Coding :)