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.
Please Do Not Vibe Fuck Up This Software
191–200 of 534 posts
Re: Please Do Not Vibe Fuck Up This Software
#192Jesus 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.
Personally I don't think it's any more ridiculous that the amount of money currently being burned to convince me that I should use more AI in every aspect of my life.
Re: Please Do Not Vibe Fuck Up This Software
#193Re: Please Do Not Vibe Fuck Up This Software
#194Earlier quoted context omitted.
Did he ask for help in churning all the code for no reason? Rsync was complete software. It does not need features, it needs stability and merely maintenance. 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 th…
Do you have any links to commits or changes that you think are "uncalled for"? Like, you say "he is making large and sweeping changes that are entirely uncalled for and cause breakage", so surely you have some examples? 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.
As an example, the entire test suite was recently vibe-replaced. An essential component for reliability and stability. And you can already see the results in the decreased stability and increased defect count.
Re: Please Do Not Vibe Fuck Up This Software
#195Earlier quoted context omitted.
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!
There may be some recency bias with the whole Bun fiasco, but Bun is after all owned by Anthorpic.
The wast majority of software in Rust that's actually used is not vibe coded as far as I know. There may be a large number of vibe coded Rust projects on GitHub but that's a poor metric to judge by given how easy it is to publish a new repo.
Is a large portion of in use Rust code vibecoded? I don't believe so.
Re: Please Do Not Vibe Fuck Up This Software
#196A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.
This nailed it. None of the bug reports even attempt to document the claimed "--compare-dest=" regression. I did ctrl-f and I didn't even see anyone mention "compare-dest" again? The people posting worthless AI rage comments could have asked Opus 4.8 to spin up rysnc 3.4.3 vs. 3.4.1, thoroughly document the regression and git bisect the commit that broke it and filed a 1000x more professional and useful bug report.
If you want society to value your human work more than AI work, try to avoid acting like a uniquely human bozo.
Re: Please Do Not Vibe Fuck Up This Software
#197Earlier quoted context omitted.
Does an AI rewrite in Rust cancel out?
I did recently read an article about how, due to better training data, an AI writes better code in Rust than most other languages. 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.
Re: Please Do Not Vibe Fuck Up This Software
#198Earlier quoted context omitted.
wtf is this comment section? 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…
> Is there any evidence that the bug rate on rsync is any worse than it used to be? or just a screenshot from mastadon? 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.
Re: Please Do Not Vibe Fuck Up This Software
#199Earlier quoted context omitted.
Did he ask for help in churning all the code for no reason? Rsync was complete software. It does not need features, it needs stability and merely maintenance. 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 th…
> Rsync was complete software. It was (and is) not: rsync has over 300 open issues with bugs and feature requests.
2. Of course bugs should be fixed. I even say so in the comment you replied to. You are attacking a strawman.
3. People will always make feature requests. Some want rsync to be able to make a sandwich. That is not really in-scope for the project though.
I think the GNU coreutils are doing this largely right. New features are almost never added. ls, for example, is pretty much complete, and too foundational to mess around with. If you need fancy new features, use something like eza.
Re: Please Do Not Vibe Fuck Up This Software
#200A few years ago, the probability of such shit reaching the Hacker News home page was near zero, because regardless of the merits, here was not full of normies that could not understand when a behavior is unacceptable (I'm referring to the violence of the language of the issue). And now, here we are, surrounded by people that can't tell the most obvious things.
This one is "tamer", a bit, because the hate goes towards the AI usage, not the person.