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

Please Do Not Vibe Fuck Up This Software

github.com

Post reply on HN
Print view View original

391–400 of 534 posts

Re: Please Do Not Vibe Fuck Up This Software

#391

Post by ddosmax556 »

pishpash wrote: post #325
ddosmax556 wrote: post #304

Earlier quoted context omitted.

Yes, reliability plummeting is valuable feedback, but it should be framed as such, and not attack the maintainers descision to use agentic tools to write code, and especially not in that high nose way with an undertone of: What you're doing is obviously wrong, did you even think?? Everyone here knows it, are you stupid? And the maintainer can then choose to use that feedback to incorporate it into the workflow, on th…

If the maintainer used any other tool which is suspected to cause a number of recent problems, it'd be discussed. The tone is a problem but the reaction is equally problematic. It isn't even clear the maintainer hasn't been silently changed if agents are used, depending on the extent. That itself is worthy of discussion, and "maintainer decision" is not the right call in that situation. One comment basically insinuat…

It can be discussed but not like this. The tone is problematic and results in the reaction. You're basically saying: I found a few bugs and I saw that you use tool X, thus you're now not worthy of maintaining this software without my supervision. Which is tiring if the initial report doesn't even show what exactly was wrong, or if something was wrong. It's just a feeling of: something doesn't work for me; I don't like AI tools; I see you're using AI tools; therefore I now tell you that you're not capable of maintaining this package, and I have to intervene. Such a stark comment must be done on more than just vibes and feelings.

Re: Please Do Not Vibe Fuck Up This Software

#392

Post by mikalauskas »

vova_hn2 wrote: post #202

Since when github issues became a place to post a screenshot of a post from some other platform? I've seen this behavior before only in places where people post memes and other entertainment content. No actionable bug report/feature request. No text version. Not even a link to the original post. Did the person who posted this mistake GitHub Issues for their personal Twitter account?

Posting screenshot is the easier way of blocking automatic LLM responses, cause most of the time people use text models without vision as a cheaper solution

Re: Please Do Not Vibe Fuck Up This Software

#393

Post by graemep »

fao_ wrote: post #294
thevinter wrote: post #116

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…

I think people are very justifiably angry that a very stable, well trusted tool, has started to immediately go downhill. The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding ( https://github.com/linuxmint/timeshift/issues/548 ), one of those links goes to a larger aggregate of bugs reported downs…

> The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding (https://github.com/linuxmint/timeshift/issues/548)

There are four actual regressions there. The commits that introduced two of them have been identified, and neither neither of those mentions Claude (or another LLM).

If you look at the actual commits that credit Claude, they are not huge commits (many are a few lines), most are tests and config. This is not vibe-coding.

> there are multiple reports from users in industrial and government settings that now have to go through whole processes to update this software

If people are handling such critical data with it they will be testing upgrades before deploying to production right?

> I wonder how many more issues have been introduced that we simply won't learn about until a company has a $10 million dollar data loss because they were not testing their backups consistently.

If a backup failure would cause a $10mn loss then its grossly irresponsible to not test your backups.

Re: Please Do Not Vibe Fuck Up This Software

#394

Post by newtonsmethod »

zbentley wrote: post #227

Did anyone in that issue thread ever … describe an issue? As in steps-to-reproduce, expected vs. observed behavior, all that? Like, this was posted on an issue tracker. “Your commit messages reference Claude and some guy on bluesky thinks some unspecified issue he had is related to those commits” is not an actionable issue. All the rest of the discussion aside, if this were my project I would close and lock with “not…

Yes, the actual issues seem to be:

* People with linux * Hardening against path-traversals causes failures for users with: no chroot; using the native rsync protocol. Ironically: chroot = no is deeply discouraged; you shouldn't really be using native rsync in an automated manner (and perhaps it seems I wouldn't advise using it at all); the CVEs the commits fix apply exactly to this use case.

https://www.cve.org/CVERecord?id=CVE-2026-29518

Requires daemon + no chroot. " daemon runs with elevated privileges. This vulnerability can only be triggered if the chroot setting is false."

So the workflows affected are those which are the most vulnerable, and yet people are recommending that people revert versions.

* Furthermore, if a regression test picked this up, it would've been written previously.

Re: Please Do Not Vibe Fuck Up This Software

#395

Post by bakugo »

soerxpso wrote: post #371
eudamoniac wrote: post #310

Earlier quoted context omitted.

They're not mad about the bug, they're mad about the cause of the bug. This is like city council starts flinging stones with a trebuchet into streets, and you're expected to calmly file pothole reports instead of complaining about the trebuchet.

Bugs exist in human code too. The AI derangement crowd pounces on any small bug as evidence that AI is a trebuchet, and thinks that if only we didn't use AI there would never be any bugs (like five years ago when all software was perfect, was not being enshittified, and had 0 bugs).

> Bugs exist in human code too.

These bugs did not exist in human code. They were introduced by AI.

> thinks that if only we didn't use AI there would never be any bugs

Strawman. These bugs would not exist if not introduced by AI.

Re: Please Do Not Vibe Fuck Up This Software

#396

Post by dragontamer »

lukaslalinsky wrote: post #343
dragontamer wrote: post #299

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…

And it seems like regressions that lead to rsync losing data is just as serious.

Again: we are talking about rsync here. This new methodology being used this year seems to be associated with a regression (ie: Data loss since this is rsync after all....) that likely wouldn't have happened any other year.

Or at least: the regressions at play are consisting of thousands of lines of changes that was only navigated by Claude later down in the discussion.

We are reaching the point of AI developed code that requires AI itself to analyze. One step at a time. It's right for the open source customers who are used to understanding changes and smaller patches than this.

Re: Please Do Not Vibe Fuck Up This Software

#397

Post by newtonsmethod »

izacus wrote: post #276
ilikehurdles wrote: post #256

Earlier quoted context omitted.

It has broken many times before. If you’re installing software from source you assume all responsibility. Go use Debian if you don’t want to deal with breakage.

Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.

> Just because you got shat on the head once it doesn't mean it's fine to be shat on the head every day now.

This happens frequently when there are fixes for CVEs, since regression tests can't catch many things which incremental rollouts can. It happened for example in 2025. People are right to imply the reaction is totally outsized here, and it's almost certainly the case that people are overreacting to AI (rather than the somewhat weak idea that it's because of the frequency of these issues).

What's really funny is that the people opposing AI here are showing far less literacy than those who wrote the code. People claiming to be affected by this bug severely are likely exposing themselves: * One bug is for Linux * The other bug affects precisely the people impacted by the CVE https://github.com/RsyncProject/rsync/issues/897

You probably don't want to revert in this scenario. If someone is hit by this bug and is running rsync in an automated manner, it is highly likely they're ignoring very many security practices: you're usually not supposed to run native rsync in an automated manner (the main use case is for public users, where you can't SSH etc; since it's unencrypted, you're supposed to check a checksum against a website etc); these cases are hit with chroot false, which is deeply discouraged and leads to far larger attack surfaces.

Re: Please Do Not Vibe Fuck Up This Software

#398

Post by hnfong »

hashmap wrote: post #296
daishi55 wrote: post #286

This anti-AI hysteria is just such a classic moral panic. It’s just 1) identify something as AI-produced 2) attack and ostracize anyone who might be involved in that production And as with all moral panics, whether (1) is factual is totally beside the point. The point is the almost sexual release you get from (2). I know in this case there is AI-produced code in rsync (as there is with most useful software by now), b…

it's dangerous to refuse to understand whats happening broadly, and what's taking place in this thread, and to signal that it's ok to keep refusing to understand it. the anger that's showing up around ai isn't a matter of the masses being misinformed, or the messaging around it, it's a matter of physics. you have this one thing that is being used as an excuse to lay people off en masse, you have tech ceos near daily…

What do you mean? You pretty much described classic moral panic.

Re: Please Do Not Vibe Fuck Up This Software

#399

Post by lukaslalinsky »

bakugo wrote: post #390
lukaslalinsky wrote: post #267

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.

If committing thousands of lines of unreviewed AI generated code is "doing their best", I'd argue that them not contributing anymore would be a net benefit for the project.

That's possible, but who are you to tell a person what they should and shouldn't do in their free time.

Re: Please Do Not Vibe Fuck Up This Software

#400

Post by thefz »

thevinter wrote: post #116

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…

> seemingly forgetting that before AI people did mistakes as well.

It's just that they now have the chance to do them 1000% faster and not even realize

Post reply on HN