From Mexico, most of what I read about coding agents is about the model: which one writes better code, which one plans better. On October 6, GitHub published a post about the part underneath, the place every one of those agents eventually pushes to. It’s called “Building Git infrastructure for agent-scale development”, written by Brian Celenza, a principal software engineer who works on GitHub’s repository storage. The short version is in one line: “We’re rebuilding GitHub’s Git infrastructure to support them.” “Them” being repos where developers and agents work at the same time.
I don’t have any inside view of GitHub’s systems. Every number below is GitHub’s, and I can’t check any of them from here.
The numbers GitHub put on the table
GitHub says total Git activity on the platform went “from 218.2 billion events per month to 473.3 billion” between September 2025 and August 2026. In September alone, it says “developers and agents made 7.38 billion commits on GitHub, more than five times as many as a year earlier.” Pushes grew 4.9x year over year, from 0.69 billion to 3.35 billion a month. Pull request merges are at “nearly 4x” last year’s volume, and GitHub Actions ran 3.26 billion times in September. The busiest single repository saw “roughly a billion requests in August.”
One thing the post doesn’t do is split those numbers between people and agents. It credits the growth to “developers and agents” together, so I won’t pretend to know the ratio.
Why an agent hits Git differently than I do
This was the part that made me nod. When I work, I push a few times a day and I don’t care if a push takes an extra second. An agent is different. “An agent in a tight loop commits or checkpoints after nearly every action.” Its speed is capped by how fast one push finishes, so “latency that a human would never notice becomes the limiting factor.”
Then multiply it. Thousands of agents on their own branches in one repo all write at once. Merge queues and trunk-based work funnel everything onto a single ref. And every push sets off reads, because CI and code scanning “clone or fetch the same branch tip thousands of times per minute.” GitHub’s summary is blunt: “Reads are relatively easy to scale” but “Writes are way harder.” Each push has to be stored durably and visible to everyone before the next agent or CI job can build on it.
The trade-off that worked until now
Today every repository lives in a system GitHub calls Spokes (that link is GitHub’s 2017 post about it). Spokes keeps full copies of a repo on the local disks of several fileservers, “five by default,” and a push goes through a three-phase commit with a quorum so CI, the web UI, and the API all see the same state.
The catch, in GitHub’s words: “the mechanism we use for durability is the same one we use for scale.” Want more read capacity? Add another full copy. But every copy takes part in every write, so “adding replicas to absorb read load makes writes slower.” For most repos that’s fine. For the busiest ones it’s a ceiling, and “losing quorum stops writes entirely.”
What they’re changing
The plan has two big ideas. The first is “Minimize coordination.” The only part of a push that truly needs everyone to agree is the reference update itself. Storing the objects, checking connectivity, and secret scanning are the heavy parts, and GitHub says most of that can run in parallel with other writes. So the critical path of a push shrinks to the one small step that needs agreement. Heavy cleanup like compaction and garbage collection also moves off the machines that answer live Git requests.
The second is “Decouple storage from compute.” The authoritative copy of each repo will live in Azure Blob Storage, and reads get served by lightweight workers that cache data on top. If a worker dies, GitHub says it “is closer to a cache miss” than a rebuild, and workers can be added for a burst, like “a new agent fleet coming online,” then removed. In internal benchmarks, GitHub says the new design “has delivered up to 35 times higher write throughput.” That’s an internal number with no public benchmark behind it yet, and the post gives no rollout date. It says the next post in the series will go deeper.
The controls stay where they are
I was glad to see the post spend real space on what doesn’t change: branch protections and required reviews so “an unreviewed change never reaches the default branch,” audit logs for security teams, and the line I’d underline: “As agents take on more of the work, the people who own the code can still review, understand, and approve it.” Faster writes are only good news if the gates in front of main still hold.
The same afternoon, GitHub made stacked pull requests generally available. It’s a smaller item, but it points the same way: “A stack now enters and lands through the merge queue as a single merge group,” and the gh stack CLI extension “now supports Git worktrees.” Worktrees are how I’d give each agent its own checkout anyway.
What I take from it for my own repos
I’m not running thousands of agents against one codebase, and most people reading this aren’t either. But the shape of the problem shows up small, too. If my agent commits after every step, each of those is a push, and each push can kick off CI. Before I blame the platform for being slow, I’d check three things: how often my agents actually push, whether every checkpoint commit really needs a full pipeline run, and whether all of them land on main through one queue at the same time.
I also like that GitHub said the quiet part out loud. Agents don’t just change who writes the code. They change the load on the boring layer under it, and that layer has to keep the same reliability and review rules while it scales. The big claims here, the 35x and the growth figures, are GitHub’s own. I’ll be watching for the follow-up post to see how much of this reaches regular repos, and when.
Featured image: Belt Railway of Chicago Clearing Yard, Chicago, Illinois, November 2013, by Ken Lund, Wikimedia Commons, CC BY-SA 2.0. This image is a derivative, shared under the same license: a 1400×900 crop of the original upload, with a mild contrast lift, slight warm grade, and light grain.
.jpg){kind=link}