Will “Vibe Coding” Kill Open Source? I Doubt It.

Recent discussions have been stirred by an arXiv paper with a rather alarming title: “Vibe Coding Kills Open Source”.

“Vibe Coding” is now a term used to describe a development style in which you let AI write the code for you, skipping documentation reading, bug reporting, and interaction with maintainers. The paper’s core argument is that while this usage boosts individual productivity, it severs the connection between users and open-source maintainers—a connection many projects supposedly rely on for survival.

Sounds plausible? The more I think about it, the more flawed this argument seems.

The Paper’s Shaky Premise

The paper builds an economic model to support its point, but its core assumption is that “open source monetizes through user participation.”

The problem is, this is far from reality.

In practice, the vast majority of open source maintainers earn absolutely nothing. Those projects that do make money rely on corporate sponsorship, support licenses, or foundation grants, which have very little to do with whether a random user reported a bug or read your documentation.

A developer working on their own search engine project put it bluntly: “I can’t think of a single open source project that monetizes through ‘direct user participation’.”

So, the paper’s logical chain breaks at the very first link: the assumed causal relationship of “User Participation → Maintainer Income” simply doesn’t exist for most.

The Real Loss: Maintainer Motivation

That said, money is only one side of the coin.

Open source has never been just about money. Many people do it for community recognition, for that sense of achievement when “what I wrote is used and praised by others.”

On this level, Vibe Coding is indeed having an impact.

Previously, if you wrote a library, people who used it would file issues, give stars, or say on Twitter, “This library saved my life.” Now? People ask AI to write code, and the AI “borrows” logic from your library, often without the user even knowing they are using your work.

One maintainer’s sentiment is particularly stinging:

“People used to respect you for the volume and quality of your code. Now that respect is gone because no one can tell if you spent time crafting it or just ‘vibed’ it out. Stars aren’t given as freely anymore; no one is really reading your code.”

This psychological sense of loss is real, though it doesn’t necessarily mean it will “kill” open source.

The Optimist’s View

antirez takes a rather optimistic stance. He believes the AI era will bring a new wave of open source, but the development model will change — the focus will shift from how much code you can write to your software design and vision.

“Today design is more important than coding.”

He also raised an interesting point: merging valuable contributions from forks has become much easier. Before, you might have been too lazy to check what someone changed in a fork; now, you can just ask AI to filter it for you.

Another optimistic angle is that AI lowers the “cost of regret.” Previously, making an architectural decision and realizing it was wrong meant a painful refactor. Now? Just let AI rewrite it for you. This makes large-scale personal projects more feasible and fun.

The Reality of Coding with AI

Let’s get practical.

A developer maintaining a Java NLP library shared his experience: He tried asking Claude to resolve a geolocation ambiguity (Input: “California” — should it return the state or the city in Missouri?). Claude provided various prioritization strategies, but after implementation, it broke other functions in the library.

His conclusion: “LLMs don’t care about the history or design decisions of your code; they only look at the current state.”

This reminds me of my own experience. AI is indeed great at writing code “from scratch,” but for legacy projects with historical baggage and various edge cases, it often “does more harm than good.” It doesn’t understand why a piece of code is written so strangely, because it doesn’t know that three years ago, a client made a bizarre request that you had to support.

I also agree with the view that AI speeds up code generation but shifts the burden of quality assurance to the code review stage. For open-source projects that are already short-handed, this could be a problem — the average quality of AI-generated PRs is often lower than that of human-written ones.

An Ironic Fact

By the way, LLMs themselves rely on open source software to exist.

From the programming languages and libraries used to train models to the operating systems running them, and the databases storing training data, and the fact that they were trained on open-source code to begin with. Without the open-source ecosystem, LLMs wouldn’t even exist.

So, the title “Vibe Coding Kills Open Source” is quite ironic when you think about it.

The GPL Loophole

There’s another angle I hadn’t considered before: GPL might be in trouble.

Why? Because you can ask an LLM to “cleanroom” implement a new version based on a public spec, write it in another language, and release it under a more permissive license (like MIT). The LLM can guarantee it “never saw the original code,” perfectly bypassing the viral nature of GPL.

This might still be legally controversial, but technically, it’s already entirely feasible.

My Verdict

The paper’s title is clickbait, but its actual conclusion is that “vibe coding will weaken maintainer incentives,” which is a far cry from “killing open source.”

Will open source die? I don’t believe it.

But the form of open source might change. We’ll see more small tools because AI makes writing custom scripts so easy that people might prefer to “vibe” one out rather than use a general-purpose project. Big projects will still need humans; things like the Linux kernel or PostgreSQL aren’t something AI can just “vibe” into existence.

As for “needing to change how maintainers are paid” — come on, this problem has existed for decades and has nothing to do with AI.

Based on the discussion around arXiv:2601.15494