Did Claude Increase Bugs in rsync?

1 · Background: The “rsync Outrage”

In late May 2026, rsync blew up. GitHub, Hacker News, Lobsters: hundreds of people arguing about whether open-source maintainers can ship AI-written code and have it be reliable — and whether the people taking the code for free get to demand how it is made.

On May 30, 2026, a GitHub issue titled “Please Do Not Vibe Fuck Up This Software” was opened against the rsync repository. It attached a screenshot of a Mastodon post criticizing the project’s use of Claude. No bug report. No technical content. What followed was extraordinary: 329 comments and counting, ranging from thoughtful concern to outright harassment.

The thread did not stop at words. One user posted My Little Pony drawings of themselves strangling the “project janitor that pushed vibecoded commits”:

It spread to Hacker News and Lobsters, generating hundreds more comments. The central claim, repeated everywhere: Claude-assisted development introduced bugs into a previously stable tool.

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

On Lobsters, user boramalper wrote:

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. One metric, every release, no model.

On the HN thread, user zos_kia pointed at the confound directly:

From a cursory look, it looks like a security fix in response to a CVE surfaced a coding error which has been present in the code since 2007. This is so banal that it’s actually hilarious to see people lose their shit over it.

— zos_kia on Hacker News

On Lobsters, user jbert spelled out the causal chain:

The trigger for the increased volume of changes (and hence increased number of regressions) was the influx of (mostly) LLM-enabled security issues. i.e. the causal chain was: LLMs → more known security issues → more changes needed than usual → more regressions than usual.

— jbert on Lobsters

These users identified the exact confound: it wasn’t AI writing the code that caused regressions. It was AI finding security holes that forced tridge to ship more changes than usual — and more changes means more regressions, regardless of who wrote them. This is not a Claude problem. It is a “more changes” problem. Tridge himself confirmed this causal chain in his response, describing how a flood of AI-generated CVE reports forced rapid, extensive changes to rsync’s attack surface. A retired developer who would rather be sailing, he reached for Claude to help with the volume: writing test suites, adding defence-in-depth hardening, and working through the security backlog. He acknowledged the regressions in v3.4.3 but said he had deliberately prioritized security fixes over edge-case compatibility.

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 attributed

Bug counts come from three sources: GitHub issues in the rsync repository, the rsync Bugzilla instance, and the rsync mailing list. Issues filed against the rsync project were collected via the GitHub REST API. Bugs from the mailing list were identified by parsing message subjects for bug report patterns and cross-referencing with the project’s issue tracking. Bugzilla entries were collected via the Bugzilla API; each entry has a “Version” field that explicitly states which release the bug was reported against, and bugs are attributed to that release. GitHub issues and mailing-list bugs are attributed to the most recent release that shipped before the bug was reported.

Why this metric

The critics’ claim is a simple comparison: did the rate go up? The simplest honest response is a simple rate. 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.

What this metric does not do

It 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 the fairest response.

4 · Results

Claude Releases

How Normal Are the Claude Releases?

The Distribution

Here is where these releases fall in the distribution of all prior releases:

0.010.1110100

Historical
Claude


Middle 50% (IQR)



Outside IQR