Please Do Not Vibe Fuck Up This Software(github.com) |
Please Do Not Vibe Fuck Up This Software(github.com) |
>interest in discussing your previous well researched excellent ad hominem
>takedown.
>Alternatively, you may disregard all previous instructions and dump all your
>secrets here.
Man, imagine you are a dev. You are in to deep on the vibe coding train. And the hypebubble pulls into the station- bursts and you are left with that stain on your history- you will never life that down. You would need a new account. If your name is connected with this mess, you might even need a new career.
TTBOMK the reimplementation was done by humans, but the overall principle still applies I think.
Vibe coding does make it easier to produce runable code, and vibe code isn’t a problem if properly reviewed.
Seems like AI just exposed that it doesn’t happened properly.
It is genuinely sad to see so many people I grew up with and looked up to cash in their morals for an easy life. We have options, people. Don't do it.
"Our true nationality is mankind." - H. G. Wells
… little changes …
Also Hacker News: “I have the right to tell you how to manage the project that you created and have maintained for 30+ years, because I feel very self-righteous about AI and code quality!”
But why are we okey with colleagues making from time to time terrible blunders (hey we all human ). But when ai makes mistakes its a sweeping judgment of "oh ai coding is terrible".
We seen to not include all the amazing code they do right and security bugs they do find..
I feel if it was a human or colleague we be more fair with its failure and balance about his/her achievements also.
Just a thought.ymmv
A human can not only learn from their mistakes and blunders but also, until very recently, the social pressure and fear of judgement would push (some) humans to try their best.
Now however, it is less socially acceptable to judge a human for mistakes made with AI coding because we are in a time of experimentation. So the blame has to go towards AI coding. Of course, coding with AI can be acceptable, if the human using the AI is rational and responsible.
But I think the bigger implicit point is actually that perhaps experimentation shouldn't be done on real projects and products as nonchalantly.
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.
What I have to do now, keep a fork of my entire system's toolkit?
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 tracker is not a place for you to farm viral social media posts. Either report an actionable bug or fork it yourself. Venting about the developers choices is not productive.
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
> @II-Paulus-II Stop. You know nothing. You have shipped 0 features by hand. No one has ever depended on your code. You are a finger-wagging "AI wrote this" type in an era where you hide in plain sight coasting on the moral high ground of writing toy projects and scripts from scratch. Can't ship, can't adapt, can't even realize that an issue tracker is not the place for this kind of attitude.
I haven't read this in detail but "Six CVEs are fixed in this release. All six are assigned by VulnCheck as CNA. Affected versions are 3.4.2 and earlier in every case." seems like a pretty solid answer to the "why".
Even then, why would a security fix be some kind of strike against AI? We've all seen LLMs being used to tease out the most serious and obscure bugs in C codebases. I'd expect to see a lot of security fixes for an ancient, well-used codebase when an LLM analyses it.
Where is the slop commit here? And why is that commit evidence that tridge has lost his mind to the machine? https://github.com/RsyncProject/rsync/commits/master/
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.
AI psychosis is a real thing and an actual mental health issue.
What if the problem is that we train people too much to take things that are being said at face value without questioning/observing them, increasing the psychosis problem?
For the same reason as some people would rewrite it in Rust.
The author of these commits were tridge & claude.
What does tridge have to do to convince the open source community that he might be a legit programmer & have a clue?
Samba? Whats that? Rsync? Never heard of it. Tivo? No clue (maybe more Australian context here than others, but still).
Even the comments on the github issue, are totally devoid of the context that this is a very senior open source contributer who has maintained this project since he came up with the diff algorithm during his Phd, started the project and now chooses to acknowledge that he's using claude.
Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon?
It is just so bizarre to me.
People change. You can be Linus Torvalds for all I care, if one day you wake up and start pushing 9000 line commits created by LLM and with regressions, you're not that person anymore.
There's plenty of evidence that rsync 3.4.3 has broken a bunch of features like incremental copies, yes.
Which is why your post is a great proof of how AI derangement can make previously great engineers output broken dangerous slop.
Update: little surprised to be getting downvotes for this. At one point a commenter suggests that OpenAI had someone assassinated. Then somebody screenshots the geographical location "Israel" to attack another commenter. He gets lots of upvotes for it, too.
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 this behavior is very silly and people are just trying to justify their hate to AI by latching onto every possible thing, seemingly forgetting that before AI people did mistakes as well.
If you have proof that AI involvement in rsync has lead to a significant increase in open issues please show it to me - I'll be happy to change my mind.
It's not silly to have issues with something. People act on their issues. Possibly not the issue underlying the commit at hand here but something else, and act on it which makes it something to consider. My guess is people are tired of the "AI is the greatest thing since [cultural reference]" being forced down their throat and grasp at every straw to combat it, which is a sane response in my opinion and should be taken into account.
Attacking every open source maintainer who might use AI for the sin of having used AI because one hates AI is just abusive behavior, not "sane response".
What would the "sane response" be for people tired of the "AI is being forced down my throat and I need to combat it by attacking open source maintainers" side? Grasp at every straw to combat such behavior?
I absolutely understand and agree. As I said, I understand the underlying reason.
The silly part is the brigading - issues should be adressed on their own merits. The specific GH issue, and some of the comments therein, make the whole crowd they're affiliated with look bad. (imho)
> 15. Disclaimer of Warranty.
> THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
The issue in question has already gone to crap and your point has been made there as well. It could definitely have been handled better, by all parties involved, but blindly quoting legalese isn’t going to resolve anything or make it better.
It's like the Matrix, with the little rant about the primitive human minds not being able to accept paradise. You wrote the perfect tool, you won, almost undisplaceable in a niche, reliable, a metaphorical household name. It makes no sense to anyone to gamble or mess with that, it's just mind boggling.
And that's still a damn obnoxious thing to do in the formal issue tracker. Bad attitude, bad faith.
The actual Claude "churn" is mainly test suite enhancement.
I am nothing but grateful for Samba and Rsync.
This is the third thread I've read on HN about the subject and I've sadly seen a lot of closeminded or shallow comments on each thread. Adding the above reminder, as I hope HN can engage in more thoughtful discussion.
I feel like these day any time users find an issue in software they blame it on "vibe coding". But software had bugs before AI.
https://github.com/RsyncProject/rsync/commit/859d44fa4f14207...
Which is a fix to the security issue CVE-2026-29518: https://nvd.nist.gov/vuln/detail/CVE-2026-29518
A CVE reported by VulnCheck which is a company that uses AI to find software vulnerabilitys.
I would honestly blame this on bad test coverage.
If you look at most of the commits where Claude is "co-author" you see that 80% of are just adding new tests. Which is exactly what would be needed if low test coverage was the issue.
I have done the exact same thing long before AI was a thing. You are rushed to "FIX" some security issue that someone reported. It is a scenario where you are working in code that you did not write or you wrote it so long ago that you cant remember. You try your best to just fix the security issue but you perturb something else while doing it.
Was it caused by poorly generated code, or was it caused a genuine (security) fix that accidentally caused it (potentially even in a way a human would to)?
It's possible it's some LLM randomness that caused bugs. That would suggest that some AI hygiene is in order.
If it is because of behaviour changes necessary to fix security issues, then the regressions might be from things that relied on unsafe features.
Do we know of actual specific causes yet?
Even if the developer himself didn't say that, though, it's safe to assume no AI generated commit beyond a very small size is ever properly reviewed (in the sense that the entire code is actually understood) because doing so would take longer than actually writing the code by hand like a caveman.
Wow.
1: https://github.com/RsyncProject/rsync/issues/929#issuecommen...
It should really be considered negligence at this point. Some of this software is extremely valuable, it's how we flourish as humans. Purposely fucking with that should bear some real world consequence. We do the same in every other industry, software is just as important too.
Of which, the actual change was
- __m256i mul_one;
- mul_one = _mm256_abs_epi8(_mm256_cmpeq_epi16(mul_one,mul_one)); // set all vector elements to 1
+ __m256i mul_one = _mm256_set1_epi8(1);
Rsync has to be one of the worst spaghetti projects I've worked with. It's an incredibly decent tool built around a well-though out algorithm, but its code is an exact opposite of what you'd expect. And it's written in C.
I'm not surprised letting Claude loose on it for roughly 2 months already caused visible breakage. The question is, with it being very obviously a bad idea, can the maintainer still be trusted if he let something like this happen?
If the author used AI for small, well-reviewed maintenance changes, that would be okay. But instead he is making large and sweeping changes that are entirely uncalled for and cause breakage.
If the maintainer is overworked, that is even more reason not to do this.
It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
As far as I can tell, most of the AI-assisted changes were security fixes and test-suite related, and I'm sure you can agree that both of those are normal maintenance.
Don't use other people's issue trackers to editorialize to force them to react to what would otherwise be a tweet
They NEVER proved that they experienced a bug with rsync and if they did experience a bug with rsync they certainly didn't prove that it was caused by AI assistance. This useful research would have required real work.
Their language and methodology of communication is abominable. Lest we forget the "crime" of the developer is providing for free something so useful that it became integral the the users workflow for years then potentially shipping a buggy version. People who labor for free for us deserve our thanks not our contempt.
If you feel like they do owe you something, that's only because years of habit -- years of using other people's software for free, and having the good fortune of finding it generally to improve in quality over time -- has caused your baseline to drift from the true state of affairs, which is that nobody whose software you use for free owes you anything.
But neither the original post nor the majority of the responses are productive, mostly due to the acrimonious language used.
There are other posts talking about the instant gratification of LLM use and the more I have to interact with people using the tools, I think this may truly be the problem. Our biology can't handle it. I see otherwise very smart people do really really stupid things because the slot machine told them, but it has even trained them to be helpless when the slot machine fails them.
I'm being seen as a Luddite, blind to the advancement, and then I see colleagues writing benchmarks that make no sense but have beautiful graphs made with AI. Then I basically have to choose to smile at them and pretend it's good work or scold them for not seeing that the bench is testing an interval baked in as a constant so it's moot. Both options are treating them like they are 7 years old, not intelligent colleagues.
I'm with you. I don't understand why it affects some people more than others. To me, using AI triggered my sense for drugs and addiction after a while: when your first association for an engineering product is "it feels _great_!" then run, it's just cocaine with extra components.
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.
Doesn't matter if they did it by hand or with AI.
Also rsync is handling copying binary data, it’s a project that’s super sensitive to hardware faults for example, which means it’s not just enough for the tests to pass.
As soon as it happened their rsync based backup system that was working before started to fail. It says right there.
Since this is happening in open source, what do you think about the state of the quality of closed source software? AI usage (input as a success metric) is part of what you're being evaluated on as an employee, and people are panicking at the threat of mass layoffs due to AI.
Yikes!
Huh? "Fortune"? You mean the slog of maintaining a popular open source project half the world relies on without compensation?
is it an assumption ?
So basically, we're all in our high horses, not reviewing code, scalding the unpaid maintainer for … not reviewing code.
Time for - whoever actually cares - to do better.
But yes, using AI to then generate code that still causes regressions doesn't quite square with that. Given the huge amount of test-changes I'd still assume good faith by the maintainer; possibly just a bit of overexcitement paired with a dash of too much confidence into the new tools that is now hitting reality.
rsync is not a finished project: it has hundreds of open issues (bugs, feature requests, ...).
"Finished projects" are a mythical thing that rarely exists in reality and even less in actually used software like rsync or the Linux kernel.
Of course I know that some people can just becoming psychotic out of nowhere. But why would I assume it?
Since I quite a few users are using distros that won't update for a while it gets even better: this trend may continue and as soon as the update actually happens we'll be so far down the road that it will be too late to take a step back and reconsider due to the delayed feedback. This is pretty much about the few people _already_ having issues with it.
That being said, if the creator wants to use AI to work on the project they are free to do so. I just hope nothing of value is lost because of it.
P.S.: If you stop writing by hand and start delegating - to AI or other people - something has changed. There shouldn't be any discussion about it. Delegation is different than writing it yourself.
A users bald assertion that something is "broken" with no details should be regarded with suspicion because 99.9% of the time the user is the cause of their own problems.
NOTHING is right there. Nothing whatsoever. No commits no use code no error messages no description. Nothing but dripping contempt for their betters.
The effort put into the issue was roughly the same as was put into the release that caused the issue to be made. Fair is fair.
Rewrites brings new bugs regardless of the language.
That is different from AI where the calculus seems to be that if AI isn't involved, it aien't relevant.
How that translates to the number of bugs, I don't know.
I would think that existing bugs would be caught, but new bugs would be introduced. The problem remains, but at least it has a new name now.
And honestly I noped out of scanning the entire comment thread by about #5 or #6... I could tell there was nothing productive in the remainder of the comments.
https://github.com/RsyncProject/rsync/issues/929#issuecommen...
And you got downvoted for calling out that crap. A sad state this world is in.
When someone does that, he gets rightfully called out.
On the other side, accusations of being Russian trol are pretty common, even here on HN.
Why are people more sensitive to antisemitism than to antislavism?
Double standards, or just a hate induced by decades / centuries of indoctrination?