Live data from Hacker News

Vibe coding kills open source

arxiv.org

211–220 of 304 posts

Re: Vibe coding kills open source

#211
post #208

Earlier quoted context omitted.

It could be a net gain for civilization if it stayed open, decentralized and off the hands of private companies, but that's not at all the case. Only tecchies care or even know about open models

Regardless of open or closed models, the reason it is a net gain is that the cost of software production is collapsing and will trend towards zero. Example: We can achieve more climate solutions (and faster) thanks to technological acceleration.

We just need to consume 1.21gwatts of electricity, and then we can invest in nuclear power in the past.

Re: Vibe coding kills open source

#212

Small bespoke personalized on the spot apps are the future with LLMs. The future will absolutely not be "How things are today + LLMs" The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?

StanLLM-generated hammer: "Dear valued customer, our automated systems have flagged activity on your StanLLM account that appears to be non-compliant with our Acceptable Use Policy. As a precautionary measure your account has been suspended. If you believe this suspension is in error, feel free to contact our customer support at /dev/null^H^H^H^H^H^H^H^H^Hsupport@..."

Re: Vibe coding kills open source

#213

I think it is not killing opensource. It is changing it. There are more smaller scoped projects created for specific purposes instead of creating a huge project that has gazillion features supporting everything. At least this is my experience.

Largely my take as well.. there's also a LOT of slop and not enough polish or completeness in terms of UX and usability.

Re: Vibe coding kills open source

#214

Earlier quoted context omitted.

What if there is a new domain.

Then it is new for everyone, no?

Humans can learn from new experiences. LLMs have to be retrained (continuous learning isn't good enough yet), or you have to fit enough information into the context while still having enough for the task itself.

Re: Vibe coding kills open source

#215
from abstract

> When OSS is monetized only through direct user engagement (...) Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.

so it applies to narrow slice of OSS

Re: Vibe coding kills open source

#216

Earlier quoted context omitted.

To me, an old guy, I would rather have LLM doing (assisting with) the code review than the actual code production. Is that stupid?

LLMs are great at reviewing. This is not stupid at all if it's what you want; you can still derive benefit from LLMs this way. I like to have them review at the design level where I write a spec document, and the LLM reviews and advises. I don't like having the LLM actually write the document, even though they are capable of it. I do like them writing the code, but I totally get it; it's no different than me and the…

If LLMs are great at reviewing, why do they produce the quality of code they produce?

Re: Vibe coding kills open source

#217

Small bespoke personalized on the spot apps are the future with LLMs. The future will absolutely not be "How things are today + LLMs" The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?

> when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?

once such LLMs exist, this question may be worth considering

they do NOT exist at this moment

Re: Vibe coding kills open source

#218

Small bespoke personalized on the spot apps are the future with LLMs. The future will absolutely not be "How things are today + LLMs" The paradigm now for software is "build a tool shed/garage/barn/warehouse full of as much capability for as many uses possible" but when LLMs can build you a custom(!) hammer or saw in a few minutes, why go to the shed?

Hehe, you created quite the dog pile. Here's my woof:

IMO you only need to look at the 30+ year history of Linux to see how wrong this prediction is. There will be a small group of people who do as you say, but the other 95% will happily pay for someone else to take care of their problem. Convenience is the supreme king of the American market.

Re: Vibe coding kills open source

#219

> When OSS is monetized only through direct user engagement, greater adoption of vibe coding lowers entry and sharing, reduces the availability and quality of OSS, and reduces welfare despite higher productivity. Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid. I can't think of even a single example of OSS being monetized through direct user engageme…

> what is monetized (beyond like a tip jar situation where you get some coffee money every once in a while) is primarily sponsored by enterprise users, support license sales, or through grants, or something like that

All of those examples are the "direct user engagement" in question. No one tips a tip jar that they don't see. Enterprise users don't sponsor projects or buy licenses when they don't know they are using projects they should sponsor or buy a better license.

If an LLM is automating your `npm install` you probably don't see the funding requests. Are you running `npm fund` in your spare time?

If an LLM is automating your need to lookup library documentation you probably don't see that the library's own documentation has a Ko-Fi link or GitHub Sponsors request. Would you check library websites and GitHub repos on your own for such things without the need to read their documentation?

Re: Vibe coding kills open source

#220
post #43

Something I've noticed is that AI code generation makes it easier/faster to generate code while shifting more work of the work of keeping code correct and maintainable to the code review stage. That can be highly problematic for open source projects that are typically already bottlenecked by maintainer review bandwidth. It can be mitigated by PR submitters doing a review and edit pass prior to submitting a PR. But a…

The maintainers can now do all the work themselves. With the time they save using AI, they can get much more work done. So much that having other engineers learn the codebase is probably not worth it anymore. Large scale software systems can be maintained by one or two folks now. Edit: I'm not going to get rate limited replying to everyone, so I'll just link another comment: https://news.ycombinator.com/item?id=46765…

> So much that having other engineers learn the codebase is probably not worth it anymore.

> Large scale software systems can be maintained by one or two folks now.

No, LLMs are not so powerful yet.

Post reply on HN