Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by Fnord666 on Monday February 09, @12:24PM   Printer-friendly

Vibe Coding Is Killing Open Source Software, Researchers Argue:

According to a new study from a team of researchers in Europe, vibe coding is killing open-source software (OSS) and it's happening faster than anyone predicted.

Thanks to vibe coding, a colloquialism for the practice of quickly writing code with the assistance of an LLM, anyone with a small amount of technical knowledge can churn out computer code and deploy software, even if they don't fully review or understand all the code they churn out. But there's a hidden cost. Vibe coding relies on vast amounts of open-source software, a trove of libraries, databases, and user knowledge that's been built up over decades.

Open-source projects rely on community support to survive. They're collaborative projects where the people who use them give back, either in time, money, or knowledge, to help maintain the projects. Humans have to come in and fix bugs and maintain libraries.

Vibe coders, according to these researchers, don't give back.

The study Vibe Coding Kills Open Source, takes an economic view of the problem and asks the question: is vibe coding economically sustainable? Can OSS survive when so many of its users are takers and not givers? According to the study, no.

"Our main result is that under traditional OSS business models, where maintainers primarily monetize direct user engagement...higher adoption of vibe coding reduces OSS provision and lowers welfare," the study said. "In the long-run equilibrium, mediated usage erodes the revenue base that sustains OSS, raises the quality threshold for sharing, and reduces the mass of shared packages...the decline can be rapid because the same magnification mechanism that amplifies positive shocks to software demand also amplifies negative shocks to monetizable engagement. In other words, feedback loops that once accelerated growth now accelerate contraction."

[...] According to Koren, vibe-coders simply don't give back to the OSS communities they're taking from. "The convenience of delegating your work to the AI agent is too strong. There are some superstar projects like Openclaw that generate a lot of community interest but I suspect the majority of vibe coders do not keep OSS developers in their minds," he said. "I am guilty of this myself. Initially I limited my vibe coding to languages I can read if not write, like TypeScript. But for my personal projects I also vibe code in Go, and I don't even know what its package manager is called, let alone be familiar with its libraries."

The study said that vibe coding is reducing the cost of software development, but that there are other costs people aren't considering. "The interaction with human users is collapsing faster than development costs are falling," Koren told 404 Media. "The key insight is that vibe coding is very easy to adopt. Even for a small increase in capability, a lot of people would switch. And recent coding models are very capable. AI companies have also begun targeting business users and other knowledge workers, which further eats into the potential 'deep-pocket' user base of OSS."

This won't end well. "Vibe coding is not sustainable without open source," Koren said. "You cannot just freeze the current state of OSS and live off of that. Projects need to be maintained, bugs fixed, security vulnerabilities patched. If OSS collapses, vibe coding will go down with it. I think we have to speak up and act now to stop that from happening."

He said that major AI firms like Anthropic and OpenAI can't continue to free ride on OSS or the whole system will collapse. "We propose a revenue sharing model based on actual usage data," he said. "The details would have to be worked out, but the technology is there to make such a business model feasible for OSS."

[...] "Popular libraries will keep finding sponsors," Koren said. "Smaller, niche projects are more likely to suffer. But many currently successful projects, like Linux, git, TeX, or grep, started out with one person trying to scratch their own itch. If the maintainers of small projects give up, who will produce the next Linux?"

arXiv link: https://arxiv.org/abs/2601.15494


Original Submission

 
This discussion was created by Fnord666 (652) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by ElizabethGreene on Monday February 09, @08:53PM (3 children)

    by ElizabethGreene (6748) on Monday February 09, @08:53PM (#1433155) Journal

    -1 Disagree. A code model being trained on an OSS repository costs the OSS community nothing, and as the code models get more clever, they'll enable contributions from people who otherwise would not have been able to do it before.

    I strongly prefer someone submit a vibe-coded push as opposed to a flood of AI generated security bug reports because the models don't understand where I do bounds checking.

    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by aafcac on Tuesday February 10, @01:30PM (2 children)

    by aafcac (17646) on Tuesday February 10, @01:30PM (#1433239)

    Anybody that can't be bothered to learn how to program now isn't going to be capable of handing in competent code with the use of AI either. If anything, using AI just makes it harder to verify whether or not the resultant code is any good. There's been tools out for ages that allow people to program by dragging and dropping code blocks and just editing a bit of the specifics like names, but that never translated into much of an uptick in the number of people contributing, but that itself had more of a chance than this does.

    The issues related to understanding and tracking issues with new code are a much bigger problem than simply generating new code and people seem to just want to pretend like that isn't the case. Finding a solution is usually not that hard, knowing if it's going to be an acceptable solution without major issues in terms of security, performance or maintainability is a lot harder.

    • (Score: 2) by ElizabethGreene on Sunday February 15, @01:53PM (1 child)

      by ElizabethGreene (6748) on Sunday February 15, @01:53PM (#1433733) Journal

      I agre with your last point very much. Getting good enough to sniff test code has always been difficult and a critical skill. I'm curious to see if doing it constantly while vibe coding will teach that skill faster

      • (Score: 2) by aafcac on Sunday February 15, @04:23PM

        by aafcac (17646) on Sunday February 15, @04:23PM (#1433740)

        My gut is telling me that it's going to depend a lot on how it's done and what language. Some languages like Perl lend themselves more to it due to being fairly conservative with changes and having a bunch of it to train on. It's also going to depend on people having the self-discipline to not use it as a way of avoiding doing any learning. For me personally, I don't generally use it as most of the stuff I want to know about has been done by somebody online and has an answer. AI does that a bit faster, but often times strips away the explanation and may be hallucinating.

        Personally, I do think think there's some value to vibe coding potentially for one off things that solve a particular user's problems, I'd just be worried about what happens when that sort of code gets distributed. The only time I've personally used it was for homeassistant to turn my hallway light on and off based on the position of the sun as well as turning it off if it's turned on when it's supposed to be off after a delay of a few minutes. I probably could have coded it myself, but asking an AI just made more sense as there wasn't really anything particularly nefarious that could be slipped in there and the work wasn't really worth it.