[ktallett]

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 it free to use.

I was very sceptical but I will admit I think vibe coding has a place in society, just what it is yet is still to be determined. It can't help most for sure but it can help some in some situations.

[Cthulhu_]

> For those small open source tools that many of us use daily and find invaluable, I actually think vibe coding is ideal for that.

If they don't exist, AND the author is comitted to maintaining them instead of just putting it online, sure. But one issue I see is that a lot of these tools you describe already exist, so creating another one (using code assist tools or otherwise) just adds noise IMO.

The better choice is to research and plan (as you say in your first sentence) before comitting resources. The barrier to "NIH" is lowered through code assistants, which risks reducing collaboration in open source land in favor of "I'll just write my own".

Granted, "I'll write my own" has always felt like it has a lower barrier to entry than "I'm going to search for this tool and learn to use it".

[data-ottawa]

There are three or four projects I've always wanted to do, but were frontloaded with a lot of complexity and drudgery.

Maybe the best feature of vibe coding is that it makes the regret factor of poor early choices much lower. Its kind of magic to go "you know what, I was wrong, let's try this approach instead" and not having to spend huge amounts of time fixing things or rewriting 80% of the project.

It's made it a lot more fun to try building big projects on my own, where I would go into decision paralysis or prematurely optimize and never start the meat or learning of the core project.

Its also been nice to have agents review my projects for major issues, so I feel more confident sharing them.

[fc417fc802]

> go into decision paralysis or prematurely optimize

Setting out to implement a feature only to immediately get bogged down in details that I could probably get away with glossing over. LLMs short circuit that by just spitting something out immediately. Of course it's of questionable quality, but once you get something working you can always come back and improve it.

[cess11]

The authors try to study the effect of people not engaging directly with OSS projects because they substitute for this with a gang of chatbots, and draw the conclusion that this lack of contact with actual people means they'll be less likely to help finance OSS development.

[hayd]

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.