Git used to wait for people. A developer edited a file, considered the change, committed it, and eventually pushed. Even the fastest team had a human pause between most writes. Coding agents remove much of that pause. They can checkpoint after nearly every action, work on thousands of branches at once, and trigger a wave of CI reads after each update.
That change is forcing GitHub to rebuild the machinery beneath the familiar git push. In its architecture briefing, GitHub says total Git activity rose from 218.2 billion events in September 2025 to 473.3 billion in August 2026. September brought 7.38 billion commits, more than five times the year-earlier total. Pushes climbed from 690 million to 3.35 billion per month.
The important story is not that agents type quickly. It is that a platform designed around bursty human work is becoming a write-heavy coordination system. Reads can be copied and cached. A push has to become durable, update a shared reference consistently, and be visible to the very next worker. The new bottleneck is the point where all of those independent changes have to agree.
Agentic coding turns source control from a place where people occasionally publish work into a continuously moving production system.
Why More Replicas Eventually Make Writes Slower
GitHub's current repository service is called Spokes. It keeps a full copy of each repository on the local disks of several file servers, five by default. Those local copies give Git operations fast access to native repository data. They also provide redundancy and let read traffic spread across multiple machines.
When a push changes a branch or tag, a three-phase commit protocol uses a quorum so that the web interface, API clients, and CI jobs see a consistent state. GitHub says this design serves roughly a billion repositories. It is not a failed architecture. It is an architecture whose two jobs have become tightly coupled.
The same replicas provide both durability and read capacity. Adding a replica can help absorb clones and fetches, but that replica also joins the write path. Every push has more durable copies to update, and completion can be limited by the slowest member of the set. Losing a replica removes read capacity; losing quorum stops writes.
current design
push -> replica A + replica B + replica C + replica D + replica E
durability, reads, and write agreement share the same hosts
new direction
push -> durable object storage
|-> cached compute workers for reads
|-> separate workers for maintenanceThat coupling matters most at the extreme end of the traffic curve. GitHub says its busiest repository handled roughly a billion requests in August. A fleet of agents compounds the problem because it creates sustained writes instead of one dramatic read spike. Each push can then fan out into thousands of fetches from builds, tests, scanners, and other automation. GitHub Actions alone ran 3.26 billion times in September, more than four times the year-earlier volume.
The Reference Is The Small Part That Must Agree
A Git push contains more than one kind of work. New commits, trees, and file contents arrive as immutable objects. The push also asks to move a reference, such as refs/heads/main, from one commit to another. Those jobs do not need identical coordination.
The reference update is the serial moment. Two writers cannot both move the same branch from the same old commit and pretend that each won. Trunk-based development, merge queues, and release branches concentrate traffic on a small number of shared references. GitHub says pull-request merges have grown to nearly four times their volume a year ago.
Storing objects, checking their connectivity, and scanning them for secrets are heavier tasks, but much of that work can proceed independently or in parallel. GitHub's redesign aims to shrink the critical path to the agreement that Git semantics actually require. The rest should not hold the acknowledgment hostage merely because it arrived in the same push.
This is a classic distributed-systems move: coordinate the smallest fact that needs consensus. It does not make consistency disappear. It draws a tighter box around it. That distinction becomes valuable when thousands of agents are producing valid, independent object data while only a few hot branch names remain contested.
Storage And Compute Stop Being The Same Machine
The larger architectural shift is to separate durable storage from the compute layer that answers Git requests. GitHub says authoritative repository data in the new design lives in Azure Blob Storage. Lightweight workers cache what they need to serve clones, fetches, and other reads.
Now read capacity can grow without adding another durable repository copy to every write. A release-day clone surge or a newly started agent fleet can receive more compute workers for the duration of the burst. When traffic falls, that capacity can go away. The durable layer keeps the source of truth underneath.
Failure recovery changes shape too. In the existing design, a lost host takes away capacity and one of the full copies that provides durability. Rebuilding it means reconstructing an entire repository replica. In the separated design, a lost compute worker is closer to a cold cache. A replacement can begin serving and fill its local cache from durable storage as requests arrive.
Repository maintenance also moves off the serving machines. Compaction and garbage collection are expensive, and every additional write creates more cleanup work. Separate workers can optimize repository data against the durable layer without competing directly with a live push or fetch for the same host.
None of this is free. Cache misses still have latency, a durable object store has different failure modes than local disks, and moving work out of the push path requires careful rules about what must finish before success is reported. GitHub has not presented the redesign as a finished public service level. It reports up to 35 times higher write throughput in internal benchmarks, which is an encouraging engineering result rather than a promise that every repository will suddenly push 35 times faster.
Human Controls Become More Important, Not Less
There is a second bottleneck hiding above storage: deciding which automated changes are allowed to land. Faster object ingestion cannot replace branch protection, required review, audit history, or a merge queue. It only gives those controls a stronger foundation.
GitHub explicitly says the new architecture must preserve existing workflows and keep people in control of their code. That is not ornamental language. An agent can produce a branch cheaply; an organization still needs to know who authorized its merge, which checks ran, and why a protected reference moved. At agent scale, governance is part of the data path.
This also explains why optimizing only clone speed would miss the architectural problem. Read replicas and caches help when many workers need the same commit. They do not settle concurrent updates to main, preserve an auditable reference history, or decide whether a change passed the required controls. Agentic development increases both the volume of immutable data and the pressure on the small mutable layer that gives a repository its shared story.
The Repository Is Becoming A Coordination Service
Git's object model is unusually well suited to parallel work. Most objects are immutable and addressed by their content, so identical data naturally converges and independent branches do not need to fight. The refs are where that parallel universe becomes a product: a team agrees on the commit called main, the tag called v2.0, or the head of a release branch.
For human-paced development, keeping complete local replicas close to the Git process gave GitHub speed, durability, and a straightforward serving model in one package. Agent-paced development changes the ratio. There are many more writers, more checkpoints, more CI fan-out, and more background maintenance, while the number of facts that require strict agreement remains comparatively small.
GitHub's answer is to split those responsibilities apart: durable storage for the repository's objects, elastic workers for serving them, separate maintenance, and narrow coordination around references. The command developers type does not need to change. The system receiving it does.
That is the useful signal beyond GitHub. Coding agents do not merely add another client to existing developer infrastructure. They change workload shape. Systems that were read-heavy can become write-heavy; occasional bursts can become continuous pressure; background chores can become foreground latency. The platforms that survive that transition will be the ones that identify the tiny piece that must stay serialized and let everything else move independently.
// Discussion
Comments
No comments yet. Start the thread.