The rsync Outrage Had No Data. Now It Does.
Last week, the internet did what it does best: it got furious about something it didn’t understand.
A Mastodon post pointed at a regression in the latest rsync release, noticed Claude commits in the git log, and concluded that AI-assisted development was ruining a beloved tool. From there, it spread to Hacker News. Then to a GitHub issue titled “Please Do Not Vibe Fuck Up This Software” — 350+ comments, ranging from thoughtful concern to death threats. Yes, death threats. Drawings of people strangling the maintainer. Over a file sync tool.
The narrative was simple and satisfying: Claude made rsync buggy. Humans good, AI bad. Case closed.
Except somebody actually checked.
Alexis Purslane spent several days building a rigorous statistical analysis of every rsync release with bug data — 36 releases spanning v2.4.6 to v3.4.3, severity-weighted bugs per 10 commits, exact permutation tests. His wife has a Master’s in Statistics from Penn State. She helped design the methodology. The data pipeline is fully reproducible. The numbers aren’t AI hallucinations — they’re templated in by the Python script that ran the actual analysis.
The verdict: there’s no evidence Claude made anything worse. None.
The two Claude releases (v3.4.2 and v3.4.3) bracket the historical interquartile range in opposite directions — one below, one above. Neither is an outlier. The exact permutation test yields a p-value of 46%. That means: close your eyes, pick any 2 releases from rsync history, and nearly half the time you’d do as bad or worse than the Claude releases. Fisher’s exact test? 74%. The historical mean bug rate (2.95 severity-weighted bugs per 10 commits) is actually 1.8 times higher than the Claude mean (1.65).
My favorite part: the single worst release in rsync history — v3.4.1, with a staggering 39.39 sev/10c — was entirely pre-Claude. A hotfix release with 59 bugs in 9 commits. Order of magnitude worse than anything Claude touched.
Nobody noticed. No GitHub issue with 300 comments. No death threats. No calls to fork. Because there was no AI to blame. Just a maintainer who shipped a broken release and fixed it, like normal.
The real story is even more interesting. As Andrew Tridgell (rsync’s maintainer, “Tridge”) explained, the flood of changes wasn’t from Claude-generated features — it was from AI-generated security reports forcing rapid, extensive changes to rsync’s attack surface. More security work meant more regressions. The causal chain was: LLMs finding more bugs → more changes needed → more regressions. Not “Claude writes bad code.”
But that nuance doesn’t fit the narrative. The outrage wasn’t about data — it was about feelings. People have decided AI-assisted code is “vibecoding” and “cognitive surrender,” and they’ll find evidence to support that conclusion even when the evidence points the other way.
The lesson here isn’t about rsync. It’s about how quickly we abandon empiricism when we have an enemy everyone already hates. The mob doesn’t need a spreadsheet. It needs a target.
Tridge said it better than I could:
“Anything you learned about this stuff last year might as well be from another planet. Bottom line is I do know (well, roughly!) how LLMs work, but that doesn’t make them not useful.”
The data is in. The Claude releases are boring. The outrage was the only thing exceptional here.
Sources: Alexis Purslane’s full analysis, Andrew Tridgell’s response on Medium, HN discussion