The Great Snowflaking: How AI Could Break the Open Source Model and Force GitHub to Reinvent Itself

AI threatens the open source model by destroying the economic assumption that code is expensive to write. Historically developers reused libraries because rewriting them was wasteful, which concentrated millions of users on shared implementations. Now AI can regenerate a custom version of almost any tool in minutes, so software fragments into unique snowflakes. That weakens shared fixes, security patching and GitHub's star based discovery, forcing the platform to reinvent how it surfaces quality.

For most of the history of software, code was expensive. If somebody had already solved a problem, you reused their solution. You downloaded the library, cloned the repository, installed the package, forked the project or submitted a pull request, because rewriting something that already existed was normally considered wasteful. AI is quietly destroying that economic assumption.

A few days ago my son showed me something he had built, and my first instinct was not to ask him for the repository, install his project, fork it or contribute to it. I looked at what it did and thought that I could just get an AI to build my own version of that. That tiny moment made me wonder whether something much bigger is happening to software, because we may be moving from an age of reuse to an age of regeneration, and if that happens, it changes open source, software security and GitHub itself.

1. Open source was built on an economic constraint

Open source succeeded partly because writing software was expensive. Imagine that someone had already spent six months building a logging library. You could spend another six months building your own, or you could type “npm install something” and move on. The economics were obvious, and the same logic created enormous shared ecosystems around Linux, PostgreSQL, Kubernetes, Spring, React, Redis, Apache and millions of smaller libraries.

There was an implicit bargain at the heart of all this: someone has already solved this problem, so use their code rather than solving it again. That bargain produced another extraordinarily important property, which is that thousands or millions of users converged onto the same implementation. When someone found a bug, the maintainer fixed it once and everybody could inherit the fix. When a vulnerability was discovered, one upstream patch could protect an enormous population of downstream systems, and when someone added a feature, everyone benefited. Open source turned software development into a form of shared infrastructure, and AI changes the economics underpinning that model.

2. Why install when you can regenerate?

Suppose I need a small utility today. I find a GitHub repository with 1,500 lines of code, seven dependencies, an installation process, its own configuration format and some architectural decisions I do not particularly like. Historically I would probably accept those compromises because rewriting 1,500 lines was annoying, but now I can tell an AI coding agent to build me something that does this, but use PostgreSQL rather than SQLite, expose a REST API, remove these dependencies, package it in Docker and use my existing authentication framework. A few minutes later I have my own version.

Not a fork, not a pull request, not even necessarily code derived directly from the original repository. It is a new snowflake, and because creating software has become dramatically cheaper, customising the implementation increasingly feels cheaper than understanding somebody else’s implementation. That is a profound inversion. We used to ask why we would build something ourselves, and AI increasingly makes us ask why we would install somebody else’s version instead.

3. GitHub’s own capacity planning is the clearest signal

The most compelling evidence for all this does not come from a think piece about AI productivity. It comes from GitHub’s engineering decisions.

In its April 2026 availability update, GitHub explained that it had started executing a plan in October 2025 to increase platform capacity tenfold, aimed at substantially improving reliability and failover. By February 2026 it had concluded that it needed to design for a future requiring thirty times current scale, and it named the driver explicitly: a rapid change in the way software is being built, with agentic development workflows accelerating sharply since the second half of December 2025. GitHub listed repository creation, pull request activity, API usage, automation and large repository workloads as all growing quickly at the same time.

The volume numbers that emerged around the August 2026 outages point the same way. Following the seven hour incident on 17 August, GitHub stated that monthly commits had grown from 1.4 billion in April to 2.9 billion, roughly a doubling in four months, and press coverage of the same disclosure reported the platform running at approximately 130 million merged pull requests and roughly 24 million new repositories per month.

Those figures deserve one honest caveat, because a technically literate reader will spot the discrepancy immediately. GitHub’s 2025 Octoverse report counted something closer to 986 million commits across the whole of 2025, alongside 630 million total repositories, more than 395 million of them public, and 4.3 million AI related repositories. A monthly figure of 2.9 billion is therefore not a continuation of the Octoverse line on the same axis: the two are almost certainly counting different things, with the platform load figure plausibly including pushes, mirrors, automation and internal traffic that the annual developer facing report excludes. The direction of travel is what matters here, and the direction of travel is not in dispute, since GitHub itself attributes the pressure to how software is now being built.

That reframes the argument considerably. This is no longer me speculating that snowflaking might be coming. It is a platform rebuilding its own foundations around the consequences, having discovered within four months that its capacity model was out by a factor of three. AI allows one developer to produce the volume of code that previously required a team, and agents can create repositories, tests, documentation, infrastructure definitions and hundreds of commits with very little marginal human effort. We are removing the constraint that kept software relatively scarce, and once the cost of producing another implementation approaches zero, software starts behaving very differently.

4. The zero star internet

I think GitHub’s long tail is going to become increasingly strange: millions of repositories with one star, or zero stars, one contributor, thousands of commits, excellent documentation, good test coverage, and quite possibly no human other than the owner who has ever used them. That sounds ridiculous until you realise that AI makes it perfectly rational. Why spend two hours evaluating five similar open source projects when you can spend ten minutes describing exactly what you need and generate a sixth?

The consequence is not simply that stars stop working, because GitHub’s discovery mechanisms were never purely star based; its own repository ranking combines signals such as stars, forks and unique issue authors. The deeper problem is that the entire family of human reputation and popularity signals starts to degrade at once. Historically, 20,000 stars told you something, because lots of humans had discovered the software, evaluated it and decided it was worth paying attention to, and a healthy issue tracker told you that humans were actually running the thing in anger. When 500 agents can produce 500 polished repositories with immaculate READMEs, exhaustive tests and pristine commit histories, the question stops being which repository looks credible and becomes which signals still prove that humans genuinely trust and operate this thing.

The interesting future problem is therefore not the repositories with 20,000 stars. It is the hundreds of millions with zero or one star, where there could be fantastic software hidden among them, alongside abandoned experiments, near duplicates, generated scaffolding and a great deal of code that nobody has ever meaningfully reviewed. GitHub becomes less like a library and more like a rainforest.

5. Forking is no longer the right metaphor

Git already understands forks beautifully. Repository A becomes repository B, Git knows their history, commits have ancestry, and changes can flow between branches. AI introduces something I would call a ghost fork instead. I look at what a project does, perhaps by reading its README, having my coding agent examine its API, or explaining its behaviour in English, and then an agent recreates the capability differently. From Git’s perspective these two repositories may have absolutely no relationship, yet conceptually one is clearly descended from the ideas contained in the other.

That matters enormously, because software lineage is starting to escape the commit graph. Once conceptual ancestry separates from code ancestry, licensing, attribution, vulnerability inheritance and software provenance all become considerably harder problems, none of which our existing tooling was designed to reason about. GitHub may eventually need to understand semantic ancestry rather than only Git ancestry, since two repositories can contain different code, different directory structures and different dependencies while implementing essentially the same capability. That relationship becomes important for discovery, and it becomes even more important for security.

6. The security problem is much bigger than duplicate code

Imagine an open source library has 500,000 users and a serious vulnerability is discovered. Today there is a reasonably well understood process: a CVE is issued, the maintainer patches the vulnerability, a new version is released, and downstream dependency scanners begin warning everyone to upgrade. Now imagine AI has caused that implementation to splinter into 50,000 customised variants, one using PostgreSQL, one using DynamoDB, one with a replaced HTTP stack, one that copied part of the authentication logic, one rewritten into Rust, and another recreated in Java. Which ones contain the vulnerability? Nobody necessarily knows.

Traditional vulnerability management depends heavily on identity, in the sense of package X, version Y, containing CVE Z, and snowflaked software damages that assumption. A developer could remove the dependency while inadvertently reproducing the vulnerable logic inside their own code, so their dependency scanner becomes completely happy while the vulnerability survives. Worse, when the original project fixes the vulnerability, the fix may never reach its ghost descendants, and we will have effectively traded dependency risk for lineage risk.

The volume side of this is already visible. OpenSSF’s 2026 CRA readiness report found that across more than 14,000 open source projects indexed on the Linux Foundation Exchange, published CVEs in the first quarter of 2026 rose 394 percent year on year, with high severity findings up 811 percent. It is important to read that number carefully, because OpenSSF itself attributes much of the increase to improved automated scanning, AI based analysis and audit activity prompted by the EU Cyber Resilience Act, rather than to software suddenly becoming four times less secure. What it demonstrates is the sheer processing volume the ecosystem is already struggling to absorb, and that is the uncomfortable multiplication at the heart of my argument: we are increasing the quantity of software at precisely the moment our ability to discover problems inside software is also increasing sharply. The Linux Foundation already treats maintainer capacity, dependency management and unresolved vulnerabilities as key indicators of open source health, and it is difficult to see how AI generated fragmentation makes any of those three easier.

There is an odd upside buried in all of this, and it is worth stating plainly before moving on. A CVE is a Common Vulnerabilities and Exposures entry, and the word doing the real work in that acronym is common. Once implementations stop being common, in the sense that no two variants of the same idea share the same code, the vulnerabilities inside them stop being common too. You would not really have CVEs any more. You would just have VEs, defects that belong to one bespoke implementation and nobody else’s.

That sounds like good news, and in one narrow sense it is. Mass exploitation depends heavily on scale, on the fact that a single flaw in a single widely shared library can be turned into one exploit and pointed at hundreds of thousands of installations at once. Take away the shared implementation and you take away that multiplier, since an attacker who wants the same reach now has to reverse engineer each bespoke variant separately rather than writing one exploit and sweeping the internet with it. Nothing common to attack really does make the worst case scenario, the single flaw that compromises an entire ecosystem overnight, considerably harder to pull off.

But the second half of the question deserves just as much scepticism as the first half deserves credit, because nothing common to forget to patch is not obviously true in the way it sounds. Incidents like the Log4j disclosure happen precisely because a flaw sits inside one widely shared dependency, which is also exactly why they eventually get fixed: enormous shared visibility forces enormous shared urgency, a CVE number gets issued, scanners flag it everywhere it appears, and even the slow movers get dragged toward patching once the disclosure is public. Remove the shared dependency and you do not remove the underlying design mistake, you remove the shared visibility into it. The same flawed pattern can now sit inside a million bespoke variants indefinitely, invisible to any scanner that works by matching known package versions, and with no CVE ever issued because there is no common instance left to name. Nobody forgets to patch a vulnerability that nobody ever discovered in the first place.

That asymmetry probably favours a different kind of attacker rather than eliminating attackers altogether. Mass, automated scanning for one known CVE across thousands of hosts becomes less rewarding, but a well resourced attacker willing to point their own AI at a specific target’s bespoke implementation, looking for the one flaw unique to that one codebase, may find fragmentation actively helpful, since there is no public disclosure, no patch cycle and no crowd of other defenders who already fixed the same bug somewhere else. Security stops looking like patch Tuesday for the whole ecosystem and starts looking like bespoke reconnaissance against one target at a time, and it is not obvious that defenders are better equipped for that world than attackers are, particularly once attackers can lean on the same AI assisted reverse engineering that produced the fragmentation in the first place.

So the honest answer is that hacking probably gets harder in aggregate and easier at the sharp end simultaneously. Worm style, internet wide compromises should become rarer, because there is genuinely less common ground to exploit at scale. Quietly persistent, individually undiscovered flaws inside code nobody with security expertise has ever looked at should become more common, because there is genuinely less common ground left for anyone, defender or disclosure process, to ever notice them. Fewer CVEs sounds like a security win right up until you remember that a lower count can mean the ecosystem got safer, or it can simply mean the ecosystem stopped being able to see itself.

7. AI makes code cheap. It does not make maintenance free.

This may become one of the great technology mistakes of the AI era, because we are confusing the cost of creating software with the cost of owning software. AI can generate another 20,000 lines of code while I eat lunch, and I now own another 20,000 lines of code. Those lines can contain vulnerabilities, they depend on runtimes that will eventually reach end of life, their APIs will need upgrading, certificates will expire, operating systems will change, database behaviour will evolve, and new attack techniques will appear.

AI can certainly help maintain all of this, but multiplying software still multiplies the surface area requiring maintenance. We could therefore produce a bizarre outcome where AI makes individual software creation dramatically more efficient while simultaneously making the world’s aggregate software estate dramatically more complicated. Every developer becomes more productive, and the ecosystem becomes less efficient, and both statements can be true at once.

8. GitHub itself has to survive the explosion

There is also a brutally practical infrastructure problem here. A platform designed around human development is becoming a platform used by humans commanding armies of software agents. Humans sleep, agents do not, and humans usually do not create 400 commits while they go for coffee, whereas agents happily can.

The events of August and September 2026 illustrate the point better than any argument I could construct. On 17 August GitHub suffered an outage lasting close to eight hours, and its own explanation was not a bad deployment or a configuration error but a capacity shortfall, with traffic reaching a new peak and a critical infrastructure component in its Central US data centre failing to scale alongside it. The commit doubling figure appeared in that same post mortem, which is what makes it significant: GitHub was not publishing a growth statistic for marketing purposes, it was explaining why its systems fell over. Then on 1 September GitHub reported a further incident in which a sharp, concentrated surge in push volume saturated worker pools and job queueing infrastructure, delaying commit processing for more than 140,000 customer accounts.

There is a further consequence worth setting out here, because it suggests the fragmentation might not stop at the level of code. If a globally shared development platform becomes increasingly exposed to enormous bursts of agent generated activity, large enterprises may eventually decide that they do not want to sit inside the same blast radius as everyone else.

For a bank, an insurer, a government department or any other systemically important organisation, GitHub going down is not merely an inconvenience for developers to grumble about. Source control, pull requests, release pipelines, security scanning and deployment workflows can all sit inside the production change path, and once that is true, the availability of somebody else’s shared SaaS platform has quietly become part of your own operational resilience architecture whether you planned for that or not.

That creates a real incentive to move part of the software factory back inside the corporate boundary. GitHub already supports exactly this model through GitHub Enterprise Server, which organisations can run inside their own datacentres or their own cloud environments, keeping the repositories themselves outside the shared GitHub.com failure domain. It is worth being precise about what actually achieves that separation, because simply running self hosted Actions runners does not, since the GitHub.com control plane remains a dependency either way. Enterprises could instead keep authoritative repositories, build infrastructure and the critical deployment path running locally, while continuing to use public GitHub mainly for collaboration with the wider ecosystem.

The motivation would not necessarily be secrecy. It would be blast radius. If ten million AI agents elsewhere suddenly produce a massive spike in repositories, commits, pull requests or API activity, there is no obvious reason that event should be capable of interrupting the release pipeline of a bank in Johannesburg.

This produces another strange inversion. Cloud development platforms won partly because enterprises wanted to stop operating their own source control infrastructure. AI could make software activity so enormous, and the shared dependency so operationally important, that some of the largest organisations decide to bring the critical parts back under their own control instead. That does not make the underlying scaling problem disappear, it simply relocates it, since an enterprise running its own GitHub estate now has to provision its capacity, patch it, secure it, upgrade it and design its own resilience around it. But the failure domain becomes theirs rather than everybody’s, and that may turn out to be worth the extra operational burden.

The Great Snowflaking could therefore be happening at two levels at once. The software itself fragments into millions of bespoke implementations, while the infrastructure used to store and build that software fragments into private enterprise islands designed specifically to contain the blast radius.

GitHub’s future challenge may consequently be larger than simply scaling GitHub.com. It may need to become the intelligence, trust and collaboration layer connecting a far more distributed universe made up of public GitHub, private GitHub Enterprise installations and locally operated software factories.

I want to be careful here, because I cannot claim that AI caused any particular one of those incidents, and I am not going to pretend otherwise. What I can say is that the pattern is consistent and that GitHub’s own framing connects the pressure to a change in how software is built. Taken together, a capacity target revised from tenfold to thirtyfold in four months, a commit volume that doubled over a comparable period, and repeated outages attributed to capacity rather than to code, describe a platform whose fundamental load assumptions have stopped holding. GitHub now has to design for a world where the entity on the other end of a git push is no longer constrained by human typing speed, and the important unit of its capacity planning may eventually stop being developers and become agents per developer instead, a number that could become very large indeed.

9. GitHub needs to become more than a repository host

Ironically, I think this makes GitHub more important rather than less, though its value may shift. Storage is not the scarce resource of the future. Trust is. GitHub could increasingly become the trust and intelligence layer sitting above the world’s exploding software estate, which means answering questions far more sophisticated than simply where the source code lives.

It needs to help us answer where an idea came from, which repositories implement substantially the same thing, which one is actively maintained, which one is actually deployed by real organisations, which security patch in one project is relevant to an independently generated project elsewhere, which code was produced by a human and which by an agent and using what source material, and which of many competing implementations should actually be trusted. The repository remains important, but the graph between repositories becomes far more valuable.

10. Package scanning stops being enough

Security tooling will have to evolve alongside all of this, and the framing matters. CVEs themselves do not need to become semantic; what needs to become semantic is vulnerability detection and vulnerability lineage, which is a subtly different and considerably more tractable problem.

Encouragingly, this is not a completely new category so much as an extension of something GitHub has already been building. CodeQL analyses actual code behaviour and data flow rather than merely matching package versions, and in June 2026 GitHub extended automatic security validation to code produced by third party coding agents including Claude and OpenAI Codex, running CodeQL, checking newly introduced dependencies against its Advisory Database and applying secret scanning, with the agent then attempting to resolve whatever the analysis finds before finalising the pull request. GitHub reported that since introducing equivalent validation for its own Copilot cloud agent in October 2025, the mechanism had proactively prevented hundreds of potential security leaks and vulnerabilities.

Extend that trajectory and the future capability becomes obvious. When a vulnerability is found in a piece of authentication logic, instead of merely identifying repositories that depend on a specific version of a package, the platform searches the software graph for semantically equivalent implementations, potentially finding thousands of apparently unrelated repositories containing variants of the same vulnerable design, and then generates individualised patches adapted to each one. Dependabot evolves from telling you to upgrade a package from one version to the next, into telling you that your authentication implementation appears semantically related to a recently disclosed vulnerability, along with a patch written for your particular implementation. Ironically, AI may create the fragmentation problem and then become essential to managing it.

11. We may share specifications instead of implementations

There is another possible future for open source that I find fascinating, which is that we continue sharing, but what we share changes. Instead of sharing the entire implementation, we increasingly share protocols, specifications, tests, schemas, prompts, architecture, interfaces and behavioural definitions.

Consider what happens if recreating an implementation becomes trivial. The most valuable open source artefact might no longer be 50,000 lines of source code. It might instead be a superb specification accompanied by 10,000 tests, which I could hand to an agent and say, implement this for my architecture and make every test pass. I might implement it in Go, someone else in Java, and a third person in Rust. The thing we share is no longer necessarily the executable implementation, but the idea and the contract behind it.

This is no longer purely hypothetical. Early projects are already experimenting with exactly this inversion, with at least one emerging standard describing its model as distributing buildable knowledge rather than code, treating the product vision, architecture, functional requirements and verification contract as the shared artefact while the generated implementation becomes a local and essentially disposable output. Whether any particular one of these efforts survives is beside the point. The fact that people are seriously proposing the specification as the primary unit of sharing suggests the inversion has already begun. That would still be open source, but it would be a radically different interpretation of openness.

12. Infrastructure converges. Implementation fragments.

I do not think this means Linux, PostgreSQL or Kubernetes suddenly disappear, because there are enormous advantages to convergence around complicated infrastructure. Mature projects contain years of obscure engineering knowledge, edge cases and battle scars that cannot simply be inferred from a README, and almost nobody is going to regenerate a database engine or a container orchestrator on a Tuesday afternoon.

But consider the enormous middle layer of GitHub: CLI tools, small APIs, internal dashboards, automation scripts, data transformation utilities, proxies, wrappers, developer tools, tiny SaaS applications and glue code. That is where I think snowflaking explodes, because these projects are complex enough to have historically been worth sharing but simple enough that an AI can increasingly regenerate them.

This suggests that the honest model is not reuse being replaced by regeneration, but reuse moving down the stack. Every one of those regenerated utilities still runs on PostgreSQL, Linux, Kubernetes, the JVM, AWS, Docker, HTTP, TLS and the OAuth standards, so the foundations keep accumulating users while the layer immediately above them shatters. AI may therefore push software in two opposite directions simultaneously: extreme convergence around the foundational primitives, and extreme fragmentation in everything built on top of them. That is why PostgreSQL plausibly gets stronger at the same moment that a perfectly decent 2,000 star utility gets quietly annihilated by 50,000 bespoke versions of itself.

13. This piece and the wider extinction debate

I want to be honest about where this piece sits relative to a much larger and more serious conversation, because it would be misleading to spend thousands of words on AI transforming software while pretending nobody is arguing about something considerably bigger than GitHub’s capacity planning.

In May 2023, hundreds of AI researchers and industry leaders signed a one sentence statement organised by the Center for AI Safety, arguing that mitigating the risk of extinction from AI belonged alongside “societal-scale risks such as pandemics and nuclear war”. What makes that statement hard to wave away is who signed it. The list included Geoffrey Hinton and Yoshua Bengio, two of the researchers whose work effectively created the deep learning revolution this piece keeps returning to, alongside the chief executives of the three labs building the frontier models sitting inside the agentic coding tools I have been describing throughout, Sam Altman of OpenAI, Dario Amodei of Anthropic and Demis Hassabis of Google DeepMind. Hinton has since put a number on his own concern, estimating something in the range of ten to twenty percent for AI ending in human extinction within the coming decades, and he has separately described the technology he helped build as “an existential risk”.

That is one side of a genuinely unresolved argument, and the other side is held just as firmly by serious people. Yann LeCun, Meta’s former chief AI scientist and a fellow Turing award winner alongside Hinton and Bengio, has repeatedly called this entire line of reasoning premature, telling one interviewer that the idea current systems are close to threatening humanity is “complete B.S.”, and separately arguing that discussing existential safety is pointless before anyone has “a basic design for even dog-level AI”. Andrew Ng, the cofounder of Google Brain, has made a related point, saying he does not see how advanced AI could plausibly lead to human extinction. When journalists at The Conversation recently put the question directly to five academic experts, three said no and two said it depended heavily on assumptions nobody can currently verify.

I am not going to pretend I can settle that argument in a paragraph, and I do not think anyone honestly can. What I would say is that both sides tend to agree on something narrower and more useful for the purposes of this piece: nobody, whether worried about extinction or dismissive of it, is arguing that AI generated software is going to remain small, slow moving or easy to supervise. Whatever you believe about superintelligence, the volume argument in section 3 and the maintenance argument in section 7 hold regardless, because they rest on what agentic coding tools are already doing today rather than on what a future system might eventually become. The extinction debate is about whether AI could end up controlling us. This piece is about something already happening underneath that question, which is that AI is quietly changing who controls software, and that argument does not need the bigger one to be true in order to matter.

14. Open source isn’t dying. Reuse is changing.

GitHub’s own data makes it hard to credibly claim that open source is currently dying. Public contributions are growing, new contributors continue arriving, and AI projects are among the fastest growing on the platform. But I think something underneath those headline numbers is changing regardless.

It would be too glib to claim that open source succeeded purely because software was expensive, and a sophisticated open source practitioner would rightly object, since open source also succeeded because of shared maintenance, network effects, transparency, interoperability, accumulated expertise, reputation and peer review. The sharper version of the economic claim is this: open source benefited enormously from the fact that creating another implementation was expensive, while reusing and improving a shared implementation was comparatively cheap. AI attacks precisely one half of that equation. It makes creation cheap, and as section 7 argues, it does not obviously make verification, operation, maintenance and trust cheap in the same proportion.

Once creating another implementation becomes almost free, customisation starts winning over standardisation, and that creates a completely new problem. We spent decades learning how to manage millions of people collaborating on shared software, and we may now have to learn how to manage millions of people not collaborating, while their agents independently generate countless variations of essentially the same ideas.

That is the Great Snowflaking. GitHub’s challenge is no longer simply storing all that code; its challenge is making sense of it. AI makes code abundant, and abundance makes trust scarce. A reader on an earlier draft of this piece, the actuary Ryno Van den Berg, put the underwriting version of that same point better than I did: abundance does not just make trust scarce, it makes risk unpriceable, because you cannot underwrite what you cannot count, and counting depends on there being something common left to count. GitHub won the previous era by becoming the place where the world stored and collaborated on code. It may win the next one by becoming the place that tells us which of an effectively infinite number of implementations we should actually trust.