Live data from Hacker News

How vibe coding is killing open source

hackaday.com

41–50 of 65 posts

Re: How vibe coding is killing open source

#41
post #4

Open Source isn't a tech stack or a specific way of typing syntax, it’s an ideology. It’s the belief that knowledge and tools should be free to share, study and modify. You cannot kill an idea. Whether I write a function by hand or 'vibe' it into existence with an LLM, the act of liberating that code for others to use remains the same.

What's not the same is that the LLMs used to create the code are highly centralized and controlled. I suspect it's only a matter of time until the content industries start trying to restrict what code LLMs are allowed to produce so that you can't use an LLM to bypass DRM.

> I suspect it's only a matter of time until the content industries start trying to restrict what code LLMs are allowed to produce so that you can't use an LLM to bypass DRM.

I don't think this is a possibility anymore for multiple reasons. As others have already pointed out there are already "open models" available to use and that genie can't be put back in the bottle, restricting the commercial models wouldn't fix the issue.

And secondly, I think the state of commercial LLMs show that the big tech companies behind LLMs have already become far more politically powerful than the traditional content industries. (I don't think this is good thing, but I think it is a thing).

If you had explained the LLM situation to 15-years-ago me in terms of how they are trained (on almost entirely copyrighted material) and what kind of output they could generate and told me Disney hadn't managed (or really even tried) to sue various players out of existence I wouldn't have believed it, yet here we are.

Re: How vibe coding is killing open source

#42
post #40

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…

As I think about it, I think lowering the barrier to entry does generally ruin things The internet is worse off. The sports I participate in got cheaper to start with and are worse. Cultures worse. What has gotten better because the barrier to entry is lower?

Of course this is true but seems to be one of the most underrated facts of modern society. Always it is proposed without question to expand access to things, to "democratize" them, open barriers, open borders. But this invariably lowers quality while crowding out those already enjoying them. Think of any quality club, park, vacation spot, restaurant, online forum whatever: none of these are improved for your own usage of the thing by adding more people to it at least beyond some threshold. A lot of this is zero sum, and quality is in tension with quantity.

Re: How vibe coding is killing open source

#43
post #26

I really don't like the narrative of 'X is killing Y', or 'Z is dead' Everything being treated as an existential threat. I'm also not particularly fond of the other extreme of toxic positivity where any problem is just a challenge and everybody is excited to take them on. Once seems to understate the level of agency people have and the other seems to overstate. The world is changing. Adapting does seem to be the rati…

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 strip them down to the necessary component. Projects like that are things that are a lot of work for an individual that make it easier to just bite the bullet and use the bloated mass library. Getting an opportunity to make an AI do that drudge work might lower the threshold that some of those things will be improved.

I also wonder about the idea of skills as libraries. I have already found that I am starting to put code into skills for the AI to use as templates for output. Developing code in this way would let you add the specific abilities of a library to any skill supporting AI.

A simple is this https://htmlpreview.github.io/?https://github.com/Lerc/JustS... which was generated by a skill that contains the source for the image decoders within the skill itself.

Re: How vibe coding is killing open source

#44

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 think it could be a good thing. The politics sucking the air out of projects and the entitled attitude from people that want something for free NOW was getting tiresome.

Raising barriers against AI slop will also create a good reason to ignore demanding non-AI slop as well. It might give the real contributors to open source projects some breathing space.

Re: How vibe coding is killing open source

#45

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 think you have it backwards. Barrier to entry just went up, why would I use a library when I can ask LLM to make one for me.

It shifts in a way where „left-pad” kind of thing will not happen because no one will need that kind of „library” because LLM will generate it.

I see it as a positive thing, no single schmuck will be terrorizing whole ecosystem when there will be dozens of of different LLMs that can write such code.

More people with shut in because they will be able to create something commercial or their „thing” won’t matter because LLM will be able to replicate their effort in 5 minutes so no one will be willing to pay for that.

Re: How vibe coding is killing open source

#46

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…

The barrier to entry decreased, meaning more things will get created

57 Channels and Nothin' On

https://en.wikipedia.org/wiki/57_Channels_(And_Nothin%27_On)

Re: How vibe coding is killing open source

#48

Earlier quoted context omitted.

> probably 90%+ of npm packages could probably go I feel npm gets held to an unreasonable standard. The fact is tons of beginners across the world publish packages to it. Some projects publish lots of packages to it that only make sense for those projects but are public anyway then you have the bulwark pa lager that most orgs use. It is unfair to me that it’s always held as the “problematic registry”. When you have a…

I think you are completely oblivious to the problems plaguing the NPM ecosystem. When you start a typical frontend project using modern technology, you will introduce hundreds, if not thousands of small packages. These packages get new security holes daily, are often maintained by single people, are subject to being removed, to the supply chain attacks, download random crap from github, etc. Each of them should ideal…

I'm not, in the least. I'm aware of the supply chain issues and CVEs etc.

One thing I want to separate here is number of packages is not a quality metric. For instance, a core vue project on the surface may have many different sub dependencies, however those are dependencies are sub packages of the main packages

I realize projects can go overboard with dependencies but its not in and of itself an issue. Like anything, its all about trade offs and setting good practices.

Its not like Java as an ecosystem has been immune either. The `Log4Shell` vulnerability was a huge mess.

My point isn't to bash the Java ecosystem, but nothing is immune to these issues and frequency is a fallacy reason to spread FUD around an ecosystem because it lacks context.

Re: How vibe coding is killing open source

#50
post #10
post #3

It does seem like it's harming open source in a few ways: * no longer any pressure to contribute upstream * no longer any need to use a library at all * Verbose PRs created with LLMs that are resume-padding * False issues created with LLM-detection by unsophisticated users Overall, we've lost the single meeting place of an open-source library that everyone meets at so we can create a better commons. That part is true…

> 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.
Post reply on HN