GitHub infrastructure strain from AI-generated activity

The 14x commit surge is not just a bigger pile of the same kind of work — it is a categorical shift in how GitHub is used. Kyle Daigle's disclosure that the platform now ingests 275 million commits per week, on pace for 14 billion in 2026 against just 1 billion in all of 2025, captures one face of the change. The sharper face is the fanout. Vlad Fedorov's own engineering note describes how a single PR ripples through Git storage, mergeability checks, branch protection, Actions, search, notifications, permissions, webhooks, APIs, background jobs, caches, and databases. When a human opens five PRs a week, that fanout is invisible. When a Copilot or Claude Code session opens fifty in an afternoon — and reruns checks each time it tweaks a comma — the same architecture is asked to absorb an order-of-magnitude more downstream events.

The pace is the load-bearing variable. Agents do not pause to read documentation, eat lunch, or context-switch between meetings. They hammer the API surface continuously, often across many repositories in parallel. Claude Code alone is reportedly responsible for ~2.6 million commits a week — roughly 4.5% of public commits — up from about 100,000 weekly in late September 2025. That is a 25x climb in a single tool's footprint in roughly six months. The platform was sized for human tempo and human curiosity. It is now being driven by what amounts to a fleet of always-on contributors that share none of those rate-limiting traits.

Inside GitHub, the response has been a public reordering of priorities that would have been unthinkable a year ago. In an April 28 post, VP of Engineering Vlad Fedorov wrote that the company's priorities are now "availability first, then capacity, then new features" — a sentence that, read carefully, deprioritizes the product roadmap behind keeping the lights on. His timeline tells the rest. In October 2025, GitHub began executing a 10x capacity plan. By February 2026 — after a month with 37 separate incidents — they concluded they needed to design for 30x. The March 2026 availability report disclosed an event in which github.com request failures peaked near 40% and 95% of workflow runs failed to start within five minutes.

The quiet implication is that GitHub is now in the kind of war-footing posture more familiar to hyperscale cloud teams than to a developer-tools company. Capacity is being rebuilt while traffic continues to grow. About 12.5% of GitHub traffic now runs from Azure Central US with a target of 50% by July 2026 — a major migration that, in normal conditions, would not be coincident with a redesign for 30x scale. Doing both at once is what "availability first" actually costs: features that were promised get pushed, and the company spends political capital it would rather have spent on Copilot pricing or new agent features. Microsoft's most strategic developer property is, for the moment, optimizing for not breaking.

Mitchell Hashimoto is not just any developer leaving a service. He is GitHub user 1299, an 18-year daily user, and the co-founder of HashiCorp — a company whose tooling helped define the modern devops stack. When he announces that Ghostty is leaving GitHub because "this is no longer a place for serious work if it just blocks you out for hours per day," and frames it as a love letter gone sour — "I love GitHub more than a person should love a thing, and I'm mad at it" — that is not a routine grievance post. It is a credibility marker for every maintainer who has been quietly running incident workdays in their head and deciding whether to act.

The community reception followed quickly. Programmer-leaning forums framed his exit as a watershed and a permission slip, with the dominant comment angle being that a coding-agent platform that cannot reliably serve a Git endpoint has lost the basic plot. Threads on the Linux side were already comparing migration paths to Codeberg, Forgejo, and GitLab in concrete terms — bug tracker import, CI parity, mirror policy — rather than as a venting exercise. There were contrarian voices arguing self-hosted projects tend to drift offline within a few years, but the structural read was that one prominent migration legitimizes a thousand quieter ones. For GitHub, the strategic risk is less about losing Ghostty's traffic and more about the precedent. Lock-in on a developer platform is partly inertia, and Hashimoto just lowered the activation energy.

The most under-appreciated structural shift in this story is not the outages — it is what's happening to human attention inside teams. Reports from review-tooling vendor CodeRabbit and analytics shop Faros AI describe PR volume rising roughly 98% while review time per PR rose about 91% across a sample of 10,000 developers. AI accelerated the generation step by an order of magnitude; review did not get faster. The result is a queue that does not clear. CodeRabbit's own VP of AI, David Loker, frames the quality side bluntly: "We're producing tech debt using AI at a clip that I can't even fathom. It's probably three to four times what it was previously." Other reporting cites figures like 1-in-10 AI-authored PRs being legitimate and AI-written code carrying ~1.7x more issues than human-written code.

This is what "the bottleneck has shifted from writing to absorbing" means in practice. Reviewers are now the rate limiter on shipping, and reviewers are not parallelizable the way agents are. The infrastructure problem — GitHub being slow — is partially a downstream symptom: tens of millions of low-yield PRs run CI, hit branch protection, fan out into webhooks, get rebased after a stale review, and run CI again. A platform tuned for high-signal human authorship is paying full freight to process noise. Until reviewing scales — through AI review tools, gating, or an explicit cost on agent-initiated PRs — the duty cycle of the entire ecosystem is set by how fast humans can read.

There is a quieter contrarian read of this whole episode: the unit economics of "unlimited" agent activity were never going to hold. GitHub priced Actions minutes, API quotas, and free-tier allowances around occasional CI runs and a handful of human commits per developer per day. Agents collapsed those assumptions. The discussion now moving into the open — including in r/technology threads about Microsoft shifting Copilot toward metered AI billing, where the top comment dryly asks when it becomes cheaper to just pay humans instead — is whether a usage-based pricing flip is sustainable or merely a way to translate compute pain into customer pain.

The mechanism is straightforward. Each agent-driven PR consumes Git storage writes, runs Actions minutes, hits search and notifications, and produces audit log entries. At human pace, those costs were rounding errors covered by enterprise seat fees. At 14 billion commits a year, with Claude Code alone authoring 4.5% of public commits, they are first-order costs. The tension is that GitHub's customers are increasingly not the developers running the agent — they are the platforms providing the agent (Anthropic, OpenAI, Microsoft itself) whose business model depends on cheap, fast Git operations. Watch for the arbitrage: if metered billing prices rise faster than agent productivity gains, the business case for agentic coding on GitHub specifically — versus a self-hosted Forgejo behind a private CI runner — narrows. Hashimoto's exit is the cultural canary; the next year of pricing pages will be the financial one.