Live data from Hacker News

Did Claude increase bugs in rsync?

alexispurslane.github.io

201–210 of 611 posts

Re: Did Claude increase bugs in rsync?

#201

Earlier quoted context omitted.

I'm not interesting in joining into some argument you're having with someone on lobste.rs

You're not supposed to join. You said you didn't know why I was defensive. I showed you those posts as evidence of the stigma attached to LLMs and their usage. Now you know why.

It doesn’t help your case that your response is to say “well I’ll just hide my use.” That’s fraud.

Re: Did Claude increase bugs in rsync?

#202
post #142

Earlier quoted context omitted.

I mean, I don't think commits are the place for tool attributions. I want to know what the change was, I'm not really interested in your tool selection (put that in the PR if it's relevant). It'd be just as irrelevant to see "written on my macbook in neovim"

Depends on what the claude attribution actually means. A lot of people will just get the thing building and then ship. To me that attribution is generally a red flag.

It means “this contribution likely infringes someone else’s copyright.”

Re: Did Claude increase bugs in rsync?

#203
post #169

Earlier quoted context omitted.

Your analysis was so thorough, rigorous, and objective, that you couldn't be bothered to write it yourself. Do you genuinely believe an article written by AI defending itself is going to convince anyone who wasn't already on your side? All you're doing is giving more fuel to the "anti-AI crowd" you hate so much.

Okay, so you didn't respond to any of my rebuttals — like the double standard between anti-AI and pro-AI claims, one of which gets to make claims based on cherry-picked anecdotes, and the other which must produce rigorous studies — you're just going to insult me/my work. Cool. > Your analysis was so thorough, rigorous, and objective, that you couldn't be bothered to write it yourself. Do you genuinely believe an arti…

> like the double standard between anti-AI and pro-AI claims, one of which gets to make claims based on cherry-picked anecdotes, and the other which must produce rigorous studies

This statement is honestly so ridiculous that I felt it didn't warrant a direct response, but here's one anyway: AI enthusiasts have been proudly proclaiming for literal years that AI makes them 10x as productive based on cherry-picked anecdotes with zero empirical evidence to back it up. It's way, way too late to claim hypocrisy here. As I stated under the original submission about this topic, irrational anti-AI behavior is usually just an equal and opposite reaction to irrational pro-AI behavior.

> I rewrote all the prose in the entire document just to satisfy critics like you.

And that doesn't help. If anything, editing the AI output to make it read less like blatant slop just comes off as deceptive, like you're trying to hide the fact that the analysis was AI generated. Looking at the commits, you were adding more AI generated text less than 2 hours ago[0] before quickly editing out one of the most blatantly sloppy sentences I've ever read[1].

Regardless, the final contents of the article are not the main issue. Even if we ignore the bias clearly on display there, the premise alone is enough to dismiss the entire thing as heavily biased and chasing a pre-determined conclusion - of course someone who is so dependent and trustful of AI that they decide such an analysis on the bugginess of AI code should itself be written by AI is going to steer the conclusion towards "actually AI code is good and you luddites are overreacting". The entire concept is so tone-deaf that failing to notice it or predict the criticism before publishing is enough to prove the bias.

[0] https://github.com/alexispurslane/rsync-analysis/commit/e029...

[1] https://github.com/alexispurslane/rsync-analysis/commit/740b...

Re: Did Claude increase bugs in rsync?

#205

Earlier quoted context omitted.

IMO "bugs per commit" is even worse than that, because, in addition to what you say, it also hides the extraordinary spike of commit activity of a project that had previously been stable. [0] It is the exact metric you'd choose if you wanted to make the current situation of rsync look like not a big deal. [0] https://github.com/RsyncProject/rsync/graphs/commit-activity

Yes, but we know why there was an "extraordinary spike," and it has nothing to do with rsync being "vibe coded." The maintained has directly addressed this.

> The maintained has directly addressed this.

Not sure if this is mentioned somewhere else, but looks like the maintainer has a blog post that addresses this: https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0

Re: Did Claude increase bugs in rsync?

#206

Earlier quoted context omitted.

You're not supposed to join. You said you didn't know why I was defensive. I showed you those posts as evidence of the stigma attached to LLMs and their usage. Now you know why.

It doesn’t help your case that your response is to say “well I’ll just hide my use.” That’s fraud.

No.

Re: Did Claude increase bugs in rsync?

#207

Earlier quoted context omitted.

[flagged]

It makes no sense at all to do that. The only thing that matters is whether the code is good.

That’s not the only thing that matters. The provenance of the code also matters enormously, specifically whether the person contributing it actually has the right to do so.

If I contributed code to an Open Source project behind my old employer’s back, that would have been bad, because that code was owned by them and not me, even if I wrote it on my own time using my own equipment, because of the contract I signed with them.

If I copied code out of an AGPLv3-licensed codebase and contributed it to a BSD-licensed codebase without telling anyone, that would have been bad, because I did not have the right to change the license on that code to BSD (or change the license on the codebase to which I was contributing to AGPLv3).

If you use an LLM to produce code, you may well be doing the latter since an LLM is actually just regurgitating portions of its inputs. This is not a hypothetical scenario; I’ve personally encountered a case of someone using an LLM attempt to contribute code I recognized from a specific Open Source project under one license to another project under a different license, while claiming they “wrote it themselves.”

Any project that accepts contributions needs to take liability seriously and manage their risk appropriately.

Re: Did Claude increase bugs in rsync?

#208
Thank you for (re)writing this in your own voice. Despite how much effort might be put into methodology, data collection, etc.. reading slop is unbearable, full stop. It's not intentional, but I have almost a nauseated reaction when the "AI tone" comes though, regardless of how good the data or how accurate the writing is.

Your verbosity and sentence structure are not a problem. I hope that publishing this gives you a bit more confidence in your writing, because it's legitimately good.

Re: Did Claude increase bugs in rsync?

#209
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.

I'd be willing to be that an undisclosed LLM disclosure will follow a developer around for the rest of their career

That kind of fraud absolutely should. (I suspect you mean “undisclosed LLM use.”)

Re: Did Claude increase bugs in rsync?

#210

needs a tldr; im not reading all that. maybe claude can summarize it for me.

And anti-AI people accuse people who use AI of being intellectually lazy. First of all, it's long because it's expanded to respond to all the criticisms. It seems that either something can be short, and dismissed as incomplete, or it can be complete, and dismissed as being long. Nice Kafka trap. Additionally, there's literally an Executive Summary section right there, for your TLDR.

Asked your Clanker what a joke is.
Post reply on HN