By ByteBot
rsync 3.4.3 landed in May, patching six CVEs. Some users upgraded, ran their backup jobs, and found that incremental transfers had silently stopped working — every file was being re-transferred from scratch. When they dug into the commit history and found dozens of entries tagged “tridge and claude,” the GitHub issue they filed wasn’t a quiet bug report. It was titled “Please Do Not Vibe F*** Up This Software.”
That framing — vibe coding, sloppy AI, critical infrastructure at risk — spread to Hacker News, Reddit, and The Register inside 48 hours. Then a developer named Alexis Purslane did something the outrage cycle rarely waits for: she ran the numbers.
The Data Doesn’t Support the Outrage
Purslane’s independent analysis examined 36 rsync releases spanning v2.4.6 to v3.4.3, measuring severity-weighted bugs per 10 commits. The results are not what the outrage cycle expected.
A permutation test across all 36 releases returned a p-value of 46%. In plain terms: if you randomly grabbed any two releases from rsync’s entire history, there’s a 46% chance they’d look as “bad” as the Claude-assisted ones. A Fisher’s exact test came back at 74%. These are not the numbers of a catastrophic AI-induced regression. These are noise.
One release stands out more than either Claude release: v3.4.1, the version immediately before AI assistance began, logged the highest bug rate in rsync’s history at 39.39 severity-weighted bugs per 10 commits. Nobody wrote a furious GitHub issue about that. There was no technology to blame.
Meanwhile, v3.4.2 — the first release with Claude commits — had a bug rate of exactly zero.
What Actually Broke, and Why
The actual regression in 3.4.3 was in the security hardening, not the AI-assisted test suite rewrite. To fix six CVEs, Tridgell replaced path-based system calls with symlink-race-safe do_*_at() wrappers. Those wrappers broke relative path resolution in daemon mode when chroot = no is set — the pattern that powers --link-dest=../prev and --compare-dest=../prev in many incremental backup configurations.
Here’s the irony the outrage missed entirely: the flood of security reports that forced Tridgell to ship rapid CVE patches in the first place? Many of them were generated by AI-powered vulnerability scanning tools. AI-generated reports → overwhelmed maintainer → rapid security changes → regression. The community blamed the wrong AI.
What Tridgell Actually Did
In his own account, Tridgell is clear about how he used Claude: “I did the design for that myself, but used claude with cross-checks from codex and gemini to do the grunt work.” The work in question was converting rsync’s aging shell-script test suite to Python — implementation work on a framework he designed and reviewed in full.
I did not just vibe-code ‘convert test suite to python.’ I’m a software engineer with 40 years experience.
Andrew Tridgell, rsync creator
This is not vibe coding. This is a senior engineer using AI as a productivity tool under close supervision — the same way they’d use a code completion tool or a linter. The “tridge and claude” commit attribution was a choice for transparency, not a confession.
The Right Question Nobody Is Asking
The outrage debate — “should AI be allowed in open source at all?” — is the wrong question, and the answer most communities are reaching for (a blanket ban) creates a worse problem than it solves.
Flathub now bans AI-generated code entirely. GNOME banned it from extensions. Several projects maintain a “slopfree” pledge. These policies penalize disclosure. A developer who transparently attributes AI assistance faces rejection; one who doesn’t disclose and submits clean code faces nothing. Banning AI doesn’t remove AI from open source. It drives it underground.
The Linux kernel’s approach is more honest: AI-generated contributions are allowed, disclosure is required, the human contributor owns the code entirely, and it’s held to identical review standards. You don’t get a pass because an AI wrote it. You don’t get flagged for using one.
That’s the governance model open source needs — and the conversation across projects hasn’t converged on it yet.
The Lesson
rsync’s maintainer used AI responsibly, the data shows no statistical harm, and the regression that actually broke backups came from security hardening, not AI output. The outrage was premature.
But the underlying concern is real: open source projects need clear, enforceable standards for AI use — not bans that create a two-tier system, but accountability frameworks that make disclosure the default and hold all code to the same bar. The Hacker News thread has 339 points and counting. The community cares. It just hasn’t agreed on what the right answer looks like.
It should get there before the next rsync.
