Live data from Hacker News

Please Do Not Vibe Fuck Up This Software

github.com

181–190 of 534 posts

Re: Please Do Not Vibe Fuck Up This Software

#181
post #42

Earlier quoted context omitted.

> is almost completely context free on what the drama is beyond "Claude" As soon as it happened their rsync based backup system that was working before started to fail. It says right there.

The source code is all right there. An actual analysis would involve a complete description of what you were doing including code they are running proving that what you were doing is reasonable and correct and expected to work. An explanation of what actually happened and ideally the exact commit where it stopped working. A users bald assertion that something is "broken" with no details should be regarded with suspic…

> Nothing but dripping contempt for their betters.

... and that's how to lose credibility.

Re: Please Do Not Vibe Fuck Up This Software

#182

Jesus Christ... this anti-AI thing is getting ridiculous. If the code is good, bug free, and easily understood, who the f*ck cares? If a maintainer just accepts any code, without review or control, humans, just as well as "AI:s" can submit crappy code. I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.

The code obviously isn't bug-free as several issues were identified. It's also not easily understood, as there are multi-thousand-line AI-generated commits.

Re: Please Do Not Vibe Fuck Up This Software

#183

Can GitHub add a tag to repositories that says "probably vibe coded" or "ai code detected"

would you argue for an 'unsafe code' tag too, if it's attached to repos with C/C++?

Would have to be on all repositories I think.

Re: Please Do Not Vibe Fuck Up This Software

#185

Earlier quoted context omitted.

I just had the first case of a file not being copied correctly after using rsync that I noticed a few days ago. It was a raw image file so it was visually noticeable, some lines of pixels just went black. It may be unrelated, it may not have even been rsync's fault, but this drama and timing just makes me wonder if I got clauded there.

Do you not do the md5 or sha hashes of the copied zip file?

That's ... what rsync is supposed to do for you.

Re: Please Do Not Vibe Fuck Up This Software

#186
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 do we need AI here? As several comments in the issue mention, it's up to the developers that contribute to an open source package to decide how they do it. Complaining on an issue tracker (apparently without proof) about AI ruining a piece of software is a form of "Open Source contributor abuse" discussed frequently on Hacker News [1] https://github.com/RsyncProject/rsync/issues/929#issuecommen... > The issue t…

I agree, if I was the maintainer this would be an extremely tiring community feedback.

People coming in "I encountered a bug, I don't know what the bug is but I thought about it for a second and it's obviously your descision to do xyz".

As a maintainer, what are you supposed to do? It's not more useful than a ticket "somethings wrong idk what" which is useless enough to close without further action. But it puts the burden on the maintainer to a) figure out what's wrong based on basically no data whatsoever, then b) if they find it out figure out why then c), and that's the tiring part, review their process and create a defense for their approach, or admit that that thing that random user felt after trying out your software for 10 minutes is right, and that you were what? stupid to even think this would ever work? They never asked for any of this, and they're already doing so much work for free.

If the rsync maintainer reads this: You're doing incredible work and humanity appreciates your obviously incredibly competence in it, and not everyone feels the way these people do.

Moving to agentic workflows is obviously the right step and it already provides enough benefits to do it already. And mistakes are bound to happen (if the issue is even a mistake!) and there will always be people who cannot comprehend the power of agents and who will point the finger saying "I know it from the start! I've worked with these tools for 2 hours already and I can see they don't work! Idk why you think they do!". They're wrong. But mistakes will happen that otherwise wouldn't have - but that's the learning experience.

Re: Please Do Not Vibe Fuck Up This Software

#187

Jesus Christ... this anti-AI thing is getting ridiculous. If the code is good, bug free, and easily understood, who the f*ck cares? If a maintainer just accepts any code, without review or control, humans, just as well as "AI:s" can submit crappy code. I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.

> If the code is good, bug free, and easily understood

The whole point here is that it wasn’t. That’s the whole reason the submission exists, that allegedly bugs were introduced where it was previously working.

> I can only conclude that this is some kind of misplaced frustration due to job protection and feelings of insecurity that makes people this polarized and religious.

Be careful with assumptions. You are basically expressing that the people you disagree with have petty negative reasons to think how they do. That’s not empathetic and it’s colossally misinformed. I recommend you attempt a good faith search of the myriad reasons people may be against LLMs. Here’s a good faith question on HN to start:

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

Re: Please Do Not Vibe Fuck Up This Software

#188
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.…

I feel really bad for the sense of entitlement a lot of open source devs have to deal with. Imagine building something for free as a hobby then having to deal a mob of angry people who have never paid you whenever you do something they don’t like. Surely your first thought would be to tell them to foxtrot oscar somewhere else.

Re: Please Do Not Vibe Fuck Up This Software

#189

I'm shocked that people are jumping on one of the most productive and powerful OSS maintainers in existence. The actual Claude "churn" is mainly test suite enhancement.

One of the most reliable OSS sync/backup tools on the planet for 2+ decades broke under people's daily backup use of it because of a large pile of LLM-driven changes basically out of nowhere from the project maintainer in a minor point release. I think they're right to be annoyed and to complain about it.

Whilst a lot of the Claude changes are test related, there were still other changes that obviously broke things for people - and who's to say that some of the testing changes may not have thinned out the testing too given one commit "rewrote all shell tests in python" with over 4000 lines added and removed at once. And even after all that Claude churn on the testing, these breaking changes obviously weren't caught by tests, so it's not exactly an "enhancement" from the end user perspective.

Re: Please Do Not Vibe Fuck Up This Software

#190
post #151

Earlier quoted context omitted.

That's not why people rewrite in Rust. Rewrites brings new bugs regardless of the language.

You're conflating why people want to rewrite it in Rust vs what is the likely end result i.e. I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs especially because there's been almost no meaningful improvement in this space for a long time. But of course in the short term it will mean regressions compared to the established C written version. T…

> I do think people want to rewrite things in Rust because they believe long-term it will mean fewer (memory safety etc.) bugs

I don't believe that anymore - if that were true, the large portion of code now being rewritten in Rust wouldn't be vibe-coded slop.

I'd be more willing to believe that "quality" was the reason if those doing the rewrite weren't fucking vibing everything!

Post reply on HN