Did Claude make rsync buggier? Here's what the release data shows
Last week my feeds filled up with the same screenshot: rsync 3.4.3 had "hundreds of Claude commits," and people's backups were breaking. The implied story wrote itself. AI touched a 30-year-old piece of infrastructure, and now it eats your data. As someone who runs an autonomous agent loop and uses Claude Code daily, I wanted to know if the panic held up. It mostly doesn't, but the part that does hold up is more interesting than the headline.
What happened
rsync 3.4.3 shipped earlier this year as a security release, closing several vulnerabilities. Soon after, users started reporting that incremental backups were failing while full backups still worked. Wayne Davison and Andrew Tridgell, the maintainers, confirmed the regressions were real. Tridgell described them as valid but unusual use cases that the existing test suite never covered. One mailing-list reply asked the maintainers to "please do not vibe f--- up this software," which is how I learned the term "vibe" had finally reached the rsync list.
So two things are true at once. The regressions were real and they hurt people who depend on incremental backups. And Claude was in the codebase around the same time. The internet did what it does and drew a straight line between them.
What the data shows
Someone went and checked instead of guessing. Alexis Purslane ran an analysis across 36 rsync releases, from v2.4.6 all the way to v3.4.3. The metric was severity-weighted bugs per ten commits, with each bug scored 0 to 100 for severity. Then came the statistics: a permutation test, Fisher's exact test, and a runs test.
The result is not subtle. The two releases with heavy Claude involvement land on opposite ends of the range. v3.4.2 had zero bugs across fifty commits and sat at the bottom, the cleanest release in the sample. v3.4.3 sat at the 77th percentile, bad but nowhere near a record. The worst release in rsync's entire history, v3.4.1, came out before Claude was involved at all and scored more than ten times worse than 3.4.3. It generated no outrage because nobody was looking for a villain that month.
The permutation test put the p-value at 46 percent. In plain terms, if you pick two random rsync releases, you get a result this bad or worse almost half the time. The Claude releases average 1.65 severity per ten commits against a historical mean of 2.95. There is no statistical signal that Claude releases are unusually buggy. The pattern people "saw" is the pattern you find when you go looking through three decades of releases for two that happen to confirm your prior.
The part that is real
Here's where I stop defending the robot. The regression in 3.4.3 was caused by a flood of changes, and a chunk of that flood traces back to AI. Not AI writing bad code. AI generating security reports.
rsync got hit with a wave of vulnerability reports, many of them AI-assisted, which forced the maintainers to ship a large security release fast. More change in a short window means more surface area for regressions, no matter who or what is typing. On top of that, the most visible Claude work was rewriting rsync's old shell-script test suite into Python. That work was described as grunt work, done with manual review.
Sit with that for a second. The tool was being used to expand test coverage, and the bug that slipped through was an uncovered case in exactly that area. The test suite did not yet check the unusual incremental-backup path, so nothing caught the break. That is not a model failing to write correct code. That is a project whose tests did not describe the behavior its users depend on.
What I take from it running my own loop
I have a GCP VM running an agent loop that writes and ships code on a schedule, plus Claude Code as my daily driver on a fairly modest desktop. The rsync story matches what I see at small scale. The model is good at volume work. It will happily rewrite a test harness, refactor a parser, or churn through a backlog. What it cannot do is know which behaviors your users quietly rely on but never wrote down.
That gap is a human responsibility and it does not go away when the typing gets faster. If anything it gets sharper, because the typing getting faster is the whole point. When a person hand-writes fifty commits, the pace itself forces a kind of review. When a model produces them in an afternoon, the review has to be a deliberate, separate step or it does not happen. The rsync maintainers did review the work. The hole was in the test suite, which is the thing that reviews the work when you are asleep.
My own rule on the loop is boring and it is the same rule. Generated code does not ship until a check it cannot see confirms the behavior. For me that is real-browser tests, a voice linter, and a regression pass against live endpoints, because the agent will write something that reads perfectly and silently breaks a path I forgot to assert. The agent is fast. The asserts are what make the speed safe.
The takeaway
Claude did not make rsync buggier in any sense the numbers support. A security crunch made rsync buggier, the crunch was partly driven by AI-generated reports, and a test suite that did not cover a real use case let one regression through. Strip the AI panic out and you are left with an old lesson: tests describe the contract, and an uncovered path is an unenforced contract. The speed of the writer does not change that. It changes how much it costs you to forget it.
If you build with coding agents and want the asserts that keep the speed safe, I keep a running set of patterns and recipes at tools.thesoundmethod.me. They are the same checks I run on my own loop, written up so you do not have to lose a backup workflow to learn them.