The study that says Claude didn't break rsync was itself written by an LLM

A defense of AI commits that reads like it was generated by one

When a Mastodon post accused rsync's maintainer of letting Claude-authored commits degrade the project, a statistical rebuttal showed up to settle it with data. The author, logicprog, built a severity-weighted bug metric, ran permutation and Fisher's exact tests across every rsync release, and concluded the outrage had no empirical footing. It hit 355 points and 364 comments — and the thread spent most of them arguing the rebuttal had the same disease as the thing it was defending.

What the numbers actually say

The metric is severity-weighted bugs per 10 commits (sev/10c): each of ~2000 bug reports gets a 0–100 severity score from an LLM at temperature 0, normalized and summed per release. The headline comparison:

Historical mean was 2.95 sev/10c; the Claude releases averaged 1.65. An exact permutation test returned p ≈ 46% — pick two random releases and you'd get an equally bad or worse spread nearly half the time. Fisher's exact came back at 74%. The author's load-bearing observation: v3.4.1, the single worst release rsync ever shipped, predates Claude entirely, and "nobody noticed because there was no AI to blame."

The two-datapoint problem nobody could unsee

The thread's sharpest objection is arithmetic. You cannot draw a statistical conclusion from two AI-touched releases, no matter how many tests you stack on top.

"Wait, how is any of this relevant if there were only 2 Claude commits? My statistics courses are far behind me, but don't you need at least 30 data points to conclude anything?" — a commenter recalling his stats coursework

"if you write a paper where you get statistical conclusions out of whole 2 datapoints you'd be laughed out of the room" — a skeptic on the sample size

And the v3.4.2 zero is doing a lot of quiet work: a release with literally 0 bugs, an outlier unlike any other in the set, dragging the Claude average down.

"Why does v3.4.2 have 0 bugs… And why was such an outlier… allowed to mix into aggregate statistics and bring all the 'is Claude buggy?' scores down. Tbh idk how that wasn't a red flag in the author's analysis…" — a reader left with more questions than answers

Others flagged that attributing bugs by release date biases everything: 3.4.1 shipped a day before 3.4.0's bugs could be filed, so they pile onto the longer-lived patch release; and recent releases simply haven't had time to accumulate reports yet, as one reader laid out point by point.

The ex-Meta engineer who found a real one

The most concrete contribution wasn't a stats critique — it was a code review. Max, who says he worked on HHVM at Meta, pulled a specific Claude-written commit and its revert:

"This is a good example of what slips through LLM attention. It forces all allocations to be calloc as if it is a strict upgrade. For large and recursive allocations, this becomes a significant cost… if you read the description of revert half carefully, it's easy to tell that even that was written by an LLM." — an ex-Meta engineer who worked on HHVM

Amluto went further, walking through a commit that mechanically renamed do_foo(args) to do_foo_at(args) — _at meaning "at a directory fd" that's never actually specified — and a function literally named do_utimensat_at:

"There's a function called do_utimensat_at. Is Claude stuttering?… If you want to fix all the gunk in a C program like rsync by LLM magic, go rewrite it in Rust… at least use a language that is more resistant to slop." — a systems programmer auditing the diff

The meta-irony, and a harassment story underneath

The recurring charge is that the defense ate its own argument: a piece insisting LLMs don't confidently produce garbage was itself, by several readers' read, LLM-written and statistically overconfident.

"the author used an LLM to interpret data in this study, and seems to have made the same category of mistake (confidently asserting falsehoods) that the study was supposed to be investigating" — a reader naming the meta-irony

The author clarified in the thread that the report cards and numbers are templated in by a script, not hallucinated by a model — "Hallucinations are a moot point" — and tptacek, after praising the work, gave a writing note: use the LLM to critique structure, but never ship a single word it suggests.

The ugliest part is real. The post documents the original maintainer drama spilling into outright harassment — My Little Pony drawings of someone strangling the "project janitor that pushed vibecoded commits," and death threats. One correction landed in the thread: Lobsters maintainer pushcx noted the brigading never actually reached Lobsters, pointing to the code that prevents it, and asked for a fix.

The honest verdict: not exonerated, just not convicted

Strip the p-values and the result is narrower than either camp wants. The data doesn't show Claude wrecked rsync — but with two releases and a metric that flattens a one-line typo and a CVE patch into the same weight, it can't show it didn't, either. The most durable prediction in the thread came from a reader who saw past the math entirely: pressure the maintainers hard enough and you don't stop AI commits, you just teach everyone to stop disclosing them.