Thoughts on GitHub's Reliability Issues and a Possible Unbundling

My 4 Months in 2026 Already Beat All of 2025

Let me start with a personal data point. Here is my GitHub contribution graph for 2025:

3,650 contributions across the entire year.

And here is my graph for 2026, with only 4 months in:

3,686 contributions — already past the full 2025 total.

And I am just one developer. Multiply this by the millions of developers now coding alongside AI agents — each one pushing branches, opening PRs, and triggering Actions at a cadence that simply did not exist a year ago. The load on GitHub is not growing linearly. It is exponential. GitHub itself published an update on availability acknowledging the recent reliability issues and the exponential growth pressure on the platform — so this is not just a vibes-based observation from one heavy user, it is what GitHub is openly telling us.

On Defending GitHub

The frustration is real, and some people are voting with their repos. Mitchell Hashimoto — someone I am a big, big fan of — moved Ghostty off GitHub (writeup). When someone of his stature decides the tradeoff is no longer worth it, the unbundling is no longer just possible — it is starting at the edges.

To make my own bias clear:

If Mitchell ever ran GitHub, I would invest every penny I have in MSFT.

That said, I want to defend GitHub on one specific dimension: the infrastructure team.

I have been working on databases for over 15 years, and from the outside many of the recent stability issues smell like an overloaded database tier. I can comprehend the challenges GitHub is facing. GitHub is a MySQL shop. With Vitess, they shard MySQL both horizontally and vertically. But Vitess is a scaling layer on top of vanilla MySQL — it is not a natively distributed database like TiDB. That means a lot of manual effort to reshard, offload hot tenants, and switch storage engines mid-flight under live traffic.

This is not a knock on the team. The GitHub MySQL team is probably the most experienced MySQL operations team in the world. They open sourced gh-ost, which is now the de-facto tool for online schema migrations on large MySQL fleets. And honestly, I am glad they bet on MySQL in the first place — Postgres would likely have broken even harder under this write-heavy workload.

The point is: even the best operators eventually run into the physics of their architecture. Exponential write growth on a sharded-but-not-natively-distributed system is a hard place to be. So when I criticize some of GitHub below, please read it knowing I have a lot of respect for what the people keeping the lights on are up against.

The Possible Unbundling

The way I see it, GitHub is really four products bundled into one:

1. Code hosting (the git repo)
2. CI (GitHub Actions)
3. User interface (PRs, issues, code review, code search)
4. Social networking (profiles, stars, follows, the contribution graph)

Each of these is on a different trajectory, and that is what makes the unbundling conversation interesting.

Code Hosting

The underlying infrastructure was not built for agentic workloads — and honestly, I do not think Git itself was built for that either. When dozens of agents are simultaneously branching, committing, and pushing on behalf of a single human, the assumptions baked into Git (human-paced commits, human-paced reviews, monolithic refs) start to creak.

Companies like code.storage from Pierre are rethinking the storage layer for this new world. I think that is the more promising direction.

CI (GitHub Actions)

The biggest historical obstacle to GitHub Actions was writing the YAML. AI just solved that. As a result, Actions has effectively become a robust, mostly-free general-purpose workflow engine — not just for CI, but for cron jobs and arbitrary automation. Usage has exploded.

The nice escape hatch: Actions lets you swap in a self-hosted runner with a single line change. When I want a faster runner, I point it at Depot or Tenki Cloud. So even within "GitHub Actions," the compute layer is already unbundling.

User Interface

This is the piece that genuinely makes me mad.

It feels like whoever is in charge of the GitHub UI does not actually use GitHub day to day. The core developer surfaces — PR review, code navigation, GitHub Actions inspection, code search (less relevant now, but still) — have stagnated for years.

What makes me even angrier is the second-order damage. Because GitHub is so widely used, its interface has been canonized as the "golden standard." This has happened to me multiple times — at my previous company and at my current one. I question a design choice, and the answer comes back: "because that is how GitHub does it." Somehow GitHub's UI has polluted an entire generation of product thinking — not just about code review and collaboration, but about what DevTools should look like in general.

So I am genuinely glad to see companies like Graphite and Linear challenge this assumption and show that code review can look and feel fundamentally different.

Social Networking

This is the hardest piece to replicate. "Open source project" today is essentially synonymous with "GitHub project." The GitHub star is the social currency of our industry — it is exactly why this star-history.com site has accumulated the audience it has. Our own traffic has roughly doubled year-over-year, which tells me the appetite for understanding what is happening on the GitHub graph is only growing.

But there is a cost to owning the social graph. It is hard to balance social with pragmatics. The default github.com home feed is, frankly, mostly useless. I want to see my ongoing PR statuses, not events from another repo.

Closing Thoughts

Building a new GitHub for the agentic era is a worthy endeavor. OpenAI and Cursor (via Graphite) are both marching in that direction. pierre.co (the company behind code.storage) attempted it before pivoting to focus more narrowly on code.storage.

Usability and scale are only half the battle. Even if a challenger nails both — a delightful UX and infrastructure for agentic workloads — migrating the belongings, the stories, and all the social attachments accumulated on the platform over a decade is intractable. That gravity is what makes the bundle so durable — and why any unbundling will likely happen one layer at a time, not all at once.