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

Did Claude increase bugs in rsync?

alexispurslane.github.io

Post reply on HN
Print view View original

271–280 of 611 posts

Re: Did Claude increase bugs in rsync?

#271

Post by gravypod »

wolletd wrote: post #246
GodelNumbering wrote: post #234

Was just looking at commits and came across a commit and its revert original commit: https://github.com/RsyncProject/rsync/commit/d046525de39315d... ``` - if (!ptr) - ptr = malloc(num * size); - else if (ptr == do_calloc) + if (!ptr || ptr == do_calloc) ptr = calloc(num, size); ``` Written with claude. This is a good example of what slips through LLM attention. It forces all allocations to be calloc as if it is a str…

Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. Most of them written with claude. And then stuff like this is in there. That's exactly what I'd expect when someone is excited about AI usage and becomes... well, sloppy.

> Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that.

I wonder if the data looks worse or better when not doing per-10commit and instead do per-commit.

Re: Did Claude increase bugs in rsync?

#272

Post by nullc »

RustyRussell wrote: post #258

For those commenting, I suggest you read the post linked by the rsync author: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0 (Disclosure: while I haven't talked with him in years, Tridge was my colleague and mentor for many years. I feel it is worth considering his view before joining a crusade)

I think that's an extremely well done response on his part.

Re: Did Claude increase bugs in rsync?

#273

Post by jiggawatts »

jarym wrote: post #256

I've been coding for over 2 decades. I love it, I've always loved it and I likely always will. I was an AI skeptic some months ago but truly Claude and Codex have changed my development style and velocity in a way I never imagined would ever be possible. With that, yes, I produce more code and am finding more bugs. So looking over at comments in HN articles the amount of polarising hate to anything produced with AI i…

I work with outsourced code all the time and it is a tyre fire without exception. I just spent a week scrubbing a codebase where some dev “did the needful” and committed an on-by-default flag to bypass authentication checks because he didn’t known how to set up his local work environment.

People report the same “took a shortcut” issue with AI vibe coding, and I can confirm that I’ve had to rewrite practically everything the AI generated for me, despite using a frontier model dialed up to 11 thinking levels.

Having said that, AI is very useful for other activities like PR review, security vulnerability analysis, typo hunting, reverse engineering, etc.

I’m probably going to have to increase my subscription to the next tier but at the same time I still can’t use any of the code it generates.

If even one person can simultaneously experience "very useful, need to pay more for it" and "useless output code quality" then of course you'd expect a variety of opinions amongst the general user base.

Re: Did Claude increase bugs in rsync?

#274

Post by Unit327 »

thorum wrote: post #80

Unfortunately for the people mad about this, I predict the only thing they will accomplish by pressuring the rsync maintainers, is to discourage everyone else from responsibly disclosing their use of AI. You’re just going to make people disable Claude attribution on their commits to avoid drama.

This argument gets trotted out every time but it doesn't convince me of anything. Yes, calling things out creates an incentive for people to hide them, but so what?

Setting aside the whole AI = bad argument, let's do a metaphor. Tax evasion is bad and unethical and you should call it out where you see it. But wait, that creates an incentive for people to hide it! So I'd better not call it out, it's best to just keep my mouth shut.

Re: Did Claude increase bugs in rsync?

#275

Post by MantisShrimp90 »

I think this writer kinda took the bait which is fine someone had to do this so we couldn't debate endlessly.

But the reality is that if you were already set enough to call rsync slop because of a single post, you aren't going to be more down now. Even in these responses I see everyone nitpicking and moving goalposts as if one more commit being actually claude-aided will tip the scales from stable project to "vibe coded slop".

Software has always been fuzzy, we have never come up with an objective way to handle software quality, and this Uber hatred of llm contributions lets the humans who make egregious bugs and mistakes off the hook.

Taking a step back, we need to have more empathy and thoughtfulness of one another in this space. Its new and people are experimenting and there will be nothing good coming from personal insults and DDOsing a good project just because someone got ragebaited on threads, x, mastodon or whatever else.

How do we determine bugs and increase quality? Its almost like we have been grappling with this question for decades and I still hear people fight on the best way forward. Simple design, test driven development, user surveys, all of the above have been used as a proxy for software and they all failed to capture everything. Back in the day we used that ambiguity to give each other grace, now we use that ambiguity to tear down other creators. Whatever, if open source software really is dying its because of this toxic shit just as much as the llms

Re: Did Claude increase bugs in rsync?

#276

Post by echelon »

wolletd wrote: post #246
GodelNumbering wrote: post #234

Was just looking at commits and came across a commit and its revert original commit: https://github.com/RsyncProject/rsync/commit/d046525de39315d... ``` - if (!ptr) - ptr = malloc(num * size); - else if (ptr == do_calloc) + if (!ptr || ptr == do_calloc) ptr = calloc(num, size); ``` Written with claude. This is a good example of what slips through LLM attention. It forces all allocations to be calloc as if it is a str…

Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. Most of them written with claude. And then stuff like this is in there. That's exactly what I'd expect when someone is excited about AI usage and becomes... well, sloppy.

Seems like someone could use Claude to port rsync to Rust and the whole enterprise would be safer from things like this.

Start with unsafe then gradually convert into idiomatic Rust.

Re: Did Claude increase bugs in rsync?

#277

Post by TZubiri »

I haven't used this thing for like 10 years, when my modus operandi was googling my question and installing whatever stackoverflow suggested.

Can someone explain why one would ever use rsync (pre vibecode version) instead of cp and dd?

Can't we just 'apt remove rsync' and save ourselves the time even spent on evaluating this dependency?

Thanks

Re: Did Claude increase bugs in rsync?

#278

Post by yw3410 »

nomel wrote: post #264
jarym wrote: post #256

I've been coding for over 2 decades. I love it, I've always loved it and I likely always will. I was an AI skeptic some months ago but truly Claude and Codex have changed my development style and velocity in a way I never imagined would ever be possible. With that, yes, I produce more code and am finding more bugs. So looking over at comments in HN articles the amount of polarising hate to anything produced with AI i…

I've always noticed, within any subject involving tools, there are people who like the tools, and some people who like to use the tools to do something else. With programming, I've always been in the later: it's a tool that allows me to do what I actually love, which is problem solving, system level thinking , and providing some nice solution to that problem, that happens to be through software. So, I have an absolut…

I am anti-vibe coding if that meets your criteria?

Reviewing vibe-coded PRs and features has been utterly exhausting over the past few months.

I work on critical, mature software - a small change in behaviour can mean data loss or non-compliance with regulations for our customers. The biggest problem with AI PRs is the sheer amount of churn, extra code and lack of intent with the PRs it generates.

The only way I can describe the latter is that an AI-only PR feels to me like a painting where everything is high detail - and you have to comb over each part before you understand why it's there because so much is superfluous. A well written human PR on the other hand, is painted such that your eye naturally follows the thought process of the author so you can just nod along during the review, as if the solution was obvious.

Also when I'm _using_ the agent; at least 50 percent of my time is spent telling it to stop with it's approach so it doesn't go down a useless rabbit hole and waste tokens.

Re: Did Claude increase bugs in rsync?

#279

Post by yubblegum »

echelon wrote: post #276
wolletd wrote: post #246

Earlier quoted context omitted.

Also the amount of commits is suspicious. In the last two months, rsync had about as much commits as in the last two years before that. Most of them written with claude. And then stuff like this is in there. That's exactly what I'd expect when someone is excited about AI usage and becomes... well, sloppy.

Seems like someone could use Claude to port rsync to Rust and the whole enterprise would be safer from things like this. Start with unsafe then gradually convert into idiomatic Rust.

Your let's redo this in Rust made me wonder if generative AI will also be susceptible to software fads. One LLM writes a few blog posts extoling a new framework/lanaguge. Other agentics read these and get 'influenced'. Then they start clamoring for 'lets redo this in X!'. Can't wait to see it. /g

Re: Did Claude increase bugs in rsync?

#280

Post by logicprog »

cobertos wrote: post #265

This post just gives me more questions than answers and I'm unable to form a decision: * Why was v3.4.1 the most buggy, right before the Claude commits? Why did "nobody notice"? It's way to strange to just say welp, it must be human error. * Why does v3.4.2 have 0 bugs, or 0 bug score. And why was such an outlier (no other commit seemingly has this??) allowed to mix into aggregate statistics and bring all the "is Cla…

> Why was v3.4.1 the most buggy, right before the Claude commits? Why did "nobody notice"? It's way to strange to just say welp, it must be human error.

Why wouldn't it be except question begging priors assuming it couldn't be?

> Why does v3.4.2 have 0 bugs, or 0 bug score. And why was such an outlier (no other commit seemingly has this??) allowed to mix into aggregate statistics and bring all the "is Claude buggy?" scores down.

My original metrics which didn't filter out feature requests and questions had it at four bugs and prior to that it was even higher and it didn't make much of a difference to the overall analysis (fell well within the IQR, the lower end of it too). Also, removing one outlier just because it looks kind of funny to you, especially when we only have two Claude releases at all, would be worse in my opinion and more arbitrary.

Post reply on HN