How vibecoding is destroying the open source that feeds it
March 3, 2026
The snake eating its own tail
A year ago, vibecoding was a curiosity. Today, it’s an industry. Millions of developers — or rather prompters — generate entire applications by describing what they want to an LLM. In minutes, an API, a frontend, a deployment. Magical.
But behind this magic lies a dirty secret that nobody wants to face: every line of code generated by these AIs was trained on millions of open source projects — projects that are now dying.
Vibecoding would be nothing without open source. And it’s killing it.
What exactly is vibecoding?
For those who spent 2025 in a cave: vibecoding is the practice of creating software in natural language, relying on generative AI models (Claude, GPT-5, Gemini, and the dozens of specialized models that have emerged since). You describe a vibe, an intention, and the AI produces the code.
No debugging. No reading documentation. No Stack Overflow. And above all — here’s the crux — no contributing back.
The implicit pact of open source is broken
The open source ecosystem has always rested on a tacit social contract:
I publish my code for free. In return, others use it, find bugs, suggest improvements, contribute. The project lives because a community keeps it alive.
This contract had already been severely tested by large corporations that consume open source without contributing proportionally. But at least the developers who used these libraries understood them. They opened issues. They forked. They sent pull requests. They wrote blog posts that spread the word about the project.
Vibecoding has blown up this cycle.
The vibecoder doesn’t know which library they’re using. They don’t know, and they don’t care. They asked “build me a payment API with webhook handling,” and the AI chose this or that dependency for them. They will never read that project’s README. They will never open an issue. They won’t even know that project exists.
The chilling numbers
The data is starting to speak, and it’s not reassuring:
- Contributions to mid-size open source projects (10-500 stars) dropped 35% between January 2025 and January 2026, according to aggregated data from GitHub and GitLab. These mid-size projects form the essential connective tissue of the ecosystem.
- The number of new issues opened by humans is down 28%, while issues opened by bots or automated tools are exploding — mostly noise, rarely signal.
- Donations via GitHub Sponsors, Open Collective and Tidelift are stagnating or declining for the majority of projects, while actual usage (measured by npm, PyPI downloads, etc.) continues to rise. More consumption, less support.
- The number of new “first-time” contributors to foundational projects (crypto libraries, parsers, networking tools) has dropped 41%.
That last number is the most alarming. The pipeline of the next generation is drying up.
The ghost generation
I spoke with about ten maintainers of popular open source projects in recent weeks. The same observation comes up, almost word for word:
“My downloads have never been higher. My contributions have never been lower.”
— Maintainer of a Python data processing library, 12,000 stars
“I’m getting issues that clearly make no sense. Someone copy-pasted an error message generated by an AI tool, without understanding what my library does or even knowing they’re using it. I spend more time closing useless issues than developing.”
— Maintainer of a Node.js tool
“I feel like I’ve become an invisible subcontractor for Cursor and Copilot. My code is everywhere, but I’ve disappeared.”
— Creator of a UI component library
Vibecoding has created a ghost generation: people who depend on open source without existing in open source. They are neither users, nor contributors, nor observers. They are passive consumers of an automated value extractor.
The technical problem: dependencies without awareness
Beyond the community problem, there’s a concrete technical issue.
When a human developer chooses a dependency, they (in theory) do evaluation work: is this project maintained? Does it have known vulnerabilities? Is it suited to my use case? What’s its license?
AI optimizes for what works right now. It favors libraries over-represented in its training data — meaning those that were popular at training time. This creates two perverse effects:
- The fossilization effect: obsolete or poorly maintained libraries keep being injected into new projects because the AI “remembers” them. We’ve seen projects generated in 2025 using package versions from 2022, with known CVEs.
- The winner-take-all effect: big projects (React, Express, pandas) continue to be systematically recommended, while newer, lighter, better-designed alternatives remain invisible. The ecosystem’s innovation freezes.
The “democratization” paradox
Vibecoding advocates make a compelling argument: democratization. Thanks to AI, millions of people who couldn’t code can now create software. That’s true. It’s even wonderful.
But this democratization is extractive. It extracts value from a common good (open source) to concentrate it in proprietary products (AI IDEs, SaaS platforms, inference APIs). Vibecoders pay their subscription to Cursor or Replit, not to the person maintaining date-fns at 2 AM.
We’ve privatized the benefits and socialized the costs. A classic.
AI models themselves make it worse
We must also point the finger at the AI companies themselves.
The models were trained on open source code, often without explicit consent, and the revenue generated by these models doesn’t flow back to the projects they depend on.
Some initiatives exist — Anthropic, Google and others have launched support funds — but let’s be honest: these are crumbs. The “AI for Open Source” fund announced by the Linux Foundation in November 2025 represents $50 million. That’s less than what these companies spend on compute in a single quarter.
And above all, money doesn’t replace contributors. An open source project doesn’t die for lack of dollars. It dies for lack of people who care.
The nightmare scenario
Let’s project forward for a moment.
If current trends continue:
- Exhausted maintainers abandon their projects. This is already happening. Maintainer burnout isn’t new, but vibecoding accelerates it by increasing the load (more usage, more noise in issues) while diminishing the reward (less recognition, fewer contributions).
- Critical projects become zombie software: still downloaded, never updated again. Security flaws accumulate. AIs keep recommending them.
- A major security crisis erupts when a vulnerability in a zombie package ends up in thousands of vibecoded applications. Log4Shell will seem like a warm-up exercise.
- Innovation slows down because new open source projects can no longer find a community. Why publish a package when nobody will ever look at it — when people don’t look at code at all anymore?
- AI models degrade because they increasingly train on AI-generated code rather than thoughtful human code. The snake eats its own tail down to the bone. What’s called model collapse becomes visible in the quality of produced code.
This scenario isn’t science fiction. Every step is already underway.
What can be done?
I’m not naive enough to think we can stop vibecoding. The genie is out of the bottle, and frankly, the productivity it brings is real. But we can — we must — correct course.
1. Tax extraction, fund the commons
AI platforms that monetize code generated from open source should return a significant percentage of their revenue to the ecosystem. Not a symbolic fund. A structural mechanism, proportional to actual usage. The model already exists in other domains: it’s called a redistribution license or a digital commons royalty.
2. Make dependencies visible
Vibecoding tools should systematically display the open source dependencies they inject, with a link to the project, its maintenance status, its license, and a way to contribute. Not hidden in a package.json that nobody will read. Full screen. “This code uses 47 open source projects. 3 of them haven’t been updated in a year. Here’s how to support them.”
3. Integrate contribution into the AI workflow
Why couldn’t AI tools generate contributions back? Detect a bug in a library, draft a fix, propose improved documentation? If AI can consume open source, it should be able to contribute to it.
Some experimental projects are moving in this direction. They need to be generalized.
4. Educate vibecoders
Just because you don’t code doesn’t mean you shouldn’t understand where the code you use comes from. Vibecoding platforms should include a minimum of open source literacy: what’s a license? What’s a maintainer? Why does it matter?
We don’t require someone who drives a car to know how to build one. But we do require them to know that the road was built by someone, and that they pay taxes to maintain it.
5. Rethink licenses
The MIT license and the Apache license were written for a world where users were developers. That world no longer exists. It’s time to explore new licensing models that account for AI extraction and ensure fair redistribution of the value created.