Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vibe coding kills open source

arxiv.org

Post reply on HN
Print view View original

221–230 of 304 posts

Re: Vibe coding kills open source

#221

Post by matkoniecz »

pgroves wrote: post #159
nicoburns wrote: post #37

Something I've noticed is that AI code generation makes it easier/faster to generate code while shifting more work of the work of keeping code correct and maintainable to the code review stage. That can be highly problematic for open source projects that are typically already bottlenecked by maintainer review bandwidth. It can be mitigated by PR submitters doing a review and edit pass prior to submitting a PR. But a…

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

Even not-so popular niche projects are getting LLM spam. Curiously, at least where Ia m active most comes from account with India-related usernames.

Some are opening PRs, some are posting comments in issues that repeat what was said already, just in more words.

Re: Vibe coding kills open source

#222

Post by storystarling »

wongarsu wrote: post #93
marginalia_nu wrote: post #65

Earlier quoted context omitted.

What would be the point of that? If LLMs ever actually become competent, surely they can just implement what they need.

The same reason why they exist now. Why spend millions of tokens on designing, implementing and debugging something, followed by years of discovering edge cases in the real world, if I can just use a library that already did all of that Sure, leftpad and python-openai aren't hugely valuable in the age of LLMs, but redis and ffmpeg are still as useful as ever. Probably even more useful now that LLMs can actually know…

They know the syntax but seem to miss the architectural context. I've found that models will happily generate valid Redis commands that introduce race conditions or break state consistency the moment you have concurrency. It saves typing but you still need to design the locking strategy yourself.

Re: Vibe coding kills open source

#223

Post by jdiff »

delegate wrote: post #101

There's some irony in the fact that LLMs are in large part possible because of open source software. From the tools which were used to design and develop the models (programming languages, libraries) to the operating systems running them to the databases used for storing training data .. plus of course they were trained mostly on open source code. If OSS didn't exist, it's highly unlikely that LLMs would have been bu…

Turns out that it's only in myth that a snake can eat its own tail without dying.

Re: Vibe coding kills open source

#224

Post by matkoniecz »

joks wrote: post #122
echelon wrote: post #33

Earlier quoted context omitted.

You won't have to ignore this stuff for long. Pretty soon it'll be mandatory to keep up. I've been a senior engineer doing large scale active-active, five nines distributed systems that process billions of dollars of transactions daily. These are well thought out systems with 20+ folks on design document reviews. Not all of the work falls into that category, though. There's so much plumbing and maintenance and wiring…

> "The same thing that happened to illustration and art is happening here" What are you talking about? Illustrators and artists are not being replaced by AI or required to use AI to "keep up" in the vast majority of environments. > "I don't get the sour opinions." The reasoning for folks' "sour opinions" has been very well-documented, especially here on HN. This comment reads like people don't like AI because they th…

> What are you talking about? Illustrators and artists are not being replaced by AI or required to use AI to "keep up" in the vast majority of environments.

large part of formerly done by humans graphics is now autogenerated

Re: Vibe coding kills open source

#225

Post by pmarreck »

romanows wrote: post #203
pmarreck wrote: post #115

Related but not sure how much attention it's getting: GPL is a dead man walking since you can have any LLM cleanroom a new implementation in a new language from a public spec with verifiable "never looked at the original source" and it can be more permissively-licensed however you wish (MIT, BSD etc). case in point, check out my current deps on the project I'm currently working on with LLM assist: https://github.com/…

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.

ah, interesting.

Re: Vibe coding kills open source

#226

Post by pmarreck »

dahauns wrote: post #198
pmarreck wrote: post #115

Related but not sure how much attention it's getting: GPL is a dead man walking since you can have any LLM cleanroom a new implementation in a new language from a public spec with verifiable "never looked at the original source" and it can be more permissively-licensed however you wish (MIT, BSD etc). case in point, check out my current deps on the project I'm currently working on with LLM assist: https://github.com/…

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

Both. Good question.

Although it would be much harder to prove, of course, that I never saw the original code/implementation.

Re: Vibe coding kills open source

#227

Post by devinprater »

I'm completely blind. I like Linux. I've started to love Android since getting a Samsung and getting rid of OnePlus, cause accessibility. Termux is cool, but it's accessibility wasn't. So, I had Gemini rangle it up a bit into my fork of Termux [1]

Now it reads (usually) only newly incoming text, I can feel around the screen to read a line at a time, and cursor tracking works well enough. Then I got Emacs and Emacspeak working, having Gemini build DecTalk (TTS engine) for Termux and get the Emacspeak DecTalk speech server working with that. I'm still amazed that, with a Bluetooth keyboard, I have Linux, and Emacs, in my pocket. I can write Org and Markdown, read EPUB books in Emacs with Nov.el, look at an actual calendar not just a list of events, and even use Gemini CLI and Claude Code, all on my phone! This is proof that phones, with enough freedom, can be workstations. If I can get Orca working on a desktop environment in Termux-GUI. But even with just Emacs and the shell, I can do quite a bit.

Then I decided to go wild and make an MUD client for Emacs/Emacspeak, since accessible ones for Android are limited, and I didn't trust my hacks to Termux to handle Tintin++ very well. So, Emacs with Emacspeak it was, and Elmud [2] was born.

Elmud has a few cool features. First of all, since Emacspeak has voice-lock, like font-lock but for TTS, Ansi colors can be "heard", like red being a deeper voice. Also a few MUD clients have sound packs on Windows, which make them sound more like a modern video game, while still being text-based. I got a few of those working with Elmud. You just load one of the supported MUD's, and the sound pack is downloaded and installed for you. It's easy and simple. And honestly, that's what I want my tools to provide, something I, or anyone else who chooses to use them, that is easy to get the most out of.

None of this would have been possible without AI. None of it would have been done. It would have remained a dream. And yes, it was all vibe-coded, mostly with Codex 5.2 on high thinking. And yes, the code may look awful. But honestly, how many closed-source programs look just as bad or even worse under the covers of compilation?

[1] https://github.com/devinprater/Talking-termux-app

[2] https://github.com/devinprater/elmud

Re: Vibe coding kills open source

#228

Post by lukan »

korenmiklos wrote: post #127
earino wrote: post #15

Earlier quoted context omitted.

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

author here. indeed, a more preceise title could be > given everything we know about OSS incentives from prior studies and how easy it is to load an OSS library with your AI agent, the demand-reducing effect of vibe coding is larger than the productivity-increasing effect but that would be a mouthful

How about "Vibe coding might hurt open source"?

Re: Vibe coding kills open source

#229

Post by technofiend »

candiddevmike wrote: post #64
WarmWash wrote: post #29

Small bespoke personalized on the spot apps are the future with LLMs. The future will absolutely not be "How things are today + LLMs" 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 a custom(!) hammer or saw in a few minutes, why go to the shed?

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.

>... and you don't have to worry about it.

Not to be argumentative, but I have a concern that whomever I buy my solution from will have vibe coded it instead. I guess that means my support contract entitles me to hassling them about it, but I'm starting to worry it's just LLMs and vibe coded apps all the way down.

Re: Vibe coding kills open source

#230

Post by aspenmartin »

II2II wrote: post #128
WarmWash wrote: post #29

Small bespoke personalized on the spot apps are the future with LLMs. The future will absolutely not be "How things are today + LLMs" 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 a custom(!) hammer or saw in a few minutes, why go to the shed?

> 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 pro…

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

Why do you think agents can’t do that? They can’t do this really well today but if the distance we went in 2025 stays similar it’ll be like a year before this starts getting decent and then like another 1 year before it’s excellent.

> 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

Only humans can do this?

Post reply on HN