The next GitHub is not worth winning

GitHub experienced 17 separate incidents between 1 and 18 August, including a nine-hour degradation of GitHub Actions on 6 August that caused 71% of workflow runs to fail, and a worldwide outage on 17 August with roughly 20% error rates on the web interface and API. The company's own Octoverse report describes the flood of AI-generated contributions as 'a denial-of-service attack on human attention', while SpaceX closed its $60 billion acquisition of Cursor, the largest startup acquisition on record.

On 6 August, GitHub Actions was degraded for nine hours https://www.githubstatus.com/incidents/qcvjkzcs7j74 . At peak, 71% of workflow runs failed outright on infrastructure errors, and three quarters of the ones that survived were delayed by more than five minutes. On 11 August, the GraphQL API spent two hours timing out https://www.githubstatus.com/incidents/vm1w8zq95wkt . On 17 August, the whole thing went down worldwide https://www.githubstatus.com/incidents/zkxwbgr0cnmx : roughly 20% error rates across the web interface and the API, roughly 50% on archive and raw content downloads, with Actions, Webhooks, Issues, Pull Requests and Copilot all failing together. In between those dates, SpaceX closed its $60 billion acquisition of Cursor https://www.cnbc.com/2026/06/16/spacex-spcx-cursor-acquisition-ipo.html , the largest startup acquisition on record. And on the 19th, Cursor published a long, genuinely excellent piece about how they store git at scale https://cursor.com/blog/git-at-any-scale . I wrote in April that GitHub’s problem is that it became the thing everything else assumes https://davidpoblador.com/blog/despite-everything-a-small-praise-of-github.html . I still think the diagnosis was right. I want to revise the conclusion. First, the part that deserves saying again GitHub lowered the barrier to collaboration for an entire industry. It standardised how we work: the fork, the pull request, the review, the merge. It ran critical infrastructure for over a decade, quietly expanded from git hosting into CI, compute, package distribution and security scanning, and gave most of it away for free to anyone who asked. Nothing below is “GitHub is bad at this”. The problem I want to talk about is genuinely hard, and the people working on it are good at it. What actually broke Two things, and only one of them is about scale. The first is coupling. Look at what fails together on a bad day: Actions, Webhooks, Issues, Pull Requests, the API, Copilot. That is not six independent products having a coincidence. That is one system with shared fate, and it is the direct cost of the ecosystem being as rich as it is. The same deep integration that makes Actions worth using is what makes Actions fail when the API does. You cannot have the first without buying some of the second. You can watch this happen in public. Between 1 and 18 August, GitHub’s own status history https://www.githubstatus.com/history records seventeen separate incidents, two of them rated critical. Not one bad week. A cadence. The second is that the workload changed shape. GitHub’s own Octoverse numbers https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/ : 630 million repositories, 230 new ones created every minute, 43.2 million pull requests merged per month and rising 23% a year, close to a billion commits pushed in 2025, up 25%. Not growth in the abstract. Growth of a quarter, every year, on a system where a bad deploy takes out a fifth of the developers on earth. And the composition changed too, not just the volume. GitHub described the flood of high-volume, low-quality AI-generated contributions as “a denial-of-service attack on human attention” . Those are their words, in their own report. When the platform’s own analysis of its ecosystem reaches for that metaphor, something has moved. So: a very hard problem, growing 25% a year, run by people who are good at it, in an architecture where the parts share fate because that is what made them valuable. That is the honest description. It is not a story about incompetence, and I do not think the fix is a better-run GitHub. Everyone is trying to buy their way past it The money agrees that something has changed, and it is moving in one direction. Cursor, now inside SpaceX, published their architecture https://cursor.com/blog/git-at-any-scale . It is worth reading in full. Their account of the history is the interesting part: GitHub tried NFS, which was “slow, and it was buggy” because git’s packfiles produce random access patterns that networked filesystems punish. They tried block-level replication, which was “terrible to operate day to day”. In 2013 they built Spokes https://github.blog/news-insights/product-news/introducing-dgit/ , three replicas per repository kept in sync with a three-phase commit, and it held for a decade. Then Cursor says what stopped it being enough: modern workloads need hundreds of replicas, and millions of tiny agent-created repositories. Their answer, Continuity, is impressive engineering. Object storage as the source of truth, local NVMe as a warm cache, a write-ahead log persisted before any push is acknowledged, rendezvous hashing so any server can act as primary. 120 pushes per second on standard object storage, over 300 on the express tier, read throughput scaling linearly to a hundred replicas. A large monorepo gets hundreds of replicas. A tiny agent repository gets one, or zero, and is materialised on demand. Meanwhile Thomas Dohmke, who ran GitHub as CEO for four years and left in 2025, raised a $60 million seed for Entire https://entire.io/ , which mirrors your repository into a distributed network so agents can clone from somewhere closer, and stores prompts, transcripts and tool calls alongside commits so agent-generated changes can be audited and reproduced. I want to be clear that I think these people are right about the observation. Agents have created an enormous number of small, short-lived repositories, and that broke assumptions built into a decade-old architecture. Cursor’s engineers reached that conclusion from inside the problem, with production numbers. That is much better evidence than anything I have. They are also solving it in the only direction available to them: make the hosted case cheap for the host. Which is a fine thing to do, and it does nothing for the laptop currently holding five copies of the same monorepo. The question nobody is asking Everyone is competing to be the best place to put code. Almost nobody is asking how much of that code needed to go anywhere at all. Here is the narrow version of my claim, because the broad version is wrong. Git is already local. git commit , git branch , git log , git diff , git rebase , none of them touch the network, and that has been true since 2005. What is remote is the layer around git: review, CI, issues, releases, packages. The collaboration layer. And most of what we now produce will never be collaborated on. Think about what a working session actually looks like this year. Five worktrees, five agents, five branches, running in parallel on the same repository. Four of them will be thrown away before lunch. Every one of those experiments currently gets a remote branch, a set of CI runs, webhook deliveries, API calls, and a row in somebody’s database, for work whose entire lifespan is ninety minutes on one machine. That is not GitHub failing. That is us sending throwaway work to a system built for work that lasts, because it is the only path any of our tools know. Not an alternative. A staging area. I am not proposing that anyone leave GitHub, and I am not making the self-hosting argument. That argument is fifteen years old and it has lost every time it has been made, to network effects, deservedly. Your code needs to be where the contributors, the issues, the stars, the security advisories and the muscle memory already are. What I am proposing is a staging area. Experiment locally, where it is cheap and fast and private. When something turns out to matter, promote it. And when a reader asks what “promote it” involves, the answer is the good part: you push it. That is the entire ceremony. Nothing about this asks anyone to give up anything, because the graduation path is the thing git was designed to do in the first place. Look at GitHub’s position through this lens and it becomes sympathetic rather than damning. They are optimising, simultaneously, for a gazillion cheap dirty experiments and for the serious long-lived projects that depend on them being up. Those two workloads want opposite things. One wants to be free, instant, disposable and unlogged. The other wants durability, auditability, replication and consistency. Serving both from one system is how you end up with an operational nightmare, and taking the first workload off the platform is good for everybody, including them. The example that already happened I keep coming back to worktrees, because they are this argument in miniature and I did not have to invent them. git worktree shipped in git 2.5, in 2015. For a decade it was a niche convenience: a way to look at another branch without stashing. Then agents arrived, and it turned out to be exactly the right primitive for a workload nobody had imagined, because a worktree is the cheapest way to hand an autonomous process a tree it is allowed to break. Claude Code creates one per background session. JetBrains added first-class support in 2026.1, VS Code the summer before. There is now an entire cottage industry of worktree managers. And here is the part I find interesting. The primitive was right, but it had an assumption baked into it that the new workload broke. git worktree add writes a complete second copy of your working tree, because in 2015 you had two of them and disks were the cheap part. Now you have five, or fifty, and on a monorepo that is gigabytes each time. On any modern filesystem it does not have to be. I measured it on the Linux kernel tree, about 95,000 tracked files: a plain git worktree add writes 1,816 MB. Materialising the same worktree with filesystem copy-on-write clones writes 36 MB, and produces a byte-identical tree. Fifty times less disk, at the same wall clock, using a filesystem feature macOS has had since 2017 and Linux has had for longer. So I built it. It is called git-sprout , it is a drop-in replacement for git worktree add , it does exactly one thing, and it is on GitHub https://github.com/alltuner/git-sprout under MIT: brew install alltuner/tap/git-sprout git sprout add ../myrepo-feature -b feature That is the shape of the whole idea, and it generalises: find a primitive that already exists, notice which assumption inside it the new workload broke, and fix that one thing. What else is on that list A few things I want to try, offered partly so people can tell me which ones are bad. A locally-hosted forge surface that speaks the API our tooling already speaks. The obstacle here is specific and worth naming: gh , the CLI that every harness and CI snippet is written against, leans on GraphQL, which is why it does not work against Forgejo https://forgejo.org/ today. That is a concrete, boring, solvable problem, and solving it would give every agent harness a working forge for free. Local CI that is not a second implementation of CI. act already runs GitHub Actions workflows in Docker with no commit and no push, and Forgejo’s own runner is a soft fork of it. The pieces exist. And credit where it is due: Forgejo https://forgejo.org/ and Codeberg https://codeberg.org/ , Radicle https://radicle.xyz/ , sourcehut https://sr.ht/ are all doing versions of this. So is Jujutsu https://github.com/jj-vcs/jj , whose adoption pitch is essentially this entire post compressed into one line: keep your git infrastructure, keep your GitHub, keep your CI, just use a better interface. It is working. That is encouraging rather than discouraging. Why the people with the money will not do this Worth asking, and I think the dull answer is the true one. Every incremental improvement to local development is revenue-neutral at best and cannibalising at worst. Codespaces, Actions minutes, Copilot seats, Advanced Security are all metered cloud products. Nobody at a platform company gets promoted for moving load off the platform. That is not cynicism, it is just how the incentives point, and it explains the observed behaviour completely on its own. There is a second possibility that I will flag as speculation, because I have no evidence for it and I would rather say so than imply I do. Being the place through which all the world’s code passes may be worth defending for reasons that have very little to do with hosting it, in a period when code is training data. I do not know that this is a factor. I notice that it would be strange if it were not considered. The asymmetry Winning the next forge war costs billions and is available to about five companies on earth. Cursor’s architecture is the work of people who have spent decades on this, now funded by a $60 billion acquisition. I am not in that fight, I have nothing useful to add to it, and I am glad somebody competent is having it. Making the throwaway ninety percent of development stop touching the network costs a weekend and a well-chosen primitive. Nobody is doing it, because there is no way to bill for it. That seems like the more interesting side of the asymmetry. Start small, reuse primitives, fix friction points, and leave the big guns for when a project earns them. git-sprout is the first one. There will be others. One more thing There is a hole in all of this. You can move the worktrees local, and the forge, and CI, and then the agent opens a socket to somebody’s data centre anyway, and the loop is remote again for the one part that actually costs money. That hole is closing. In the same week as the outage, three labs shipped four sets of open weights: GLM-5 https://huggingface.co/zai-org/GLM-5 on the 11th, DeepSeek V4 Pro https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-0813 on the 13th, Qwen3.8-27B https://huggingface.co/Qwen/Qwen3.8-27B on the 14th. And Kimi K3 https://huggingface.co/moonshotai/Kimi-K3 , published in July, now reports agentic coding scores level with the leading closed models. So the gap that matters is no longer open against closed. It is datacentre against laptop. Kimi K3 is 2.8 trillion parameters, and nobody is running that next to their editor. Qwen3.8-27B is 27 billion, scores 73.0 on Terminal-Bench, and wants about 18 GB at four-bit. Four months ago that would have been near the top of the open leaderboard. Now it fits in memory. Same argument, one layer down: the frontier model for the work that matters, the local one for the four experiments that get deleted before lunch. Which leaves the question I will end on. What happens the first time the whole loop closes, repository and worktree and forge and CI and model, all on one machine, none of it phoning anywhere, for the ninety percent of what we make that was never going to matter? I do not think that is far away.