Live data from Hacker News

Vibe coding kills open source

arxiv.org

171–180 of 304 posts

Re: Vibe coding kills open source

#171
post #161

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?

The vast majority of users make zero changes to the default settings of an app or device, even for software they use all the time and where some simple builtin adjustments would significantly improve their experience. I simply can't imagine a world where these same people all decide they constantly want to learn a completely unique UX for whatever piece of software they want to use.

The LLM will know how the user operates, their proclivities and brain structure, and will design UX perfectly suited to them, like a bespoke glove. They won't have to learn anything, it will be like a butler.

Re: Vibe coding kills open source

#172

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

Terraform, ansible, countless others. No community=no enterprise version, no awareness

Re: Vibe coding kills open source

#173
post #171
post #161

Earlier quoted context omitted.

The vast majority of users make zero changes to the default settings of an app or device, even for software they use all the time and where some simple builtin adjustments would significantly improve their experience. I simply can't imagine a world where these same people all decide they constantly want to learn a completely unique UX for whatever piece of software they want to use.

The LLM will know how the user operates, their proclivities and brain structure, and will design UX perfectly suited to them, like a bespoke glove. They won't have to learn anything, it will be like a butler.

Why not just say that the LLM will just do all the work while you're making up future, hypothetical capabilities of LLMs?

Re: Vibe coding kills open source

#174
post #76
post #33

Earlier quoted context omitted.

You won't have to ignore this stuff for long. Pretty soon it'll be mandatory to keep up. I've been a senior engineer doing large scale active-active, five nines distributed systems that process billions of dollars of transactions daily. These are well thought out systems with 20+ folks on design document reviews. Not all of the work falls into that category, though. There's so much plumbing and maintenance and wiring…

> I've been so not now, then?

"i used to do drugs. i still do, but i used to, too."

Re: Vibe coding kills open source

#175
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.

Re: Vibe coding kills open source

#176

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…

Right, I'd say this is the best value I've gotten out of it so far: I'm planning to build this thing in this way, does that seem like a good idea to you? Sometimes I get good feedback that something else would be better.

Re: Vibe coding kills open source

#177

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?

Why use a battle tested, secure, library that you know solves your problem when you can burden your project with custom code you need to maintain?

Re: Vibe coding kills open source

#178

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 misremembered :(

4.5 Sonnet, but because I've been stuck on 3.7 Sonnet for so long due to corporate policy I wrote the wrong thing.

And yeah corporate policy. Opus is not available. I prefer Codex for my personal coding but I have not needed to look in the Git history here yet.

Re: Vibe coding kills open source

#179

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…

Expertise won't be needed (it already isn't). One can create copies of apps with vague descriptions referencing those big apps:

"Create a copy of xyz. It needs to look and behave similarly. I want these features ... And on top of that ...". Millions decisions not needed. A handful of vague descriptions of what one wants is all it takes today. I think claude and co. can even take in screenshots.

Documentation won't be needed either IMO. Since humans won't write nor read the code. They will simply ask LLM's if they have a question.

I totally am giving up my experience with various paid SaaS this year, which I was paying for last years. Not only am I able to add the features that I was wishing for those tools to have (and would have never made it into the real app because they're niche requests), but am saving money at the same time.

And the above is just whats happening today. Claude Code is younger than 1 year old. Looking forward to come back to this thread in a year and swallow my words... but I'm afraid I won't have to.

Re: Vibe coding kills open source

#180

Related but not sure how much attention it's getting: GPL is a dead man walking since you can have any LLM cleanroom a new implementation in a new language from a public spec with verifiable "never looked at the original source" and it can be more permissively-licensed however you wish (MIT, BSD etc). case in point, check out my current deps on the project I'm currently working on with LLM assist: https://github.com/…

> which means full reads and scrubs touch more bits and inevitably brush against those error rates

Does this make sense at all? ZFS scrubs only reads the data you have, not the whole drive, and repairs data if possible. The more data you have, the more you have to validate regardless of the tools used. The BER is also just a terrible metric and is not reflective of how drives actually behave.

Post reply on HN