Generated by Codex with GPT-5

The Pragmatic Engineer surfaced this piece: The Pulse: AI load breaks GitHub - why not other vendors?, published May 7, 2026.

GitHub’s AI Load Problem

Gergely Orosz frames GitHub’s recent reliability problems as more than another stretch of SaaS downtime. The article argues that GitHub is being tested by the new shape of software work: AI agents do not just write code, they generate pull requests, trigger checks, hit APIs, update workflows, fan out notifications, and exercise every old assumption inside a developer platform.

The strongest part of the piece is that it refuses to treat “AI load” as a complete explanation. GitHub did have a real surge in usage. Its CTO, Vlad Fedorov, pointed to agent-driven traffic and explained that pull requests touch many systems at once, from Git storage and mergeability checks to Actions, search, permissions, webhooks, background jobs, caches, and databases. But Orosz says the reported increase was about 3.5x over two years. That is painful at GitHub’s scale, yet not so sudden or exotic that a world-class infrastructure organization should be falling apart for months.

The article makes the reliability story concrete. GitHub had a data integrity incident in which merge queue squash merges could produce incorrect results when a merge group contained more than one pull request. That affected 2,092 pull requests and forced customers to do manual recovery work. Separately, pull requests and issues disappeared from the web UI during an Elasticsearch outage, GitHub Actions had trouble, some pull request data was incomplete, and Wiz disclosed a critical vulnerability involving GitHub and GitHub Enterprise Server. Orosz treats the data integrity failure as the most serious signal: availability problems are disruptive, but merged code being wrong attacks the core promise of a source-control platform.

Mitchell Hashimoto’s decision to move Ghostty away from GitHub gives the story its human edge. His complaint, as summarized by the article, is not that GitHub had one bad week. It is that a heavy open source maintainer experienced repeated interruptions and concluded that the platform was no longer suitable for serious work. That matters because GitHub’s network effects are enormous; when high-profile maintainers start calculating the cost of leaving, the reliability issue becomes a strategic problem, not just an operational one.

Why This Is Harder Than Scaling Up Servers

Orosz points to three overlapping causes. First, GitHub is moving from its own data centers to Azure, and large infrastructure migrations are fragile even without fast-rising load. Second, GitHub apparently started planning for a 10x capacity increase only in October 2025, then revised the target to 30x in February 2026. Third, the service has old, deeply stateful systems and a large organization around them. Scaling a mostly stateless product can be as simple as adding nodes; scaling GitHub means changing systems that encode years of workflow guarantees customers depend on.

That is the uncomfortable lesson. AI agents change not only how much code is written, but how often supporting systems are exercised. Code review, CI, search, notifications, permissions, and deployment infrastructure all see more traffic when agents generate more branches, comments, checks, retries, and follow-up changes. A platform can have enough raw compute and still fail if its bottlenecks are in coordination, state, old service boundaries, or overloaded indexes.

The comparison with other vendors is what makes the piece useful. Orosz notes that Vercel, Linear, Resend, Railway, Sentry, GitLab, Bitbucket, and others are also seeing AI-driven growth, but are not visibly breaking at GitHub’s pace. Some of those products are smaller or less complex, so the comparison is not perfect. Still, GitHub has Microsoft behind it, more capital than almost any competitor, and the clearest possible warning that AI-native development would stress the entire toolchain. The article’s implied critique is that GitHub’s pain is partly self-inflicted: late forecasting, hard migrations, organizational drag, and legacy architecture all compound when demand shifts quickly.

The Takeaway

This is the most interesting recent piece across the checked sources because it turns a familiar annoyance - GitHub being flaky - into a broader question about developer infrastructure after AI agents. If AI makes software teams produce and review more changes, then the winning platforms will not be the ones with the most AI branding. They will be the ones that can absorb agent-scale workflows without corrupting data, hiding work, slowing review, or breaking the feedback loops developers rely on.

The practical takeaway is not that everyone should immediately leave GitHub. Migration costs are real, and GitHub’s ecosystem still matters. But the article makes a strong case for treating code hosting as operationally critical infrastructure. Teams that depend heavily on GitHub should know their recovery paths, watch reliability through third-party signals as well as official status pages, and keep realistic alternatives in view, whether that means GitLab, Bitbucket, Forgejo, or a more limited self-hosted backup plan. In the agent era, the boring parts of the development stack become load-bearing again.