Live data from Hacker News

Vibe coding kills open source

arxiv.org

1–10 of 304 posts

Re: Vibe coding kills open source

#2
I 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 it free to use.

I 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

#4
generative 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 generative ai

this might be the most directly noticeable change for users of niche open source

Re: Vibe coding kills open source

#5
"Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns."

I 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

#6
I have been trying to use Claude code to help improve my opensource Java NLP location library.

However 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

#7
post #4

generative 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…

What do you think of the paper's research claims that the returns for maintainers are reduced and sharing is decreasing?

Re: Vibe coding kills open source

#8
I 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 you have, how the software should look like, behave, what it should do to be useful. Today design is more important than coding.

Re: Vibe coding kills open source

#9
post #8

I 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…

We need a new git. (could be built on the current git)

> 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

#10
post #2

I 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…

> For those small open source tools that many of us use daily and find invaluable, I actually think vibe coding is ideal for that.

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".

Post reply on HN