0 · Disclaimer: How AI Assistance Was Used

In order to avoid accuastions of this "just being Claude defending Claude," "AI slop," "probably all hallucinations," etc., I've decided it's probably worth explaining a few key points about how this report was created:

• All metrics, methodology, and data sources were exclusively chosen by me, in consultation with my wife, who has a Master's Degree in Statistics from Penn State University.
• The methodology is directly based on my wife's input: she was the one that pointed out that trying to just compare bugs per ten lines of code before and after would likely be too effected by noise because of the low number of post-Claude samples, and that, for similar reasons, trying to build some kind of linear regression model to ascertain the relative effects of different variables would probably also not work. She specifically told me that looking at where the post-Claude releases fall into the historical distribution, and how likely from the historical distribution we would be to get releases as "bad" or worse than the post-Claude releases, was probably the best that could be done.
• I spent several days on this, two before even creating the GitHub repo and had at least one major total rewrite of the report to use a better methodology (given the feedback from my wife mentioned above). This was a lot of manual, cognitive effort on my end.
• The scripts used to fetch the data, collate it into a DuckDB database file, construct the views on that DB, and then do the statistical analysis on that data, were indeed written by GLM 5.1, as was the HTML and much of the original prose for the final report webpage you're looking at right now.
• Crucially, however, all numbers, statistics, cards, and graphs in this report are automatically templated in directly by the Python script that ran the statistical analysis, thus avoiding any possibility of hallucinations or inconsistencies in the numbers.
• After posting this on Hacker News and recieving almost no substantive input, discussion, or response on the actual content of the article, I decided to rewrite all of the prose in my own voice. If anyone complains about my verbosity or sentence structure — as they usually do, which is the reason I originally let the AI write the prose, among other reasons obsoleted by templating — they can go fuck themselves.
• If you want to replicate the data and results here, and inspect exactly how they were calculated, you can find the repository here. I have purposefully made it so that the pipeline can be run end to end completely from scratch, so you can see the entire pipeline end-to end, with no mysterious DB blobs forcing you to trust that I didn't doctor or screw up the data. If you want to be mad about the numbers, look there first.

1 · Background: The rsync Outrage

In late May 2026, rsync blew up. First, an evidence-free Mastodon post was made pointing to a spurious correlation between a regression that particular user experienced upon upgrading to a release, and that release having Claude commits in it. It was viewed an unknown number of times, but even likes and boosts passed the thousands mark handily, and it gained significant traction — as all spurious anti-AI hate does —, seeing 58 replies from 32 unique users. Someone rages about "cognitive surrender" with no evidence; another suggests adding rsync to the famous open-slopware blacklist. From there, it spread to Hacker News, with 81 comments, full of mixed dread, anger, and crowing about how this finally proves once and for all no one can use LLMs safely. Among all that was one particular comment which spurred further the view that the regressions and bugs were caused by Claude.

This On May 30, 2026, this burgeoning outrage emergently coalesced into a single focal point: a GitHub issue titled "Please Do Not Vibe Fuck Up This Software", opened against the rsync repository. It attached a screenshot of the Mastodon post criticizing the project's use of Claude. That's it. No bug report, no technical content, no attempt to actually ascertain if the concern was real or justified; just 350+ comments ranging from thoughtful concern to outright harassment (most of the most egregious, unreasonable, and outright violent comments have since been deleted; few thought to preserve them).

The thread did not stop at words. As is typical for anti-AI users, it eventually escalated to fantasies of violence. One user posted a now deleted comment including My Little Pony drawings of themselves strangling the "project janitor that pushed vibecoded commits":

Completing the internet outrage cycle, this issue in turn spread to Hacker News, generating hundreds more comments. Some attempted to point at the number of regressions after the introduction of Claude — "The Linux Mint Timeshift tool has an issue open documenting a number of regressions that are currently open on the rsync issues page, that were only introduced post-vibecoding" — as evidence that it was worse. Others pointed out that those regressions were not caused by Claude, and in response, the goalposts were moved again. Over and over, the core theme was one central claim, repeated everywhere: Claude-assisted development introduced bugs into a previously stable tool. AI is cognitive surrender, is cocaine, is loss of craft, and the users are right to be angry as a result:

People are very justifiably angry that a very stable, well trusted tool, has started to immediately go downhill… all because the main dev is vibecoding that software.

— fao_ on Hacker News

However, this isn't doesn't have to be a question solved only on the basis of — ironically — vibes. This is something that could be, at least to a degree, empirically tested. Some even pointed that out:

On Lobste.rs, in response to the Medium essay Tridge himself posted in response, finally some users like boramalper begin to actually ask for evidence one way or another:

It'd be interesting if someone actually did a timechart of regressions after each release (if at all possible) to see if the number actually went up recently or not.

— boramalper on Lobsters

User bitshift replied: "I would also love to see such a chart. It wouldn't be completely informative… But at least it would be something objective we could measure."

This analysis is that chart. Or, well, as best as it can be made, given the limitations of the data (see the previous section).

2 · Executive Summary

• 46 releases with bug data, spanning v2.4.6 to v3.4.3
• 2 releases have Claude commits: v3.4.2 (9 Claude, 0.80 bugs/10c) and v3.4.3 (28 Claude, 6.76 bugs/10c)
• Both fall inside the middle 50% of the historical distribution
• Exact permutation test p-value = 46%: if you pick any 2 releases at random, you'd score as bad or worse 46% of the time
• The historical mean is 2× the Claude mean (7.59 vs 3.78 bugs/10c)
• No regime shift detected: runs test p=0.123, sequence is consistent with randomness
• v3.4.1 (102 bugs / 9 commits, no Claude) is an outlier but belongs in the baseline — it is a release, and the distribution already captures it

3 · The Metric

The analysis uses a single metric: bugs per 10 commits (bugs/10c). For each release, divide the number of bugs attributed to it by the number of commits in its range, then multiply by 10. This normalizes for release size.

bugs/10c = (bug_count ÷ total_commits) × 10

How commits are assigned to releases

Every commit on the default branch was ordered by committer date to produce a sequential timeline. Each git tag points to a specific commit in this timeline. A release's range is all commits between the previous tag and its own tag. Pre-release tags ("pre", "rc") are skipped as boundaries and absorbed into their final release. Every commit belongs to exactly one release.

How bugs are found and assigned to releases

Bug counts come from three sources:

1. GitHub issues in the rsync repository (collated via the GitHub REST API),
2. the rsync Bugzilla instance (collected via the API),
3. and the rsync mailing list.

GitHub issues and mailing-list bugs are attributed to the most recent release that shipped before the bug was reported. For Bugzilla, each entry has a "Version" field that explicitly states which release the bug was reported against, and bugs are attributed to that release.

Why the release is the unit of analysis

Why group commits by release, bugs by release, and then ascertain the correlation — or lack thereof — between Claude commits and bugs through the intermediary of releases? This is for two reasons.

First, because the claim that the critics are making is also, itself, made in terms of releases: that having any Claude commits in a release makes the whole release more buggy as a whole in a noticeable way, not just that Claude-authored commits may introduce more bugs; the latter is a different metric, because later Claude- or human-authored commits could correct for those bugs within the same release, and nobody would then notice as part of the release, and overall it wouldn't matter to users; additionally, it's simply important, as stated elsewhere, to meet the claim of the critics where it's at. If this forces them to make their claims more nuanced — or otherwise move the goalposts — then mission accomplished.

Second, it's a problem of attribution: the vast, vast majority of bugs do not state exactly which commit caused them, because doing so would require extensive research and analysis that is often not worth it in favor of simply fixing-forward, and even if that analysis was done — via something like git bisect — it wouldn't necessarily result in anything useful, or anything at all. Many bugs can result from a combination of multiple commits, often separated significantly over time, where it's unclear whether one commit or the other really introduced the bug. Or, one commit can reveal several latent bugs introduced by other commits at once, and so on.

Why bugs and commits?

The critics' claim is simplistic, absolute, and universalistic: the rate of bugs in the Claude-exposed releases went up. Therefore, the simplest honest response is to analyize precisely what is being claimed: bugs, commits, releases, and Claude-exposed commits. If the Claude releases sit in the middle of the historical distribution, the burden shifts to the critics to explain why this particular middle is somehow worse than all the other middles that came before it. Even if that results in is shifting the conversation toward a more nuanced discussion of the quality and type and user impact of the bugs in the releases, it will already have been a major win for the pro-AI crowd, and a shifting of the goalposts for the anti-AI crowd, and then we can do further analysis based on that. And the ball's in the anti-AI court for that game.

What this approach does not do

I'm aware that this metric does not control for commit complexity, security intensity, or bug severity. It does not distinguish between a one-line typo fix and a CVE patch. It is a blunt instrument. But the critics' accusation is also blunt: "Claude is making things worse." A blunt instrument is what is required in response. Blood begets blood.