Live data from Hacker News

How vibe coding is killing open source

hackaday.com

11–20 of 65 posts

Re: How vibe coding is killing open source

#12
post #10
post #3

It does seem like it's harming open source in a few ways: * no longer any pressure to contribute upstream * no longer any need to use a library at all * Verbose PRs created with LLMs that are resume-padding * False issues created with LLM-detection by unsophisticated users Overall, we've lost the single meeting place of an open-source library that everyone meets at so we can create a better commons. That part is true…

> no longer any need to use a library at all As someone who works on medical device software, I see this as a huge plus (maybe a con for FOSS specifically, but a net win overall). I'm a big proponent of the go-ism "A little copying is better than a little dependency". Maybe we need a new proverb "A little generated code is better than a little dependency". Fewer dependencies = smaller cyberseucity burden, smaller reg…

Since code-generating AIs were likely trained on them, they won't go too far, though.

Re: How vibe coding is killing open source

#13
AI mediation between end dev and open source definitely reduces the incentives for maintainers that look to build community, visibility, reputation, collaborate with others… I also love AI so not sure what the solution could be.

Re: How vibe coding is killing open source

#14
post #3

It does seem like it's harming open source in a few ways: * no longer any pressure to contribute upstream * no longer any need to use a library at all * Verbose PRs created with LLMs that are resume-padding * False issues created with LLM-detection by unsophisticated users Overall, we've lost the single meeting place of an open-source library that everyone meets at so we can create a better commons. That part is true…

It's also now a lot easier to fork an open source project and tweak the last 10% so it works exactly as you want.

Re: How vibe coding is killing open source

#15
post #7

How many others are now reluctant to open source their code because they don't want it to end up in the training for an LLM? I certainly am.

It definitely feels less fun. Harder to get attribution, build a reputation, a community… Common driving forces for people to contribute to open source.

Re: How vibe coding is killing open source

#16
post #10
post #3

It does seem like it's harming open source in a few ways: * no longer any pressure to contribute upstream * no longer any need to use a library at all * Verbose PRs created with LLMs that are resume-padding * False issues created with LLM-detection by unsophisticated users Overall, we've lost the single meeting place of an open-source library that everyone meets at so we can create a better commons. That part is true…

> no longer any need to use a library at all As someone who works on medical device software, I see this as a huge plus (maybe a con for FOSS specifically, but a net win overall). I'm a big proponent of the go-ism "A little copying is better than a little dependency". Maybe we need a new proverb "A little generated code is better than a little dependency". Fewer dependencies = smaller cyberseucity burden, smaller reg…

> probably 90%+ of npm packages could probably go

I feel npm gets held to an unreasonable standard. The fact is tons of beginners across the world publish packages to it. Some projects publish lots of packages to it that only make sense for those projects but are public anyway then you have the bulwark pa lager that most orgs use.

It is unfair to me that it’s always held as the “problematic registry”. When you have a single registry for the most popular language and arguably most used language in the world you’re gonna see massive volume of all kinds of packages, it doesn’t mean 90% of npm is useless

FWIW I find most pypi packages worthless and fairly low quality but no ones seems to want to bring that up all the time

Re: How vibe coding is killing open source

#17
Yes, it will kill open source—at least as we know it.

I’m convinced that GitHub and GitLab will eventually stop offering their services for free if the flood of low-quality, "vibe-coded" projects—complete with lengthy but shallow documentation—continues to grow at the current rate.

The trend of rewriting existing programs ("vibe-coding" a rewrite of $PROG in Rust, for example) threatens to undermine important, battle-tested projects like SQLite. As I described in this comment: https://news.ycombinator.com/item?id=46821246.

I’m quite sure developers will increasingly close-source their work and black-box everything they possibly can. After all, source code that cannot be seen cannot be so easily "rewritten" by vibe-coders.

Re: How vibe coding is killing open source

#18
post #7

How many others are now reluctant to open source their code because they don't want it to end up in the training for an LLM? I certainly am.

Me. I've never been a maintainer for any big opensource project, so it won't make a dent on anything, but now my contributions are exactly zero.

Re: How vibe coding is killing open source

#19
post #4

Open Source isn't a tech stack or a specific way of typing syntax, it’s an ideology. It’s the belief that knowledge and tools should be free to share, study and modify. You cannot kill an idea. Whether I write a function by hand or 'vibe' it into existence with an LLM, the act of liberating that code for others to use remains the same.

What's not the same is that the LLMs used to create the code are highly centralized and controlled. I suspect it's only a matter of time until the content industries start trying to restrict what code LLMs are allowed to produce so that you can't use an LLM to bypass DRM.

There are competent open source LLMs out today. They are not highly centralized.

Re: How vibe coding is killing open source

#20
Article doesn't seem to have anything new to add to the discussion. It's just a bunch of links to previous anti-AI articles the author has written on stories we have all read before such as the collapse in new stack overflow questions.
Post reply on HN