Picture your Git server on a normal Tuesday. A few hundred engineers push a few times an hour, CI clones on each push, and everyone goes home. Now give each of those engineers three AI coding agents that commit after almost every step. That is the AI coding agents Git scaling problem GitHub is now rebuilding its storage to handle, and the same math applies to the CI, monorepo and review setup you run yourself.
GitHub said developers and agents made 7.38 billion commits in September 2026, more than five times the count a year earlier. Its fix is to split storage from compute and only coordinate on branch pointer updates. If you run self-hosted Git, CI runners or artifact stores, expect the same pressure, and start measuring push latency, clone load and review queues now.
What did GitHub actually change?
Principal engineer Brian Celenza laid out the numbers in a GitHub engineering blog post published on 6 October. Pushes grew 4.9 times year over year, from 0.69 billion to 3.35 billion a month. Total Git activity went from 218.2 billion events a month in September 2025 to 473.3 billion in August 2026. GitHub Actions ran 3.26 billion times in September.
The old design, called Spokes, keeps five copies of each repository by default and makes every copy take part in every write. That is fine for reads. It is bad for writes, because a push is only as quick as the slowest replica, and adding copies to absorb reads makes writes slower.
The new design moves the authoritative data to Azure Blob Storage, puts lightweight caching read workers in front of it, and shifts compaction and garbage collection to separate background workers. Only reference updates still need agreement across the system. GitHub said internal benchmarks show up to 35 times higher write throughput. It has not given a rollout date, and it said customers will not need to change how they work.
Why does agent commit volume hurt so much?
Celenza made a point that is easy to skip past. An agent working in a tight loop commits or checkpoints after nearly every action, and it waits for each push before moving on. Latency a person would never notice becomes the thing that sets the agent's pace.
Humans batch their work. Agents do not.
GitHub also noted that CI and code scanning fetch the same branch tip thousands of times a minute. Your setup is smaller, but the shape is the same: one busy branch, many clients pulling it, and a server that was sized for people.
Where will it break in your own stack?
Most teams will not hit Git storage limits first. They will hit everything wired to Git events.
CI on every push. If each agent checkpoint triggers a full pipeline, your runner bill and queue time grow with agent count, not team size. Move heavy jobs to pull request events and run only fast checks per push.
Monorepo trunk contention. Many agents merging to one trunk means more rejected pushes and rebase retries. A merge queue helps. So does keeping agents on short-lived branches that squash before they land.
Clone storms. Fresh runners doing full clones of a big monorepo is wasteful even at human pace. Use shallow or partial clones, a local mirror or cache, and check that your artifact repository can take the extra fetch load.
Server housekeeping. If you run GitLab, Gitea or Bitbucket Data Center yourself, repack and garbage collection jobs will run more often on hot repositories. Check when they run and what they block.
Who reviews all of this?
This is the part no storage redesign fixes. Faster pushes simply move the bottleneck to human review, and agent commits build up verification debt faster than any team can hire reviewers.
He is right. GitHub can make writes 35 times faster. Your senior engineers cannot read 35 times faster.
A few rules are worth setting now. Squash agent checkpoints before a pull request opens, so reviewers see one change with a clear purpose instead of 80 tiny commits. Ask agent changes to arrive with evidence of what ran: tests, scans and the commands used. Keep branch protection and required reviews on for protected branches, and do not open a side door for bots because they are noisy. Track review wait time and pull requests per reviewer the same way you track build time.
What should platform teams measure first?
Push latency at the 95th and 99th percentile. Clone and fetch counts per repository per hour. CI minutes triggered per merged pull request. Time from pull request open to first review. If any of those are climbing faster than headcount, agents are already doing the work, and your infrastructure was sized for the old math.
GitHub had to rebuild because its own numbers grew five times in a year. Yours will not move that fast, but they will move, and it is cheaper to find the weak point on a dashboard than during an outage.
