How vibe coding is killing open source • Hacker News Board

Re: How vibe coding is killing open source

#61

Post by milowata » Wed, Feb 04, 2026, 2:45 PM UTC

Lerc wrote: post #43

milowata wrote: post #31

Earlier quoted context omitted.

I actually started writing a very similar essay, but the hyperbole got too out of hand – open source isn't dying anytime soon. I do think that SDKs and utility-focused libraries are going to mostly go away, though, and that's less flashy but does have interesting implications imo. https://meelo.substack.com/p/a-mild-take-on-coding-agents

I'm inclined to agree somewhat about libraries. I'm not entirely certain that it is a bad thing. Perhaps it would be more accurate to say libraries will change in form. There is a very broad spectrum of what libraries do. Some of the very small may just become purpose written inline code. Some of the large, hated-but-necessary libraries might get reduced into manageable chunks if people who use them can utilise AI to…

Yeah interesting...so the libraries don't necessarily go away, they just change shape into skills.

Re: How vibe coding is killing open source

#62

Post by umvi » Wed, Feb 04, 2026, 5:22 PM UTC

dayjaby wrote: post #50

umvi wrote: post #10

Earlier quoted context omitted.

> no longer any need to use a library at all As someone who works on medical device software, I see this as a huge plus (maybe a con for FOSS specifically, but a net win overall). I'm a big proponent of the go-ism "A little copying is better than a little dependency". Maybe we need a new proverb "A little generated code is better than a little dependency". Fewer dependencies = smaller cyberseucity burden, smaller reg…

I am utterly confused at how you think rewriting entire libraries have less security holes than battle-hardened libraries that 1000s of other people use.

- Generating your own left pad means you don't have to pull in an external left pad

- Which in turn means left pad doesn't show up on your SBOM

- Which in turn means CVEs won't show up for left pad when you run your SBOM through through SCA

- Which means you don't have to do any CVE triage, risk analysis, and mitigation (patching) for left pad

- It also means you don't have to do SOUP testing for left pad

Now imagine you've done that for a dozen libraries that you are only using a small piece of. That's a ton of regulatory and cybersecurity work you've saved yourself. I never claimed generating code makes your software more secure, I claimed it can reduce the regulatory and cybersecurity burden on your SDLC, which it does as demonstrated above. Taken to the extreme (0 external dependencies), your regulatory burden for SOUP and SCA goes to zero.

Re: How vibe coding is killing open source

#63

Post by cudgy » Wed, Feb 04, 2026, 6:19 PM UTC

RcouF1uZ4gsC wrote: post #8

Open source and free software was the largest transfer of wealth in the form of techne freely from the craftspeople to the business people. Knowing how to write a database could make one fabulously rich. Now the person who knows how to make and promote a simple crud app backed my MySql becomes the rich one, while the db people beg for donations. Linux killed Sun/Solaris and SGI Irix Developers have voluntarily moved…

Well said. This also aptly describes the emergence of “script kiddies“ in the early 2000’s (now comically referred to as “engineers“). Promotion of simply combining libraries that are not understood by amateurish developers into mostly poorly implemented solutions thrust upon the end users. Corporations loved the lower salaries of web developers and the efficiency of utilizing open source libraries, thereby devaluing the skilled developers whose original intent was to share their knowledge via these oss libraries. Web development was the most affected by this trend initially, and as we see now is mostly impacted by the emergence of LLM‘s.

Re: How vibe coding is killing open source

#64

Post by pjjpo » Thu, Feb 05, 2026, 12:13 AM UTC

LaurensBER wrote: post #35

observationist wrote: post #33

Things change. The barrier to entry decreased, meaning more things will get created, more people will participate in communal efforts, and quality will depend on AI capabilities and figuring out how to curate well - better tools, less friction between idea and reality, and things get better for everyone. Just because some things suck, for now , doesn't mean open source is being killed. It means software development i…

I concur, open-source will be more reputation based and no doubt, in the future, LLMs can also act as a quality gate. I work a lot with quants (who can program but are more focused on making money than on clean-code) and Opus 4.5 and Kimi 2.5 are extremely good at giving them architecture guidance. They tend to overcomplicate some things but the result is usually miles better than what they produced without LLMs.

One issue I found is that for new projects, it is much harder to market now. shownew is flooded and subreddits have turned up their spam filters high so quality projects will have trouble getting eyes without significant social activity before wanting to share. So the bar for introverts writing (not vibing) good OSS feels like it has gone up in an unfortunate way.

Re: How vibe coding is killing open source

#65

Post by lenkite » Thu, Feb 05, 2026, 10:36 AM UTC

dom96 wrote: post #7

How many others are now reluctant to open source their code because they don't want it to end up in the training for an LLM? I certainly am.

What is even the point in open sourcing code now unless it is being done specifically for the government or for a public standard? You don't get attribution, you don't get bugfixes, your human product used as a training set to make billionaires richer and permit a proliferation of LLM generated copies with README's filled with emojis and fake soundbites.

The Claude Fans here should not be overly surprised if the number of human-coded OSS projects falls off a cliff in the next couple of years. AI Companies might need to actually being paying humans for writing code to prevent model collapse.