Vibe coding kills open source
arxiv.org
Vibe coding kills open source
1–10 of 304 posts
Re: Vibe coding kills open source
#2I was very sceptical but I will admit I think vibe coding has a place in society, just what it is yet is still to be determined. It can't help most for sure but it can help some in some situations.
Re: Vibe coding kills open source
#3Re: Vibe coding kills open source
#4more open source, better open source
perhaps also more forking (not only absolute but also relative)
contribution dynamics are also changing
I'm fairly optimistic that generative ai is good for open source and the commons
what I'm also seeing is open source projects that had not so great ergonomics or user interfaces in general are now getting better thanks to generative ai
this might be the most directly noticeable change for users of niche open source
Re: Vibe coding kills open source
#5I think the title is clickbait.
The conclusion is:
"Vibe coding represents a fundamental shift in how software is produced and consumed. The productivity gains are real and large. But so is the threat to the open source ecosystem that underpins modern software infrastructure. The model shows that these gains and threats are not independent: the same technology that lowers costs also erodes the engagement that sustains voluntary contribution."
The dangers I see rather in projects drowning in LLM slop PR's, instead of less engagement.
And the benefits of LLMs to open source in lowering the cost to revive and maintain (abandoned) projects.
Re: Vibe coding kills open source
#6However trying to get it to do anything other than optimise code or fix small issues it struggles. It struggles with high level abstract issues.
For example I currently have an issue with ambiguity collisions e.g.
Input: "California"
Output: "California, Missouri"
California is a state but also city in Missouri - https://github.com/tomaytotomato/location4j/issues/44
I asked Claude several times to resolve this ambiguity and it suggested various prioritisation strategies etc. however the resulting changes broke other functionality in my library.
In the end I am redesigning my library from scratch with minimal AI input. Why? because I started the project without the help of AI a few years back, I designed it to solve a problem but that problem and nuanced programming decisions seem to not be respected by LLMs (LLMs dont care about the story, they just care about the current state of the code)
Re: Vibe coding kills open source
#7generative ai increases ambition, lowers barriers more open source, better open source perhaps also more forking (not only absolute but also relative) contribution dynamics are also changing I'm fairly optimistic that generative ai is good for open source and the commons what I'm also seeing is open source projects that had not so great ergonomics or user interfaces in general are now getting better thanks to generat…
Re: Vibe coding kills open source
#8Re: Vibe coding kills open source
#9I believe we will see a new huge wave of useful open source software. However don't expect the development model to stay the same. I was finally able to resurrect a few projects of mine, and many more will come. One incredible thing was the ability to easily merge what was worth merging from forks, for instance. The new OSS will be driven not much by the amount of code you can produce, but from the idea of software y…
> One incredible thing was the ability to easily merge what was worth merging from forks, for instance
I agree, this is amazing, and really reduces the wasted effort. But it only works if you know what exists and where.
Re: Vibe coding kills open source
#10I think vibe coding would greatly struggle with large open source projects unless your planning was exceptional and your comments on optimal coding style was exceptional, however...... For those small open source tools that many of us use daily and find invaluable, I actually think vibe coding is ideal for that. It can make a functional version quickly and you can iterate and improve it, and feel no loss for making i…
If they don't exist, AND the author is comitted to maintaining them instead of just putting it online, sure. But one issue I see is that a lot of these tools you describe already exist, so creating another one (using code assist tools or otherwise) just adds noise IMO.
The better choice is to research and plan (as you say in your first sentence) before comitting resources. The barrier to "NIH" is lowered through code assistants, which risks reducing collaboration in open source land in favor of "I'll just write my own".
Granted, "I'll write my own" has always felt like it has a lower barrier to entry than "I'm going to search for this tool and learn to use it".