GitHub Is Rebuilding Git Infrastructure for AI Agents: Why Pushes, Merges, and CI Are Becoming Bottlenecks

AI coding agents do not use Git quite like human developers do.

A person might work for an hour, make a few commits, open a pull request, and wait for CI. An agent can edit, checkpoint, push, run tests, inspect feedback, and push again in a much tighter loop. Multiply that behavior across many agents working in one repository, and familiar Git operations start to become an infrastructure problem.

That is why GitHub says it is rebuilding parts of its Git infrastructure for what it calls agent-scale development. The change is not about replacing Git or asking developers to change their workflows. It is about making repository reads and writes handle much higher levels of concurrent activity without sacrificing reliability or the controls teams depend on. [197]

The numbers behind the redesign

GitHub’s engineering team described a sharp rise in activity:

• Monthly Git activity grew from 218.2 billion events in September 2025 to 473.3 billion in August 2026.
• Developers and agents made 7.38 billion commits on GitHub in September 2026, more than five times the number a year earlier.
• Pushes grew 4.9 times year over year, reaching 3.35 billion per month.
• GitHub Actions ran 3.26 billion times in September, more than four times the volume a year earlier.
• Pull-request merges also grew to nearly four times their volume from a year earlier. [197]

These are GitHub’s reported platform figures, not an independent measurement of every Git host. But they make the pressure clear: if each agent creates more commits and triggers more tests, infrastructure must deal with more writes and a much larger wave of reads.

Why agent workflows change Git’s workload

A push is more than uploading a commit.

The platform must store the objects, update references consistently, make the new state visible to clients, and support the tools that depend on it. Those tools may include CI, code scanning, repository browsing, pull-request views, and integrations.

One push can cause many downstream reads. A CI system and code-scanning jobs may fetch the same branch tip repeatedly. If agents push often, that read fan-out grows alongside write volume.

There are three related pressure points:

1. Push latency enters the agent loop

When an agent commits after a small step, push latency can directly slow its next step. A pause that is barely noticeable to a human can become a repeated wait in a tight automated loop.

If an agent must push, wait for the update to become visible, run tests, inspect results, and push again, the time to complete useful work depends partly on how quickly the platform accepts and publishes each update.

2. Many writes converge on shared repository state

Agents can work on separate branches, but merges often converge on a shared branch or reference. Release branches and merge queues can also concentrate updates.

The system needs to coordinate changes where correctness requires agreement. If too much work is forced through one coordinated path, that path limits throughput.

3. One write can create many reads

A push may trigger several CI jobs, code scans, previews, and other automation. That means a write can produce a large burst of repository reads.

Making clones faster helps, but it does not solve the entire problem. The platform also needs to handle writes without making every read-serving replica part of the write path.

The trade-off in the existing architecture

GitHub says its existing architecture, called Spokes, stores full repository copies on several fileservers. Five copies are used by default. Local copies provide low-latency access to repository data, redundancy, and the ability to distribute reads.

When a push changes a reference, the architecture uses a three-phase commit protocol and a quorum to ensure that clients and services see a consistent repository state. This approach has supported GitHub at very large scale.

The trade-off is that durability and read capacity are closely linked. According to GitHub, adding a replica to increase read capacity also adds work to writes, because replicas participate in the write path. The push can be limited by the slowest replica involved. If enough replicas are unavailable to lose quorum, writes stop until the system can safely agree on the repository’s new state. [197]

This is a familiar distributed-systems tension:

More replicas can improve read capacity and redundancy.
But if every replica participates in every write,
more replicas can also add coordination cost to writes.

For typical workloads, that trade-off can be reasonable. For a repository receiving an unusually high volume of concurrent reads and writes, it can become a scaling ceiling.

The design direction: separate storage from compute

GitHub’s redesign aims to separate durable repository storage from the compute workers that handle Git requests.

In the architecture described by GitHub:

• The authoritative repository data lives in Azure Blob Storage.
• Lightweight compute workers serve reads and writes, using caches for frequently accessed data.
• Reads can scale by adding compute capacity without adding another full durable repository copy to every write.
• Repository maintenance, such as compaction and garbage collection, moves to separate workers instead of competing with live Git requests. [197]

This changes the relationship between capacity and durability.

If more CI jobs need to fetch a branch, GitHub can add read-serving capacity without necessarily adding another durable copy that participates in each push. If a compute worker fails, GitHub describes recovery as closer to replacing a cache-serving worker than rebuilding a full repository copy.

The design also aims to move heavy work away from the critical path of a push.

Some parts of a push require coordination, especially updating a reference consistently. Other work, such as object validation and secret scanning, may be performed independently or in parallel. GitHub says the goal is to coordinate only where agreement is required and let other work proceed without unnecessarily delaying the push acknowledgment. [197]

The details matter: this is not a claim that GitHub skips validation or secret scanning. The stated design goal is to avoid making all such work block the narrow part of the operation that needs coordinated agreement.

Why moving maintenance matters

Repositories accumulate objects and data structures that need maintenance over time. Compaction and garbage collection help keep repository operations fast, but they consume resources.

If this maintenance runs on the same machines that answer live Git requests, it can compete with pushes and fetches. Under heavy load, background work can become visible as user-facing latency.

Moving maintenance onto separate workers aims to keep that cost away from the live serving path. In practical terms, repository cleanup can continue without using the same capacity needed to answer a burst of clones or pushes.

This principle is not unique to Git hosting. Many systems isolate background compaction, indexing, cleanup, and repair work because those operations can otherwise compete with customer requests.

What GitHub says it has measured

GitHub reports that internal benchmarks of its new architecture delivered up to 35 times higher write throughput, while read capacity could scale independently. [197]

That figure needs context:

• It is a result GitHub reports from internal benchmarks.
• It does not mean every GitHub repository will become 35 times faster.
• It is not a promise that an individual git push will have one thirty-fifth of its current latency.
• It does not tell us which workload, repository size, concurrency level, or baseline produced the maximum result.
• GitHub says the work is being built while the platform continues operating, without asking users to change their workflows. [197]

For developers, the headline number is less useful than the architectural direction: GitHub wants read capacity, write throughput, durability, and maintenance to interfere with each other less.

What this means for developers and platform teams

For most teams, there is no immediate Git command or repository setting to change. GitHub says its redesign is intended to preserve familiar workflows and controls while changing the infrastructure underneath them. [197]

The broader lessons are still useful for teams running their own Git and CI platforms:

• Measure push latency and CI queue time separately. A slow build queue is not necessarily a slow Git server.
• Look at downstream work per push. One commit can trigger many builds, scans, previews, and integration jobs.
• Avoid unnecessary push loops. Agents and automation should checkpoint usefully, not create commits that do not add reviewable progress.
• Use concurrency controls for expensive CI jobs. Duplicated builds of the same branch can multiply read and compute load.
• Keep merge coordination understandable. Shared branches and merge queues may become contention points when many workers update them at once.
• Preserve review and branch protections. Faster writes do not replace the governance needed to decide what reaches a protected branch.

Agent-scale infrastructure does not make repository policy less important. In a world where code changes arrive faster, review boundaries, branch protections, audit logs, and clear ownership become more important.

The bigger engineering lesson

The key challenge is not simply that AI agents create more commits. It is that they can create more concurrent work around each commit: pushes, fetches, CI runs, scans, merge attempts, and repository maintenance.

GitHub’s response is to reduce coupling:

• Store durable data separately from request-serving compute.
• Scale reads without making every read replica part of every write.
• Coordinate only operations that require agreement.
• Move heavy maintenance away from live requests.
• Add compute capacity when workload rises, then reduce it when the burst passes.

These principles apply to databases, build systems, artifact stores, and other developer infrastructure—not just Git hosting.

The practical takeaway is that AI agents do not remove the bottlenecks in software delivery. They can expose bottlenecks that human-paced workflows allowed systems to hide. GitHub is redesigning its foundations so repository infrastructure can handle that higher concurrency while keeping familiar developer workflows intact. [197]