Vibe coding kills open source

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.

Because software developers typically understand how to implement a solution to problem better than the client. If they don't have enough details to implement a solution, they will ask the client for details. If the developer decides to use an LLM to implement a solution, they have the ability to assess the end product.

The problem is software developers cost money. A developer using an LLM may reduce the cost of development, but it is doubtful that the reduction in cost will be sufficient to justify personalized applications in many cases. Most of the cases where it would justify the cost would likely be in domains where custom software is in common use anyhow.

Sure, you will see a few people using LLMs to develop personalized software for themselves. Yet these will be people who understand how to specify the problem they are trying to solve clearly, will have the patience to handle the quirks and bugs in the software they create, and may even enjoy the process. You may even have a few small and medium sized businesses hiring developers who use LLMs to create custom software. But I don't think you're going to see the wholesale adoption of personalized software.

And that only considers the ability of people to specify the problem they are trying to solve. There are other considerations, such as interoperability. We live in a networked world after all, and interoperability was important even before everything was networked.

1) Your specific analogy is kinda missing something important: I don't want my tools working differently every time I use them, also it's work to use LLMs. A hammer is kind of a too-simple example, but going with it anyway: when I need a hammer, I don't want my "LLM" generating a plastic one, then having to iterate for 30 minutes to get it right. It takes me far less than 30 minutes to go to my shed. A better example is would be a UI, even if it was perfect, do you want all the buttons and menus to be different every time you use the tool? Because you generate a new one each time instead of "going to the shed"?

2) Then there's the question, can an LLM actually build, or does it just regurgitate? A hammer is an extremely we'll understood tool, that's been refined over centuries, so I think an LLM could do a pretty good job with one. There are lots of examples, but that also means the designs the LLM is referencing are probably better than the LLM's output. And then for things not like that, more unique, can the LLM even do it at all or with a reasonable amount of effort?

I think there's a modern phenomenon where making things "easier" actually results in worse outcomes, a degraded typical state vs. the previous status quo, because it turns what was once a necessity into a question of personal discipline. And it turns out when you remove necessity, a lot of people have a real hard time doing the best thing on discipline alone. LLMs might just enable more of those degenerate outcomes: everyone's using "custom" LLM generated tools all the time, but they all actually suck and are worse than if we just put that effort into designing the tools manually.

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.

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.

When (not if) software breaks in production, you need to be able to debug it effectively. Knowing that external libraries do their base job is really helpful in reducing the search space and in reducing the blast radius of patches.

Note that this is not AI-specific. More generally, in-house implementations of software that is not your core business brings costs that are not limited to that of writing said implementation.

Also, you don't have to fear breaking updates--you know for sure that the software's UI will not just change out from under you because some designer had to pad their portfolio. Or that you're not going to lose a critical feature because the developer decided to refactor and leave it out.

I'm currently going through and looking at some of the bigger, bloated, crashing slow-moving software I use and working on replacements.

Because I thought I needed a hammer for nails (employee payroll) but then I realized I also need it to screw (sales), soldering (inventory management) and cleanup (taxes).

Oh and don't forget that next month the density of iron can lower up to 50%.

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.

I very much like to use the years of debugging and innovation others spent on that very same problem that I'm having.

- PRO Deployer

- MS Typescript

- Typescript-Go

- a bespoke internal extension to automate a lot of housekeeping when developing against tickets (git checks, branch creation, stash when switching, automatically connecting and updating ticket system)

Whatever it is, the future will also certainly not be what it was a couple decades ago - that is, every one inventing their own solution to solved problems, resulting in a mess of tools with no standardization. There is a reason libraries/frameworks/etc exist.

You go to the shed because you know the hammer has undergone extensive testing and won’t immediately be hacked, costing you hundreds of millions.

I do not suspect that we will stay in an individualized programs Tower of Babel situation, if we ever enter it in the first place.

It's anyone's guess as to what we end up settling on, of course. This is just a guess of mine.

And many businesses do, and it works, until it doesn't. I agree with you; that's the future I'm seeing for ad-hoc LLM apps.

The danger is not "Nobody uses OSS".

The danger is "building software becomes exponentially more difficult without a commons to build from".

once such LLMs exist, this question may be worth considering

they do NOT exist at this moment

Otherwise we'll all individually be burning power via GPUs to reinvent the wheel thousands of times.

Also, look at the level of effort to maintain any bespoke machine. Assembly lines with interchangeable parts were a big deal for a reason. That follows with software via standard libraries and APIs. If you reinvent your software wheel every time, we'll all have careers trying to fix the deluge of slop that has been generated.

Now that LLMs can do it while I make coffee, I can do more useful things with my time like writing business code and posting on HN.

Beyond that, meh.

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.

I had a job where in short we had a lot of pain points with software that we had no resources permitted to fix them. With a mix past experience, googling I started writing some internal web based tools to fix these gaps. Everyone was happy. This is where I see vibe coding being really helpful in the higher level stuff like higher level scripting and web based tools. Just my opinion based on my experience.

[1] https://github.com/anomalyco/opencode/pulls [2] https://github.com/Aider-AI/aider/pulls

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=46765785

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?

would anyone want SlopHub Copilot if it had been trained exclusively on Microsoft's code?

(rhetorical question)

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?

I was under the impression that copyright was only available for works created by people.

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.

...erm.

To adress the elephant in the room: Who exactly is supposed to be verifiable to never have looked at the original source? You or the LLM?

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"

Document, document, document: your architecture, best practices, preferences (both about code and how you want to work with the LLM and how do you expect it to behave it).

It is time consuming, but it's the only way you can get it to assist you semi-successfully.

Also try to understand that LLM's biggest power for a developer is not in authoring code as much as assistance into understanding it, connecting dots across features, etc.

If your expectation is to launch it in a project and tell it "do X, do Y" without the very much needed scaffolding you'll very quickly start losing the plot and increasing the mess. Sure, it may complete tasks here and there, but at the price of increasing complexity from which it is difficult for both you and it to dig out.

Most AI naysayers can't be bothered with the huge amount of work required to setup a project to be llm-friendly, they fail, and blame the tool.

Even after the scaffolding, the best thing to do, at least for the projects you care (essentially anything that's not a prototype for quickly validating an idea) you should keep reading and following it line by line, and keep updating your scaffolding and documentation as you see it commit the same mistakes over and over. And part of scaffolding requires also to put the source code of your main dependencies. I have a _vendor directory with git subtrees for major dependencies. LLMs can check the code of the dependencies, the tests, and figure out what they are doing wrong much quicker.

Last but not least, LLMs work better with certain patterns, such as TDD. So instead of "implement X", it's better to "I need to implement X, but before we do so, let's setup a way for testing and tracking our progress against". You can build an inspector for a virtual machine, you can setup e2es or other tests, or just dump line by line logs in some file. There's many approaches depending on the use case.

In any case, getting real help for LLMs for authoring code (editing, patching, writing new features) is highly dependent on having good context, good setup (tests, making it write a plan for business requirements and one for implementation) and following and improving all these aspects as you progress.

Make sure there’s a holdout the agent can’t see that it’s measured against. (And make sure it doesn’t cheat)

https://softwaredoug.com/blog/2026/01/17/ai-coding-needs-tes...

You have to tell it about the backstory. It does not know unless you write about it somewhere and give it as input to the model.

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.

If they don't exist, AND the author is comitted to maintaining them instead of just putting it online, sure. But one issue I see is that a lot of these tools you describe already exist, so creating another one (using code assist tools or otherwise) just adds noise IMO.

The better choice is to research and plan (as you say in your first sentence) before comitting resources. The barrier to "NIH" is lowered through code assistants, which risks reducing collaboration in open source land in favor of "I'll just write my own".

Granted, "I'll write my own" has always felt like it has a lower barrier to entry than "I'm going to search for this tool and learn to use it".

Maybe the best feature of vibe coding is that it makes the regret factor of poor early choices much lower. Its kind of magic to go "you know what, I was wrong, let's try this approach instead" and not having to spend huge amounts of time fixing things or rewriting 80% of the project.

It's made it a lot more fun to try building big projects on my own, where I would go into decision paralysis or prematurely optimize and never start the meat or learning of the core project.

Its also been nice to have agents review my projects for major issues, so I feel more confident sharing them.

I haven't worked out how to do this for my own projects.

Once you've set it up it's not too hard to imagine an AI giving an initial PR assessment... to discard the worst AI slop, offer some stylistic feedback, or suggest performance concerns.

It feels that vibe coding may exacerbate fragmentation (10 different vibe-coded packages for the same thing) and abandonment (made it in a weekend and left it to rot) for open source software.

> One incredible thing was the ability to easily merge what was worth merging from forks, for instance

I agree, this is amazing, and really reduces the wasted effort. But it only works if you know what exists and where.

I have had a lot of conversations with Claude about it and it supports that theory.

Sometimes having dozens of one-off scripts is easier/simpler than trying to create the uber-flexibly one tool does all solution.

Also it's a formal system and process, "vibe" coding is anything but. Call me curmudgeony (?) but I don't think "vibe coding" should be a phrase used to describe LLM assisted software engineering in large / critical systems.

At some point the investors want to see profit.

Oh sweet summer child.

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

And maintainance costs along with technical debt rapidly goes up.

https://bsky.app/profile/gaborbekes.bsky.social/post/3md4rga...

(Note, I receive a thanks in the paper.)

This is also just untrue. There is a study showing that the productivity gain is -20%, developers (and especially managers) just assume it is +25%. And when they are told about this they still feel they are +20% faster. It's the dev equivalent of mounting a cool-looking spoiler to your car.

There are productivity gains, but they're in the fuzzy tasks like generating documentation and breaking up a project into bite-sized tasks. Or finding the right regex or combination of command line flags, and that last one I would triple verify if it was anything difficult to reverse.

What's interesting in reading comments like this is reading the same type of message across a bunch of different fields and aspects of life.

"When continents move, not only the weather changes"

If GenAI keeps increasing it's abilities and doesn't bankrupt a number of companies first, I think it's going to make a lot of people bubbles that encompass their entire lives. It's not difficult to imagine little pockets of hyperreality were some peoples lives are only feed by generated content and their existence starts to behave more like a video game than having any grounding in the physical. It's going to be interesting what the fractured remains of society look like in that future.

AI agents can select and load the appropriate packages and libraries without the user even knowing the name of the library, let alone that of the developer. This reduces the visibility of developers among users, who are now less likely to give a star, sponsor, offer a job, recommend the library to others etc.

Even as a business user, say an agency building websites, I could have been a fedn of certain js frameworks, hosting meetups, buying swags, sponsoring development. I am less likely to do that if I have no idea what framework is powering the websites I build.

Our argument is that rewards fall faster with vibe coding than productivity increases. OSS developers lose motivation, they stop maintaining existing libraries, don't bother sharing new ones (even if they keep writing a lot of code for themselves).

Without any kind of offence implied: As maintainer of a few open source projects, I'm happy if it stops being an employability optimisation vector. Many of the people who don't code for fun but to get hired by FAANG aren't really bringing joy to others anyway.

If we end up with a small web of enthusiasts who write software for solving challenges, connecting intellectually with likeminded people, and altruism—then I'm fine with that. Let companies pay for writing software! Reduce the giant dependency chains! Have less infrastructure dedicated to distributing all that open source code!

What will remain after that is the actual open source code true to the idea.

Nobody cares if you wrote 5000 LOC, what they care about is what it does, how it does it, how fast and how good it does it, and none of those qualifiers are about volume.