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.

> when LLMs can build you an custom(!) hammer or saw in a few minutes, why go to the shed?

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.

StanLLM-generated hammer: "Dear valued customer, our automated systems have flagged activity on your StanLLM account that appears to be non-compliant with our Acceptable Use Policy. As a precautionary measure your account has been suspended. If you believe this suspension is in error, feel free to contact our customer support at /dev/null^H^H^H^H^H^H^H^H^Hsupport@..."

> 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 an custom(!) hammer or saw in a few minutes, why go to the shed?

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.

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.

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.

I do not think that this is likely to be a successful model.

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.

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?

"why go to the shed"

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.

The more I experiment with quickly coding up little projects with LLMs the more I am convinced of this. There is that saying: 90% of your customers use 10% of your software's features, but they each use a different 10%. Well, the ability to quickly vibe up a small bespoke app that does that 10% AND NOTHING ELSE is here now, and it kind of solves that problem. We don't need to put up with DoEverythingBloatWare (even open source DoEverything) when you can just have the bits and pieces you actually want/need.

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.

> when LLMs can build you an custom(!) hammer or saw in a few minutes, why go to the shed?

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%.

I can speak to this directly: I've customized a few extensions I use with VSCode, (nearly) completely having the AI generate/iterate over my feature request until it works. I don't have the time to learn the details (or different languages) of the various projects, but I get huge benefit from the improvements.

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

From what - OS libraires only? Assembly?

The danger is not "Nobody uses OSS".

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

Because I will probably ask the AI for a rock instead of a bespoke hammer. If I even know what a nail is.

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

Would you trust your hand next to a saw made by an LLM?

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.

I don't think apps where people spend a lot of time are equivalent to small tools. You can vibe code a calculator but you probably spend most of your time on much more complex software.

Because it can’t really do that for any tools that matter.

Exactly, think StarTrek replicator.

Why need a tool at all when the LLM can just build the house? What is a hammer? What is a keyboard? What’s a “Drivers License”?

Because going to the shed to get a work-tested tool is still faster than waiting on an LLM and hoping it meets every use-case you're likely to run into with that tool.

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.

along that line of thinking, I've been wondering if there are better building blocks. right now we're asking llms to use the bricks designed for the human hand building a cathedral - what do the bricks look like when we want AI to build many sheds for specific use? functional programming? would the database ideas of data storage like the longhorn vapourware make a come back?

[dead]

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.

I like this take. "How things are today + LLM" is in some ways the best we can approximate because one is all we know and other side is the future unfolding before our eyes. One of the coolest things about vibe coding I find is starting with a base like django then using vibe coding to build models and templates exactly how one wants for a UIUX. Basically maybe we still need humans for the guts and low level stuff but that provides a base for fast, easy personalized customization.

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.

I was expecting this to be the point of the article when I saw the title. Popular projects appear to be drowning in PRs that are almost certainly AI generated. OpencodeCli has 1200 open at the moment[1]. Aider, which is sort of abandoned has 200 [2]. AFAIK, both projects are mostly one maintainer.

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

To me, an old guy, I would rather have LLM doing (assisting with) the code review than the actual code production. Is that stupid?

The maintainers can now do all the work themselves.

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

There is this kind of webdev-adjacent niche where the model of using documentation (or even intentionally sub-par documentation) as a marketing funnel for consulting and/or "Pro" versions is a thing. These projects are somewhat vocal about vibe coding killing their business models. If these projects really create any meaningful value is another question.

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

> If OSS didn't exist, it's highly unlikely that LLMs would have been built.

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

(rhetorical question)

> I am a huge proponent of using AI tools for software development. But until I see a vibe coded replacement for the Linux kernel, PostgreSQL, gcc, git or Chromium, I am just going to disagree with this premise.

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?

Largely my take as well.. there's also a LOT of slop and not enough polish or completeness in terms of UX and usability.

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

One major part of successful LLM-assisted coding is to not focus on code vomiting but scaffolding.

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.

I find that asking it to write a design doc first and reviewing that (both you and the bot can do reviews) gets better results.

Sounds a lot like model training and I’ve treated this sort of programming with AI exactly like that importantly making sure I have a test/train split

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

If Claude read the entire commit history, wouldn't that allow it to make choices less incongruent with the direction of the project and general way of things?

> LLMs dont care about the story, they just care about the current state of the code

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 struggles

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.

I think the solution to the latter is simply to maintain high standards in terms of structure and organization. I've always been a fan of KISS should override any other non-requirement of software. Any my non-requirement, I mean anything that is just subjective. Don't create complexity you don't actually need, or that doesn't make an outsized contribution to making other areas of the code easier to reason with.

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

And make one PR after another, i can see how happy Linus & Co. would be of all the garbage features ;-)

The real question is how much of the new wave of vibe-coded software will be able to graduate from pet project to community-maintained project.

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.

I don't trust software that has .claude in its GitHub repo.

We need a new git. (could be built on the current git)

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

As long as you hold the copyright to your "validate" project, you can dual license it. So can release it under the (A)GPL and also use it in your closed-source commercial project. I think you would need to make contributors sign a contributor license agreement (CLA) though, to continue using their contributions to "validate" in your closed-source offering.

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

Did something change? Is LLM generated stuff now able to be protected with copyrights?

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

>verifiable "never looked at the original source"

...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?

Probably fair... would also be interesting to try to limit the use of say GPL code to maintaining interoperability, not duplication of internal methods, etc. I also think that the amount of MIT/ISC/BSD, etc. licensed code, with whatever MS and other commercial entities have contributed for this use is probably enough to not be a significant difference to model quality though.

It could be a net gain for civilization if it stayed open, decentralized and off the hands of private companies, but that's not at all the case. Only tecchies care or even know about open models

Seems you are arguing that The Tragedy Of The Commons could never happen because people benefit from the Commons

There is a reasonable argument that there won’t be many new languages now that models are sufficiently trained. If anything, we may see languages optimized for models and not humans.

I've done a bit of experimentation with that. And the irony is Rust seems to fare best because of the error messages of the compiler.

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

Author here. We have the productvity-increasing effect of AI coding agents in the model (you're right, we're using "vibe coding" as a catch-all here). Our claim is that rewards to OSS developers (visibility and recognition in the dev community, future sponsorships, upsells to business users etc) fall faster than productivity increases. OSS devs lose the incentives to create software for others and respond to their needs.

Science starts with hypothesis and predictions.

Two of the authors are engaging on bluesky regarding the "clickbaityness" of the paper:

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

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

do you have experience in reviving an abandoned project? which way did you go? what would be a sensible approach?

> The productivity gains are real and large

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 even is "engagement" here? Seems like abstract harm that rationalizes whatever emotion the reader already feels.

> For those small open source tools that many of us use daily and find invaluable, I actually think vibe coding is ideal for that.

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".

There are three or four projects I've always wanted to do, but were frontloaded with a lot of complexity and drudgery.

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 think one of the things that will need to be embraced is carefully curating .md context files to give the prompts better/shared direction to contributors. Things like any new feature or fix should include a test case (in the right place), functions should re-use existing library code wherever possible, function signatures should never change in a backwards-incompatible way, any code changes should pass the linter, etc etc. And ideally ensure the agent writes code that's going to be to the maintainer's "taste".

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.

The authors try to study the effect of people not engaging directly with OSS projects because they substitute for this with a gang of chatbots, and draw the conclusion that this lack of contact with actual people means they'll be less likely to help finance OSS development.

>then you have less reason to collaborate and depend on each other vs asking your own LLM to build your own bubble

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.

Author here. By "returns" we mean any reward the developer is aiming for, whether money, recognition, world fame, future jobs, helping fellow developers. Sorry, econ jargon.

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).

Eh, I don't believe that. Smartphones have amazing cameras, and we still have photographers. There are CNC saws and mills that will ship you your perfectly realised CAD prints, yet there are still carpenters and a vibrant community of people making their own furniture. These examples go on and on.

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.

But effort / amount of work shouldn't be a deciding factor - I think anyone can churn out code if they choose to. But it's the type and quality of it.

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.

What do you think of the paper's research claims that the returns for maintainers are reduced and sharing is decreasing?

Is the maintenance due to code or due to people / politics / etc? LLMs won't change that.

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.

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

At some point the investors want to see profit.

> On the contrary, I hope vibe coding revives Linux desktop into a truly usable platform.

Oh sweet summer child.

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

And maintainance costs along with technical debt rapidly goes up.