Vibe coding kills open source

Did you read it?

It isn't saying that LLMs will replace major open source software components. It said that the "reward" for providing, maintaining and helping curate these OSS pieces; which is the ecosystem they exist in, just disappears if there is no community around it, just an LLM ingesting open source code and spitting out a solution good or bad.

We've already seen curl buckle under the pressure, as their community minded, good conscious effort to give back to security reports, collapsed under the weight of slop.

This is largely about extending that thesis to the entire ecosystem. No GH issues, no PRs, no interaction. No kudos on HN, no stars on github, no "cheers mate" as you pass them at a conference after they give a great talk.

Where did you get that you needed to see a Linux kernel developed from AI tools, before you think the article's authors have a point?

A good question but there's a good answer: Debugged and tested code.

And by that, I mean the FULL spectrum of debugging and testing. Not just unit tests, not even just integration tests, but, is there a user that found this useful? At all? How many users? How many use cases? How hard has it been subjected to the blows of the real world?

As AI makes some of the other issues less important, the ones that remain become more important. It is completely impossible to ask an LLM to produce a code base that has been used by millions of people for five years. Such things will still have value.

The idea that the near-future is an AI powered wonderland of everyone getting custom bespoke code that does exactly what they want and everything is peachy is overlooking this problem. Even a (weakly) superhuman AI can't necessarily anticipate what the real world may do to a code base. Even if I can get an AI to make a bespoke photo editor, someone else's AI photo editor that has seen millions of person-years of usage is going to have advantages over my custom one that was just born.

Of course not all code is like this. There is a lot of low-consequence, one-off code, with all the properties we're familiar with on that front, like, there are no security issues because only I will run this, bugs are of no consequence because it's only ever going to be run across this exact data set that never exposes them (e.g., the vast, vast array of bash scripts that will technically do something wrong with spaces in filenames but ran just fine because there weren't any). LLMs are great for that and unquestionably will get better.

However there will still be great value in software that has been tested from top to bottom, for suitability, for solving the problem, not just raw basic unit tests but for surviving contact with the real world for millions/billions/trillions of hours. In fact the value of this may even go up in a world suddenly oversupplied with the little stuff. You can get a custom hammer but you can't get a custom hammer that has been tested in the fire of extensive real-world use, by definition.

Oh sweet summer child.

> Well, LLMs are rapidly reducing development costs to 0.

And maintainance costs along with technical debt rapidly goes up.

It does not struggle, you struggle. It is a tool you are using, and it is doing exactly what you're telling it to do. Tools take time to learn, and that's fine. Blaming the tools is counterproductive.

If the code is well documented, at a high level and with inline comments, and if your instructions are clear, it'll figure it out. If it makes a mistake, it's up to you to figure out where the communication broke down and figure out how to communicate more clearly and consistently.