Code Got Cheap. Trust Didn't.

GitHub just told us where the bottleneck went

In September 2026, GitHub took 7.4 billion commits. That's five times what it saw a year earlier. The cause wasn't a hiring boom. It was developers turning AI agents loose to write code.

GitHub wasn't ready. Outages ran from February through August, and by one reconstruction of its status page, 90-day availability bottomed out around 84% in May. For a platform the world's software supply chain runs through, that's not a blip.

The fix GitHub announced at Universe this week: four million more CPU cores, 160 petabytes of fast storage, a re-architecture that splits compute from storage, and a migration to multi-region Azure. In other words, it's rebuilding the plumbing because the volume of code changed shape faster than anyone planned for.

Writing code stopped being the hard part

For 40 years, the constraint in software was how fast people could type working code. Every process we built (sprint planning, headcount models, outsourcing) assumed that.

That assumption is gone. An agent will produce a pull request in minutes and another fifty before lunch. Code is now cheap and abundant. Everything downstream of it is not.

GitHub's numbers make the point bluntly. Five times the commits didn't mean five times the value. It meant five times the load on the systems that store, build, test and ship that code, and those systems fell over.

Where the need moved

The demand didn't disappear. It shifted to the work AI doesn't do well, or does too fast for anyone to check.

Review. Someone still has to decide whether a change should merge. Reviewer capacity is now the real throttle, and most teams haven't budgeted for it.

Verification. Tests, builds and CI pipelines are getting hammered. GitHub Actions was among the services that kept going down this year.

Architecture. Agents are good at the next function. They're bad at knowing whether the system should exist in that shape at all.

Supply chain. More code pulls in more dependencies, faster, with less human eyeballing each one.

Resilience. If your delivery pipeline depends on one hosted platform running at 84%, that's a business continuity problem, not a developer annoyance.

The skill that matters now isn't writing code. It's judgment about code: what to keep, what to reject, and what will break in production.

The security tell is in GitHub's own product list

Look at what else GitHub shipped this week. AI Scans, to catch vulnerabilities in pull requests and in code that's already merged. Reachability analysis, so teams can focus on flaws that are actually exploitable. A package firewall that checks policy before npm packages get pulled in.

Those aren't coding tools. They're triage tools. GitHub is building them because the volume of unreviewed code now outruns the humans who used to catch problems by reading it.

I've worked 600+ incidents. The pattern is consistent: breaches rarely start with something nobody could have seen. They start with something nobody had time to look at. AI just multiplied the amount of stuff nobody has time to look at.

There's an irony here too. The answer to too much AI-written code is more AI checking it. That can work. But it means your assurance now depends on one model grading another model's homework, and somebody in your organization should own that risk on purpose.

What leaders should do now

1. Stop measuring output. Lines of code, PRs merged and commit counts are now vanity metrics. Measure defects escaped, time to detect, and change failure rate.

2. Fund review like it's production. If AI tripled your code output and your reviewer headcount stayed flat, you've tripled your unreviewed attack surface.

3. Gate dependencies. Put policy in front of package pulls. Agents will happily add a library nobody vetted.

4. Plan for your platform going down. Ask what happens to releases, hotfixes and incident response if your code host is unavailable for a day. Have an answer before you need it.

5. Hire for judgment. The developers worth keeping are the ones who can say no to a plausible-looking change and explain why.

6. Make someone own the AI-checks-AI risk. Name it, scope it, and put it on the risk register.

The bottom line

AI didn't reduce the need for engineering. It moved it. The scarce resource used to be people who could write code. Now it's people who can tell good code from bad, systems that can absorb the volume, and controls that hold when nobody's reading every line.

Sources

GitHub powering up four million extra cores to stop its service going down, The Register, Oct 28, 2026

GitHub is spending four million cores learning that lesson. Most organizations won't have that budget. They'll need to learn it with better process instead.