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

41–50 of 304 posts

Re: Vibe coding kills open source

#41

Post by koakuma-chan »

echelon wrote: post #33
koakuma-chan wrote: post #22

Earlier quoted context omitted.

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

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…

I'm not saying that you shouldn't use AI.

There was a submission to a blog post discussing applications of AI but it got killed for some reason.

https://news.ycombinator.com/item?id=46750927

I remain convinced that if you use AI to write code then your product will sooner or later turn into a buggy mess. I think this will remain the case until they figure out how to make a proper memory system. Until then, we still have to use our brains as the memory system.

One strategy I've seen that I like is using AI to prototype, but then write actual code yourself. This is what the Ghostty guy does I believe.

I agree that AI can write decent Rust code, but Rust is not a panacea. From what I heard, Cursor has a lot of vibe-coded Rust code, but it didn't save it from being, as I said, a buggy mess.

Re: Vibe coding kills open source

#42

Post by gyanchawdhary »

interesting as an econ thought experiment .. but it assumes OSS revenue comes from direct developr engagement .. In practice .. most successful OSS is funded by enterprises .. cloud vendors .. or consulting engagements .. where broader adoption, including AI mediated usage, often increases demand of said OSS project

Re: Vibe coding kills open source

#43

Post by echelon »

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…

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

Re: Vibe coding kills open source

#45

Post by reactordev »

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?

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

Re: Vibe coding kills open source

#46

Post by neko-kai »

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

e.g. Vibe coding defeats GNOME developers' main argument for endlessly deleting features and degrading user experience - that features are ostensibly "hard to maintain".

Well, LLMs are rapidly reducing development costs to 0.

The bottleneck for UI development is now testing, and here desktop Linux has advantage - Linux users have been trained like Pavlov's dogs to test and write detailed upstream bug reports, something Windows and macOS users just don't do.

Re: Vibe coding kills open source

#47

Post by nevi-me »

Cthulhu_ wrote: post #11
tomaytotomato wrote: post #6

I have been trying to use Claude code to help improve my opensource Java NLP location library. However trying to get it to do anything other than optimise code or fix small issues it struggles. It struggles with high level abstract issues. For example I currently have an issue with ambiguity collisions e.g. Input: "California" Output: "California, Missouri" California is a state but also city in Missouri - https://gi…

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

I've been a skeptic, but now that I'm getting into using LLMs, I'm finding being very descriptive and laying down my thoughts, preferences, assumptions, etc, to help greatly.

I suppose a year ago we were talking about prompt engineers, so it's partly about being good at describing problems.

Re: Vibe coding kills open source

#48

Post by draxil »

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?

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.

Re: Vibe coding kills open source

#49

Post by ipaddr »

For me spending time on my open source projects doesn't make sense anymore.

People (the community and employers) previously were impressed because of the amount of work required. Now that respect is gone as people can't automatically tell on the surface if this is a low effort vibe code or something else.

Community engagement has dropped. Stars aren't being given out as freely. People aren't actively reading your code like they use to.

For projects done before llms you can still link effort and signal but for anything started now.. everyone assumes it's llm created. No one want to read that code and not in the same way you would read other humans. Fewer will download the project.

Many of the reasons why I wrote open source is gone. And knowing the biggest/only engagement will come from llms copying your work giving you no credit.. what's the point?

Re: Vibe coding kills open source

#50

Post by hayd »

ktallett wrote: post #2

I think vibe coding would greatly struggle with large open source projects unless your planning was exceptional and your comments on optimal coding style was exceptional, however...... For those small open source tools that many of us use daily and find invaluable, I actually think vibe coding is ideal for that. It can make a functional version quickly and you can iterate and improve it, and feel no loss for making i…

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.

Post reply on HN