GitHub announced on October 6, 2026, in an official engineering blog post, that it is rebuilding the Git infrastructure behind the world's code hosting — for a direct reason: who writes the code has changed. Over the past year, commits, pushes, and merges produced by agents and developers on GitHub have multiplied, and the storage architecture designed for human pace has hit the write bottleneck first.
Start with the numbers: pushes reach 3.35 billion a month
The scale shift GitHub reports is steep. In August 2026, Git events on the platform reached 473.3 billion, more than double the year before; in September 2026, commits reached 7.38 billion, over five times the prior year. Pushes grew from 0.69 billion to 3.35 billion per month, up 4.9x year over year; pull request merges grew to nearly four times their year-ago volume; and GitHub Actions ran 3.26 billion times in September, also more than four times higher.
The way agents work amplifies every write. Thousands of agents working in parallel on separate branches of one repository produce a sustained write rate that converges on a single point — the trunk: merges contend on one reference, and trunk-based development, release trains, and merge queues funnel all that work onto a single ref that has to absorb every merge. Each push also fans out into thousands of reads, as CI and code scanning clone or fetch the same branch tip thousands of times per minute.
Reads scale easily, writes do not: the old architecture's coupling
GitHub's current storage layer, Spokes, keeps a full copy of every repository on the local disks of several fileservers — five by default — and uses a three-phase commit protocol with a quorum so the web UI, the API, and CI all see a consistent state when a push updates a reference. That pairing serves a billion repositories today.
The problem is that durability and scale are the same mechanism: the on-disk copies are both the source of truth and the source of read capacity. Adding read capacity means adding another durable replica, and every replica participates in every write, so a push is only as fast as its slowest replica. Adding replicas to absorb reads makes writes slower, losing a replica cuts read capacity, and losing quorum stops writes entirely. For most repositories the tradeoff works; at the highest activity levels, it becomes a ceiling.
The rebuild's direction: separate durability from scale
GitHub's new architecture separates durability from scale while holding three lines: workflows stay the same — branching, review, merge, and history run on the new infrastructure exactly as teams trust them today, with no change in user habits; reliability comes first, with every tradeoff measured against it; and people stay in control — branch protections, required reviews, audit logs, and repository visibility are preserved, so no matter how much agents do, code is still reviewed and approved by its owners. On the engineering side, the emphasis is on minimizing coordination: a repository receiving many pushes must accept and publish updates quickly rather than wait for global agreement at every step. The whole rebuild happens while the platform keeps running — there is no maintenance window in which the world's code stops moving.
The significance reaches beyond one company. Once agent output is counted in billions of commits, the bottleneck shifts from model capability to infrastructure: repositories, review, and CI, all built for human pace, must be rebuilt for machine pace. This site previously covered GitHub's ReviewBench evaluation, which tests agent-written code against 219 real pull requests — that asks whether the code agents write is trustworthy. This rebuild answers the other half: whether the platform itself can keep up with the speed at which agents write it. For teams leaning heavily on coding agents, write throughput, merge queues, and audit capability at code platforms will be worth watching as closely as the models over the next two years.
