Did Claude make rsync buggier? The numbers say no

The rsync project recently merged commits authored with Claude, and the AI-skeptic corner of the internet quickly declared the result a disaster. Alexis Purslane went and checked. Across 36 rsync releases from v2.4.6 to v3.4.3, including the two Claude-touched releases v3.4.2 and v3.4.3, Purslane scored every bug for severity using an LLM grader and ran exact permutation and Fisher tests on the per-release rates. The Claude releases come in at 0 and 3.29 severity-weighted bugs per 10 commits. The historical mean is 2.95. The p-values are 46% and 74%.

In other words, no statistical signal that Claude made rsync worse. The most jagged release in the sample is v3.4.1, at 39.39 sev/10c, which predates the Claude commits and generated no controversy at all. Purslane is candid about the data: the sample is small, the severity grader is itself an LLM, and the methodology section spells out where the noise lives. But the headline holds. "Claude releases bracket the IQR in opposite directions" and sit inside normal historical variation.

The analysis is on Purslane's blog and worth reading if you have an opinion on AI in mature C codebases. The most interesting finding is not the verdict. It is the absence of an effect on a project where the priors against AI were already loud.

Why it matters

Most arguments about AI-assisted contributions to open source run on vibes. If your team is deciding whether to accept Claude-authored patches, you now have a public, reproducible template for the kind of evidence those decisions should rest on. Run it against your own repo before you write the policy.