Live data from Hacker News

Please Do Not Vibe Fuck Up This Software

github.com

341–350 of 534 posts

Re: Please Do Not Vibe Fuck Up This Software

#341
post #328

This whole brigading is bizzarre and some people are behaving like irrational animals. I potentially understand the motivations that might bring one to want to "win" this battle but this really isn't it - it just makes you sound like a fanatic. It takes 5 minutes to search for "regression" on the issue page and go through the 17 results. There are potentially even more on the tracker used prior to github. I think thi…

[flagged]

what a fascinating take. i just scrolled the github thread. there’s very little, if any substance.

your perception must be very interesting to have gleaned anything but seething AI rage.

Re: Please Do Not Vibe Fuck Up This Software

#342
post #307

Earlier quoted context omitted.

These are not customers.

[flagged]

That’s exactly what I was calling out.

Customers pay money for goods and services. They thus get a bunch of social, ethical, and legal positions in terms of their relationship with the seller.

Rsync is an open source project that its maintainers put onto the Internet. People who use it are not customers, and they do not have the right to expectations around how the maintainers will change the software or change how they develop it.

Re: Please Do Not Vibe Fuck Up This Software

#343

Earlier quoted context omitted.

The thing is, showing the annoyance to the volunteer, who is already doing their best, has two possible outcomes: 1) they stop volunteering 2) they will ignore you In neither of that is your issue solved. So maybe it's better to deal with the frustration on your own and then file a bug report.

There must be some degree of communication from customers to developers. Even if it is a free volunteer service. Poor communication results in professionals firing the customer as well. None of this is exclusive to OSS of volunteer effort. But the communication in general is necessary. This is just product management and communication issues. There is an perceived problem and the problem MUST be communicated. Problem…

Look, it's not that long time ago when we had the xz malware. The pattern is always the same. Maintainer of the project is doing X, people start to pressure them to do something else, maintainer gives up and opens the project up to other maintainers, and then many things can happen. If there is any lesson from the incident, open source maintainers should never allow the pressure to happen, ignore it if it's too strong, block people. Rsync has been maintained for a very long time. Bugs happen, even regression bugs happen. People don't get to dictate how should the volunteer do development.

Re: Please Do Not Vibe Fuck Up This Software

#344

Earlier quoted context omitted.

TBH I don't really feel the same most of the time. I give the LLM little chunks to do. I read the code. I think. I plan. I write a bit of code. I have the LLM crunch out some bullshit task like setting up an annoying C repo. There aren't that many moments in building with LLMs where things line up so the AI can just absolutely nail some code and save me a ton of time.

I think a lot of people have a sort of “slot machine” experience with it at some point. You just start firing off prompts on some new project, wait a few seconds, see what prize you got. Then you start doing that over and over just letting the LLM code and code and not even review what it’s doing. It really is like getting hooked on gambling. You’re getting a thrill from anticipation, not the actual results. This is…

Absolutely, vibecoding is addictive, agents being able to do all of these hard things that would otherwise take days or weeks to figure out how to do by hand.

It's just another avenue of dopamine addiction, not unlike scrolling TikTok, Reddit, or wherever except vibecoding is disguised as being productive.

Re: Please Do Not Vibe Fuck Up This Software

#345

Earlier quoted context omitted.

I read that, yes. I think I'm missing the part where the maintainer is "better".

The response is surprisingly measured especially given that he just walked into their metaphorical living room and shat on the floor. Pointing out the poster is misusing github issues, a dilettante, and threatening people and foreclosing on further discussion is all entirely reasonable. Lots of people in the comments but did you attend to who was an actual maintainer for that repo or did you just assume that the peop…

You misunderstand. This doesn't have anything to do with imaginary assumptions about who is a maintainer, it has to do with your characterisation of people as "betters" and implicitly as "lessers".

Re: Please Do Not Vibe Fuck Up This Software

#346

Earlier quoted context omitted.

There must be some degree of communication from customers to developers. Even if it is a free volunteer service. Poor communication results in professionals firing the customer as well. None of this is exclusive to OSS of volunteer effort. But the communication in general is necessary. This is just product management and communication issues. There is an perceived problem and the problem MUST be communicated. Problem…

Look, it's not that long time ago when we had the xz malware. The pattern is always the same. Maintainer of the project is doing X, people start to pressure them to do something else, maintainer gives up and opens the project up to other maintainers, and then many things can happen. If there is any lesson from the incident, open source maintainers should never allow the pressure to happen, ignore it if it's too stron…

If I were the rsync maintainer I’d probably set the repo to only allow issues and PRs from prior contributors until people learn to behave.

Re: Please Do Not Vibe Fuck Up This Software

#347
post #153
post #36

I truly don't get it You have a rock solid piece of software used by an infinite amount of people and other services. It works fine, does it's job and just have some time to time updates due to minor bug fixes. Why do we need AI here? And more over, why people is saying "fork it and use the previous version". It should be actually all the way around, create a parallel fork younamethetool-ai and keep the OG untouched.…

Why would it be the maintainer’s responsibly to fork their own repo? It wouldn’t even make sense; who would maintain the old repo? They also don’t need a reason, or owe you their reason, for changing what tools they use to work on their open source projects.

Autonomous agents are different. Claude should fork the repo because it is a new maintainer trying to take over a project. Doesn't matter if the OG maintainer is under illusions.

Re: Please Do Not Vibe Fuck Up This Software

#348
Btw, the bug itself was introduced in 30656c5e by Claude Code, and I guess.. improper human review and testing.

https://github.com/RsyncProject/rsync/commit/30656c5e

Someone using AI to bisect recent rsync. https://github.com/themgt/rsync-compare-link-dest-341-343-re...

Someone trying to fix it with more Claude Code: https://github.com/RsyncProject/rsync/pull/930

Related ticket: https://github.com/RsyncProject/rsync/issues/915

I'd recommend putting in more regression testing in the commit before 30656c5e, and rebase it forward while keeping functionality.

Re: Please Do Not Vibe Fuck Up This Software

#349
post #17

Earlier quoted context omitted.

> Like, why? Because everyone, including this forum, is addicted to the instant gratification of LLMs. It’s pure hubris of thinking you can scan the output and it does what you think it does.

TBH I don't really feel the same most of the time. I give the LLM little chunks to do. I read the code. I think. I plan. I write a bit of code. I have the LLM crunch out some bullshit task like setting up an annoying C repo. There aren't that many moments in building with LLMs where things line up so the AI can just absolutely nail some code and save me a ton of time.

> There aren't that many moments in building with LLMs where things line up so the AI can just absolutely nail some code and save me a ton of time.

Your workflow is similar to mine, and not "agentic". The proponents of Agentic workflows would have you handover the bulk of the edits to AI, and you'd hand-hold/course-corrrect its approach via chat while it does the thinking.

I tried the agentic approach for code-gen once, and found it mentally draining. Its like pairing with an over-enthusiastic junior on cocaine that can also type 2000 wpm.

Chunking small changes is great because you don't need the latest and greatest models, Flash variants are more than enough.

Re: Please Do Not Vibe Fuck Up This Software

#350
the entitlement people have towards free, open source software, is incredible.

this isn’t even a “new” problem. if you were around in the early 00s or before you probably worked with a BOfH sys admin that didn’t let you update system packages. that person cared deeply about system integrity and enforced it with policies around package managers.

having outsourced all of that stuff over the years to the cloud, it seems like people forgot this reality existed and can still exist.

the mob freak out is really a projection of a skill issue and it’s sad.

Post reply on HN