Three weeks ago, Mitchell Hashimoto — GitHub user #1299, co-founder of HashiCorp, the person who probably owes more of his career to GitHub than almost any other open source figure — announced he was moving Ghostty off the platform.
It wasn’t an impulsive decision. He spent a month keeping a journal, marking with an “X” each day that a GitHub outage blocked his ability to work. Almost every day had an X.
“This is no longer a place for serious work if it just blocks you out for hours per day, every day”, he wrote. And he was careful to clarify: the problem isn’t Git. The problem is the infrastructure built around it — issues, PRs, Actions.
That distinction matters. And it points to something bigger than an availability complaint.
The structural problem nobody was talking about
GitHub’s degradation isn’t random. A massive flow of coding agents is pushing the platform to its limit — flooding it with pull requests at a scale and cadence the system was never designed for.
Git was built for humans. Humans commit when they finish something. They open PRs with intention, review them, close them. There’s a natural throttle built into the pace of human work. Agents don’t have that throttle. They commit continuously. They open PRs in parallel. They push at machine speed, in volume, without stopping.
The infrastructure around Git — issue trackers, CI runners, PR queues — was designed with human throughput as an implicit baseline. Nobody architected for 50 agent-generated PRs simultaneously on the same repository. And now they’re arriving.
This is a systems design problem masquerading as a reliability problem. GitHub can patch servers and add capacity, but the fundamental incompatibility between a version control model built for human pace and agent-speed commit rates doesn’t get solved by throwing hardware at it.
Why Jujutsu is the serious candidate to watch
There are several alternatives to Git getting attention right now. But the one worth watching is Jujutsu — known as jj on the command line.
Jujutsu is an open source version control system written in Rust, created by Martin von Zweigbergk at Google. It has over 27,000 GitHub stars and is used internally at Google — making it the most production-validated Git-compatible alternative available in 2026.
The keyword is compatible. jj doesn’t ask you to abandon Git. It’s a Git-compatible VCS designed to simplify everyday tasks and reduce the risk of costly errors — not a Git replacement but an alternative interface over existing Git repositories, allowing you to adopt it incrementally without breaking current workflows.
But jj’s design philosophy is what makes it genuinely interesting for the agent era.
Git revolves around commits. jj revolves around changesets — it treats work as mutable by default. There’s no dirty state to manage, no stash-first workflow to switch context. Everything lives in the same model. Your working copy is already always a changeset.
This has profound implications for agent-generated code. Agents don’t think in human commit rhythms. They produce continuous change. A VCS that treats the working copy as a permanent, tracked state — rather than an unsaved draft — adapts better to agent-speed workflows than anything Git offers today.
And then there’s the operation log: jj records repository operations, not just commits. If something goes wrong with a split, a rebase, or a rewrite, you can revert the entire repository to a previous state. For teams supervising agents — where you genuinely don’t know what the agent just did to your repo — this is less a nice-to-have and more a requirement.
jj’s operation log captures the complete repository state at every point. It’s more like Time Machine for your repo than anything Git offers natively.
What this means for technical leaders
I want to be clear about what I’m not saying. I’m not saying GitHub is going to disappear, or that you should migrate your entire organization to jj tomorrow.
What I am saying is that Hashimoto’s story is a signal, not an isolated incident. When a developer with 18 years of track record and the credential of being user #1299 leaves GitHub citing daily workflow blocks, you pay attention. Not for the drama, but for what it reveals about the underlying architecture.
The tools our teams rely on were built for human-pace development. The world of development changed. Agents now commit code. The infrastructure didn’t keep up.
jj is designed to make parallel development easy — an excellent option for modern development styles where you have AI generating code, comparing variations, and constantly experimenting.
That’s not marketing copy. It’s a description of what every team running coding agents is actually doing.
The teams that will have an advantage over the next 18 months aren’t the ones with the best models. They’re the ones who thought seriously about their version control infrastructure. Today, most haven’t.
Where to start
jj installs alongside your existing Git setup. Since jj writes standard Git commits, reverting to pure Git at any point requires no migration effort. It’s a very low-cost experiment for a potentially high-value infrastructure improvement.
The repo: github.com/jj-vcs/jj