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.

Archive: http://archive.today/sgl5M

all 10 comments

sorted by: hot top controversial new old
[–] 13 points 9 months ago

Vibe Coding is Killing Open Source Software

FTFY. The only difference is that with FOSS the slop is visible to all.

  • source
  • [–] 21 points 9 months ago (3 children)

    It really is time for UBI - this would take financial pressure off of OSS coders (and everyone else) and ensure that there will always be new source material for the data hungry AI companies.

  • source
  • hideshow 3 child comments
  • [–] 20 points 9 months ago (2 children)

    its time for ubi for many reasons, and this is one of them indeed

  • source
  • parent
  • hideshow 2 child comments
  • [–] 6 points 9 months ago (1 child)

    Agreed. Would be actually cool if the reason UBI gets realized is the need for human creativity in all their forms - if big tech would push in that direction i couldn't even argue against it.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 5 points 9 months ago

    i think the reason we do not have ubi universally is it would remove one of the biggest leverages companies have. If you dont have to worry about becoming homeless and starving to death, you can't be coerced into accepting any work for shitty pay. And people who dont have so many worries might start thinking about things beyond immidiate survival and how to distract themselves from it.

  • source
  • parent
  • [–] 6 points 9 months ago (1 child)

    “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

    "Monetize direct user engagement", does that mean their argument is that AI makes it so people don't need to pay devs to handhold them through using very user unfriendly software?

  • source
  • hideshow 1 child comment
  • [–] 9 points 9 months ago

    They give the example of Tailwind CSS, who sell UI blocks/kits and templates. I think that sounds like more added value than just pay me to help you use my software.

    This is already happening. Last month, Tailwinds—an open source CSS framework that helps people build websites—laid off three of its four engineers. Tailwinds is extremely popular, more popular than it’s ever been, but revenue has plunged.

    Tailwinds head Adam Wathan explained why in a post on GitHub. “Traffic to our docs is down about 40% from early 2023 despite Tailwind being more popular than ever,” he said. “The docs are the only way people find out about our commercial products, and without customers we can't afford to maintain the framework.

    Even for projects that don't advertise commercial products, I can believe that not needing to leave the chat/IDE to do anything leads to less traffic on GitHub etc, which is where the donate buttons are for ex.

  • source
  • parent
  • [–] -2 points 9 months ago (2 children)

    I can walk through tricky logic.

    I can pentest and determine issues or if a solution works.

    I dont know what is important. I dont know how to rebase git commits and get a pat token unless ai is holding my hand.

    I right now only vibe code but I then deep dive through the finalized commits. I am not a programmer by trade and at best I'm a sloperator.

    I think my code contributions are helpful.

  • source
  • hideshow 2 child comments
  • [–] 7 points 9 months ago* (1 child)

    What types of projects do you contribute to? Do you indicate that your contributions are done using AI?

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago* (last edited 9 months ago)

    So far, I have made a full stack server on a rpi from only ai and pentesting. It is deployed (live and used by my coworkers as a part of their workday). I intend to open source it once I understand more about git.

    I recently have made one pull request on one project that js very well maintained and I indicated that I used ai and it is really eye opening to see what good development/maintaining looks like.

    I am currently doing a deep dive into each of the feedback notes (left by a collaborator). I am by no means fast as I'm trying to max my learning from each scrap of interaction and error. Several concepts are hard for me to remember well so I use my high level memory and commands to the ai each time they come up.

  • source
  • parent
  • 12 comments in c/fuck_ai@lemmy.world view that post
    [–] 11 points 9 months ago

    AI slop kills all that it touches. Art, Music, Movies, Open/Closed source software, journalism, education, the list seems endless.

  • source
  • [–] 11 points 9 months ago

    The possible impact first hit me when I saw the genAI policy on the Asahi Linux site: https://asahilinux.org/docs/project/policies/slop/

    Tl;dr is that because Asahi is a project running on super custom hardware, there is no way to be sure LLM generated code is not based on proprietary (Apple-owned) code.

  • source
  • [–] 17 points 9 months ago (5 children)

    Probably not relevant to the article, I had to rant. I'm drunk, and suffering!

    I'm trying the old vibe coding, except with actual specs. I feel like I have to. I hate it.

    I think refining the spec/prompt with Claude makes sense. I found it helped me crystallise my spec and highlight gaps & pitfalls.
    At which point, I should've just coded it.
    I'd have known what it does, and it would be exactly what I needed.
    But I figured I'd see what Claude could do.

    So, my "dev->staging->prod" (project isn't in production state yet, thought it would be good to try AI on something) database migration system with a planning, apply and rollback stage was built by Claude.
    There are system tables that should migrate fully (but allow for review if they are structurally different) and there are data tables that should only alter schema (not affect data). It's decently complex that it would take me a week or so to write and generate, but maybe I can spend a day or 2 writing a spec and seeing what clause can do.

    It wanted to use python, and told me that migra is outdated and tried to generate something that would do it all.
    I told it to use results (the migra replacement), and after convincing it that results was the actual library name and that it can produce schema differences (and telling it that it is a different API than migra cause it tried to use it as if it was migra, and.... So much wasted time!), I finally got working code. And all the logs and CLI etc resulted in SUCCESS messages.
    Except that tables are named like "helloThere" were ignored by it, cause it hadn't considered tables might have uppercase. So I got it to fix that. And it's working code.

    It looks nicely complex with sensible file names.
    Looking at the code: there are no single responsibilities, no extensibility. It's actually a fucking mess. Variables sent all over the place, things that should be in the current command context being randomly generated, config hard coded, randomly importing a function from another file (and literally the only place that other function is used) because.... I don't know.
    It's just a bunch functions that does stuff, named be impressive, in files that are named impressively (ignoring the content). And maybe there are context related functions in the same file, or maybe there are "just does something that sounds similar" functions.

    The logging?
    Swallows actual errors, and gives an expected error messaged. I just want actual errors!

    It's hard to analyse the code. It's not that it doesn't make sense from a single entry point. It's more that "what does this function do" doesn't make sense in isolation.
    "Where else might this be a problem" has to go to Claude, cause like fuck could I find it it's probably in a functionally similar function with a slightly different name and parameters or some bullshit.

    If I didn't know better, and looked at similar GitHub projects ... Yeh, it seems appropriate.

    It is absolutely "manager pleasing complexity".
    But it does work, after telling it how to fix basic library issues.

    Now that it works, I'm getting Claude to refactor it into something hopefully more "make sure functions are relevant to the class they are in" kinda thing. I have low expectations

    I don't EVER want to have to maintain or extend Claude generated code.
    I have felt that all the way through this experiment.
    It looks right. It might actually work. But it isn't maintainable.
    I'm gonna try and get it to be maintainable. There has to be a way.
    Maybe my initial 4-page spec accidentally said "then randomise function location".

    I'm gonna try Claude for other bits and pieces.
    Maybe I'll draw some inspiration from this migration project that Claude wrote (if I can find all the bits) and refactor it into something maintainable (now that I have reference implementations that seems to work, no matter how convolutedly spread they are)

  • source
  • hideshow 5 child comments
  • [–] 11 points 9 months ago

    I’m going to say something that might make you throw up in your mouth a little bit…

    I think you’re not supposed to care that you cannot maintain the code. That’s the ai’s job now.

    You are now a manager. You write the specs and complain when things don’t work right.

    It’s a different job entirely.

  • source
  • parent
  • [–] 8 points 9 months ago (1 child)

    We use AI to help code at work. it does a good job at creating some boiler plate stuff, but I definitely wouldn't use it to create super intricate stuff. It will create stuff that definitely doesn't work and acts so confident about it.

    It's really funny when you can literally see where it is calling incorrect functions and tell it no. It fixes it, and then 2 or 3 prompts later it goes back to calling those wrong functions again.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 9 months ago

    I haven't experienced "2 or 3 prompts later" regression.
    I have found asking it to queue changes until I ask for it to work on the queue.
    Maybe ask it to produce a single file for review, or tell it how to modify a file (and why, it likes an explanation).
    But always stack up changes, ask it to review it's queue of changes etc.
    Then ask it to do it in a one-er.
    Although, this is the first time claude said such a request will take a long time (instead of showing it's working/thinking and doing it is 20 minutes).
    Maybe this is when it starts forgetting why it did things.

  • source
  • parent
  • [–] 4 points 9 months ago

    I don't EVER want to have to maintain or extend Claude generated code.

    I think this is the crux of it. I've experimented with getting AI to fix things, create code blocks. It's really impressive what it can do.

    Except, yeah, the code is an utter mess. On the surface it looks good, but when you dig into it it's totally unmaintainable.

    I got it to write some Grok patterns for some logging software, mostly because there were so many variants on logs from some piece of software that it would have been a nightmare to do it all manually without missing something (and I'm lazy and wanted to see if it could be used for this).

    It did it and they work (after a few revisions). However it has created a separate pattern for every little variation. If I'd done it by hand I would have used more complex patterns, but less of them. As a result, any tiny little problem requires changing about four different patterns.

  • source
  • parent
  • load more comments (1 reply)
    [–] 8 points 9 months ago (1 child)

    GitHub should have insight on new repositories and repositories that are gaining files like CLAUDE.md and AGENTS.md that kind of tip off the use of AI coding.

    My guess is there's a super long tail of projects people are releasing as open source that were vibe coded to solve some simple problem. Most will likely fall into abandonment or never reach any amount of viability.

    On the other hand the cost of starting a project to solve an interesting problem has never been lower. It's never been easier to take a swing at building something cool that people might like. This should expose new opportunities that haven't been attempted yet.

    My intuition says it's not all bad. It's like selling hammers to people who aren't licensed construction workers. Yeah, some stuff will get built that should not be built.

  • source
  • hideshow 1 child comment
  • load more comments (1 reply)
    [–] 6 points 9 months ago

    They don’t have to argue. We pretty much all agree.

    Unless they like arguing – I won’t judge.

  • source
  • [–] 2 points 9 months ago

    That's a feature.

  • source