For most of Git’s history, a commit marked a decision. A developer finished a change, checked it, and pushed. Hosting platforms were built around that rhythm. AI coding agents don’t work that way.
“An agent in a tight loop commits or checkpoints after nearly every action,” GitHub engineer Brian Celenza wrote in a GitHub blog post explaining why the company is rebuilding the Git infrastructure behind its platform.
The numbers show how fast the load has shifted. GitHub recorded 7.38 billion commits in September 2026, more than five times the total a year earlier. Monthly Git activity climbed from 218.2 billion events in September 2025 to 473.3 billion in August 2026. Pushes grew 4.9x year over year, from 0.69 billion to 3.35 billion per month. Pull request merges are up nearly 4x. GitHub Actions ran 3.26 billion times in September, also 4x the prior year. The busiest single repository handled roughly 1 billion requests in August.
Nobody planned capacity for curves like these. GitHub ties the surge to agentic development, where coding agents open branches, push changes, and trigger pipelines without a person at the keyboard. It also exposes a design choice that made sense when humans did most of the pushing.
GitHub’s current storage system, Spokes, keeps five full copies of each repository on local file servers by default. A three-phase commit protocol keeps those copies consistent. That delivers strong durability, but it ties reads and writes together. “Every replica participates in every write, so a push is only as fast as the slowest replica in its set,” Celenza wrote. The catch follows directly: “Adding replicas to absorb read load makes writes slower.”
Agents push on both sides of that tradeoff at once. Thousands of concurrent agents create sustained write pressure. Teams using trunk-based development funnel all those merges onto a single reference. Each push then fans out into thousands of reads as CI pipelines clone the repo and code scanning kicks in. Background maintenance, such as compaction and garbage collection, piles up as volume grows. And when an agent’s loop waits on push latency, the agent’s speed is capped by the infrastructure, not the model.
GitHub’s answer is to stop coordinating work that doesn’t need it. In the new design, only reference updates, the moment a branch pointer moves, require agreement across the system. Object storage, connectivity checks, and secret scanning run independently. Maintenance jobs move off the serving path to dedicated background workers.
The bigger change is separating storage from compute. “Authoritative repository data lives in Azure Blob Storage, which already provides durability and replication at Azure scale,” Celenza wrote. Lightweight read workers sit in front of that storage and cache what requests need. Read capacity can grow without adding durable copies, so scaling reads no longer slows writes. If a compute worker fails, it’s a cache miss, not a durability event. “Compute workers can be added or removed as traffic changes instead of provisioning for peak load in advance,” he added.
Early results are strong. “In internal benchmarks, it has delivered up to 35 times higher write throughput,” the post said. GitHub didn’t share a rollout timeline or say whether customers will need to change anything. A follow-up post will cover the full architecture.
GitHub framed the work around three principles: keep familiar workflows like branching, review, merge, and history unchanged; put reliability first; and keep people in control. Branch protections, required reviews, audit logs, and repository visibility all stay in place.
That’s where the next constraint shows up. “GitHub is rebuilding its Git infrastructure because agents commit at machine speed, and the existing architecture assumed a person pushing a finished change. Faster pushes move the bottleneck to review, where branch protections and required reviews still run at human speed,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group.
“Agent commits build verification debt faster than teams can hire reviewers to clear it. Engineering leaders should require agent changes to carry evidence of what ran and why before they reach a protected branch,” Ashley added.
For DevOps teams, the lesson goes beyond GitHub. Plenty of internal systems were sized for a human cadence: self-hosted Git servers, artifact repositories, CI runners, and the pipelines that clone code on every push. If one agent can generate dozens of commits in the time a developer makes one, every downstream system feels it. Teams should find out now where push latency, clone storms, and single-branch contention would show up first in their own environments. Better to answer that during planning than during an outage.
There’s a process question, too. When commits are cheap and constant, a single commit stops being a meaningful unit of review. Teams may need to rethink how they squash agent checkpoints, how they gate merges to trunk, and how much CI they run per push versus per pull request. Running a full pipeline on every agent checkpoint will get expensive fast.
GitHub is betting that agent-driven development is the new baseline, not a spike. The commit data backs that up. As Celenza put it, “Engineering for that scale raises the floor for everyone.”
The tools developers use every day assumed people push code at human speed. That assumption no longer holds. GitHub is rebuilding for it. Most other organizations will need to take a hard look at their pipelines and review processes next.