Live data from Hacker News

Vibe coding kills open source

arxiv.org

21–30 of 304 posts

Re: Vibe coding kills open source

#21
post #5

"Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns." I think the title is clickbait. The conclusion is: "Vibe coding represents a fundamental shift in how software is produced and consumed. The productivity gains are real and large. But so is the threat to the open source ecosystem that under…

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

Re: Vibe coding kills open source

#22
post #8

I believe we will see a new huge wave of useful open source software. However don't expect the development model to stay the same. I was finally able to resurrect a few projects of mine, and many more will come. One incredible thing was the ability to easily merge what was worth merging from forks, for instance. The new OSS will be driven not much by the amount of code you can produce, but from the idea of software y…

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

Re: Vibe coding kills open source

#23

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 updated my original comment to explain my reasoning a bit more clearly.

Essentially I ask an LLM to look at a project and it just sees the current state of the codebase, it doesn't see the iterations and hacks and refactors and reverts.

It also doesn't see the first functionality I wrote for it at v1.

This could indeed be solved by giving the LLM a git log and telling it a story, but that might not solve my issue?

Re: Vibe coding kills open source

#24
post #16
post #9

Earlier quoted context omitted.

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.

More we need a new GitHub.

May I recommend SourceHut (https://sr.ht/)

Re: Vibe coding kills open source

#25
post #16
post #9

Earlier quoted context omitted.

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.

More we need a new GitHub.

Also this.

But IMO the primitives we need are also fundamentally different with AI coding.

Commits kind of don't matter anymore. Maybe PR's don't matter either, except as labels. But CI/hard proof that the code works as advertised is gold, and this is something git doesn't store by default.

Additionally, as most software moves to being built by agents, the "real" git history you want is the chat history with your agent, and its CoT. If you can keep that and your CI runs, you could even throw away your `git` and probably still have a functionally better AI coding system.

If we get a new Github for AI coding I hope it's a bit of a departure from current git workflows. But git is definitely extensible enough that you could build this on git (which is what I think will ultimately happen).

Re: Vibe coding kills open source

#26
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. If I am on a system without Python installed, I don't see Claude saying, oh, you don't need to download it, I'll write the Python interpreter for you.

Re: Vibe coding kills open source

#27

Earlier quoted context omitted.

> 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 updated my original comment to explain my reasoning a bit more clearly. Essentially I ask an LLM to look at a project and it just sees the current state of the codebase, it doesn't see the iterations and hacks and refactors and reverts. It also doesn't see the first functionality I wrote for it at v1. This could indeed be solved by giving the LLM a git log and telling it a story, but that might not solve my issue?

I personally don't have any trouble with that. Using Sonnet 3.7 in Claude Code, I just ask it to spelunk the git history for a certain segment of the code if I think it will be meaningful for its task.

Re: Vibe coding kills open source

#28
I don't really read papers and haven't read this one either but that summary.

> In vibe coding, an AI agent builds software by selecting and assembling open-source software (OSS),

Are they talking about indirectly due to prior training of the model? No agent I use is selecting and assembling open source software. That's more of an integration type of job not software development. Are they talking about packages and libraries? If yes, that's exactly how most people use those too.

I mean like this:

> often without users directly reading documentation, reporting bugs, or otherwise engaging with maintainers.

and then,

> Vibe coding raises productivity by lowering the cost of using and building on existing code, but it also weakens the user engagement through which many maintainers earn returns.

Maintainers who earn "returns" must be such a small niche as to be insignificant. Or do they mean things like github stars?

> When OSS is monetized only through direct user engagement, greater adoption of vibe coding lowers entry and sharing, reduces the availability and quality of OSS, and reduces welfare despite higher productivity.

Now the hypothesis is exactly the opposite. Do agents not "select and assamble" OSS anymore? And what does this have to do with how OSS is "monetized"?

> Sustaining OSS at its current scale under widespread vibe coding requires major changes in how maintainers are paid.

Sustaining OSS insofar as maintainers do it for a living requries major changes. Period. I don't see how vibe coding which makes all of this easier and cheaper is changing that equation. Quality is a different matter altogether and can still be achieved.

I am seeing a bunch of disjointed claims taken as truth that I frankly do not agree with in the first place.

What would the result of such a study even explain?

Re: Vibe coding kills open source

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

Post reply on HN