Live data from Hacker News

Vibe coding kills open source

arxiv.org

61–70 of 304 posts

Re: Vibe coding kills open source

#61
There's a balance between coding by hand and vibe coding that is important. The less you understand the code, the more boring maintaining the software becomes. It's OK for throw away code, but not for serious open source projects. Use it as a powerful tool rather than your replacement.

Re: Vibe coding kills open source

#62
I wonder how many OSS projects are using AI to actively squash bugs so their projects are more rock-solid than before. Also, seems to me if your project underwent a full AI standardized code-quality check (using 2 or 3 AI models), it would be considered the "standard" from which other projects could use. For example, if you needed a particular piece of code for your own project, the AI tooling could suggest leveraging an existing gold-standard project.

Re: Vibe coding kills open source

#63
post #48

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?

I think that's an optimistic interpretation of how good LLMs are? But I think the reality is: LLMs democratise access to coding. In a way this decreases the market for complete solutions, but massively increases the audience for building blocks.

>LLMs democratise access to coding

Vibe coders don't code, they let code. So LLMs democratise access to coders.

Re: Vibe coding kills open source

#64

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?

Because whatever you use a LLM to build will inevitably need more features added or some kind of maintenance performed. And now you're spending $200+/mo on LLM subscriptions that give you a half-assed implementation that will eventually collapse under its own weight, vs just buying a solution that actually works and you don't have to worry about it.

Re: Vibe coding kills open source

#65

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?

Maybe true for some apps, but I suspect we will still have a vibrant ecosystem of package managers and open source libraries and coding agents will know how to use them.

What would be the point of that? If LLMs ever actually become competent, surely they can just implement what they need.

Re: Vibe coding kills open source

#66

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?

I think you're missing the enormous value in apps being standardized and opinionated. Standardized means that in addition to documentation, the whole internet is available to help you. Opinionated means as a user of an app in a new domain, you don't have to make a million decisions about how something should work to just get started.

Sure, there will be more personalized apps for those who have a lot of expertise in a domain and gain value from building something that supports their specific workflow. For the vast majority of the population, and the vast majority of use cases, this will not happen. I'm not about to give up the decades of experience I've gained with my tools for something I vibe coded in a weekend.

Re: Vibe coding kills open source

#68

On the contrary, I hope vibe coding revives Linux desktop into a truly usable platform. e.g. Vibe coding defeats GNOME developers' main argument for endlessly deleting features and degrading user experience - that features are ostensibly "hard to maintain". Well, LLMs are rapidly reducing development costs to 0. The bottleneck for UI development is now testing, and here desktop Linux has advantage - Linux users have…

You don't think the current prices of LLMs will stay?

At some point the investors want to see profit.

Re: Vibe coding kills open source

#69
post #47

Earlier quoted context omitted.

> I started the project in my brain and it has many flaws and nuances which I think LLMs are struggling to respect. The project, or your brain? I think this is what a lot of LLM coders run into - they have a lot of intrinsic knowledge that is difficult or takes a lot of time and effort to put into words and describe. Vibes, if you will, like "I can't explain it but this code looks wrong"

I've been a skeptic, but now that I'm getting into using LLMs, I'm finding being very descriptive and laying down my thoughts, preferences, assumptions, etc, to help greatly. I suppose a year ago we were talking about prompt engineers, so it's partly about being good at describing problems.

One trick to get out of this scenario where you're writing a ton is to ask the model to interview until we're in alignment on what is being built. Claude and open code both have an AskUserQuestionTool which is really nice for this and cuts down on explanation a lot. It becomes an iterative interview and clarifies my thinking significantly.

Re: Vibe coding kills open source

#70

Earlier quoted context omitted.

I personally don't have any trouble with that. Using Sonnet 3.7 in Claude Code, I just ask it to spelunk the git history for a certain segment of the code if I think it will be meaningful for its task.

Out of curiosity, why 3.7 Sonnet? I see lots of people saying to always use the latest and greatest 4.5 Opus. Do you find that it’s good enough that the increased token cost of larger/more recent models aren’t worth it? Or is there more to it?

I suspect they use the LLM for help with text editing, rather than give it standalone tasks. For that purpose a model with 'thinking' would just get in the way.
Post reply on HN