Vibe coding kills open source
61–70 of 304 posts
Re: Vibe coding kills open source
#62Re: Vibe coding kills open source
#63Small 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.
Vibe coders don't code, they let code. So LLMs democratise access to coders.
Re: Vibe coding kills open source
#64Small 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?
Re: Vibe coding kills open source
#65Small 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.
Re: Vibe coding kills open source
#66Small 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?
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
#67Earlier quoted context omitted.
More we need a new GitHub.
May I recommend SourceHut ( https://sr.ht/ )
Re: Vibe coding kills open source
#68On 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…
At some point the investors want to see profit.
Re: Vibe coding kills open source
#69Earlier 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.
Re: Vibe coding kills open source
#70Earlier 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?