QWE AI Academy Here’s the part the headlines miss: the buggiest rsync release in the project’s entire history shipped before Claude ever touched the codebase, and nobody opened a 329-comment GitHub issue about it. A severity-weighted analysis of every release found that earlier hotfix exceeded the post-Claude releases by an order of magnitude. The analysis ran a severity-weighted bugs-per-10-commits permutation test on every rsync release with bug data, asking only whether Claude-assisted releases were unusually buggy – and the answer wasn’t the one Mastodon wanted.
So did Claude increase bugs in rsync? Statistically, no. Did rsync 3.4.3 break some people’s backups? Yes, definitely. Both things are true, and that gap is exactly where solo developers can learn something useful about working with Claude on real code. This tutorial extracts the workflow Andrew Tridgell actually used – design first, multi-model cross-check, manual review, local VMs – and shows you how to copy it on your own projects.
What actually broke (and why “Claude did it” is the wrong frame)
Rsync 3.4.3 shipped on May 20, 2026 as a security update fixing six CVE-listed vulnerabilities, with three requiring non-default daemon configurations and two reachable through a normal pull or authenticated daemon connection – and the update included fixes tied to daemon configurations using use chroot = no, a setting that became central to several of the reported regressions. The concrete bug? Pulling files via the native rsync protocol from a daemon with use chroot = no started returning “Invalid argument (22)” on every file, while the exact same source over SSH worked fine, and rsync 3.4.2 had no issue at all. Same command, different outcome, no warning – the kind of regression that only surfaces if you happen to be running that specific combination.
That’s a subtle, domain-specific path-handling regression. An experienced C programmer working alone at 2 a.m. could write that bug. Claude could write it. The diff is not the interesting part. The interesting part is that the affected use cases weren’t covered by the existing rsync test suite or by Tridge’s manual testing. That’s the actual lesson – not “AI bad,” but “your test coverage was always the weak link.”
The workflow Tridge actually used with Claude
This is the part most takes skip. Tridge’s own account describes rewriting the rsync test suite in Python from the old shell-script design, doing the design himself, and using Claude with cross-checks from Codex and Gemini to do the grunt work. That sentence has four distinct moves in it. Most “how to use Claude” guides cover one.
- Design before prompting. Write the architecture by hand. Tridge says he did the design first and had a plan for how to validate it, then used AI tools for the grunt work because they’re good at that. Skip this step and you’re just dictating to a parrot.
- Cross-check with a second model. Run Claude’s output past Codex or Gemini before merging. Different training data, different blind spots.
- Manually review every part. Tridge reviewed every part of the output himself and ran through a significant amount of CI time getting it right – what shows up in the commit history with co-authored-by Claude is the tip of the iceberg.
- Move heavy testing local. Tridge has since moved to running most testing on local VMs to reduce CI wait time. Faster iteration loops catch more.
None of this is novel software engineering. What’s different is that it’s now your workflow with an AI agent in the loop instead of a junior dev.
A walkthrough: applying this to your own repo
Say you want Claude to rewrite a shell script test suite in Python – the exact thing Tridge did. Here’s a tighter version of the loop:
# Step 1: write the design as a markdown file BEFORE opening Claude
# design.md should specify: directory layout, test harness contract,
# how fixtures are loaded, how each old shell test maps to a new Python test.
# Step 2: feed Claude the design + ONE old test, ask for ONE new test
claude "Read design.md. Convert tests/old/test_basic.sh to tests/new/test_basic.py following the contract. Do not invent new test cases."
# Step 3: cross-check with a second model on the same output
codex review tests/new/test_basic.py --against design.md
# Step 4: run BOTH old and new tests against a known-good binary
./run_old_tests.sh > old.out
pytest tests/new/ > new.out
diff <(grep -E 'PASS|FAIL' old.out) <(grep -E 'PASS|FAIL' new.out)
The diff at the end is the part everyone forgets. If your new test suite passes 100 tests and your old one passed 102, you have two missing tests – and that gap is where your next regression will hide. Tridge himself noted that rsync’s new Python test suite reports dozens of failures when run against OpenBSD’s openrsync implementation (as of June 2026), which tells you the test suite is sensitive enough to catch real behavioral differences. Use that property.
Pro tip: When you ask Claude to port code, give it the old code and the design document in the same prompt – but never the old tests and the new tests together. Otherwise it will silently “fix” the new tests to match the old output instead of telling you they diverge.
Common pitfalls people are repeating right now
Pitfall one: trusting that “AI wrote the test suite” means the test suite is complete. It isn’t. The rsync regression slipped through because the missing tests covered a daemon mode + native protocol + use-chroot=no combination that nobody had ever scripted. Claude can only write tests for cases you describe. It can’t imagine your weirdest production config.
Pitfall two: the Co-Authored-By trailer. Since rsync 3.4.1, dozens of commits have been attributed to “tridge and claude” – and that attribution is what turned the bug into a story. Community discussion on Tildes has converged on disabling the LLM co-author signature – not because it changes code quality, but because it removes a social attack surface from people who just want to be angry. Whether you keep it on is an ethics call, but be aware it’s now a flag.
Pitfall three: pushing AI-assisted commits straight onto a release branch. The reaction was less about Claude and more about the fact that breaking changes landed on a stable branch without a corresponding test update. That’d burn you with a human contributor too.
How this compares to alternatives
If you’re now nervous about using Claude on critical code, here’s the honest comparison:
| Approach | Bug risk | Time cost | Social cost |
|---|---|---|---|
| Hand-write everything | Same kinds of bugs, just slower to ship | Highest | None |
| Single-model (Claude only) + review | Lower than no review, higher than cross-check | Medium | Medium (attribution flag) |
| Multi-model cross-check (Tridge’s setup) | Lowest in practice | Medium-high | Medium |
| Fork to a no-AI alternative (e.g. openrsync) | Different bug profile, smaller community | Migration cost | None |
The honest answer? I keep going back and forth on this. The data says Claude-assisted releases aren’t worse, but the data also can’t measure the bugs you would have caught if you’d been forced to type every line by hand and think about it. Maybe that’s a real loss. Maybe it’s romanticism. I genuinely don’t know yet, and I distrust anyone who claims they do.
What to do this week
Pick one repo. Write a one-page design document for the next feature before you open Claude. Run the first draft past a second model – Codex or Gemini both work – and compare the diffs. If they disagree on anything non-trivial, that’s your review queue. Then read Tridge’s full post end-to-end. It’s the most useful piece on AI-assisted maintenance published as of mid-2026, and the perspective there is hard-won.
FAQ
Is rsync safe to upgrade to 3.4.3?
For most users, yes. If your setup involves daemon mode with use chroot = no, the native protocol, or multiple --compare-dest arguments for incremental backups, test on a non-production machine first. As of June 2026, Tridge is deciding between a 3.4.4 release that softens the regressions and going straight to a planned 3.5.0 with much larger security changes – so a fix is coming either way, but the timeline is open.
Should I stop adding Co-Authored-By: Claude to my commits?
It depends on who reads your repo. On an internal corporate project, leave it on for transparency – your reviewers want to know. On a public OSS project with a vocal audience, recognize you’re putting a target on the commit. The code is identical either way; only the social interpretation changes.
Did the statistical analysis really clear Claude?
It cleared the claim that Claude-assisted rsync releases produced statistically more bugs than pre-Claude ones. It didn’t and couldn’t measure things like long-term code comprehensibility, maintainer skill atrophy, or whether the bugs that did ship were qualitatively different. That limitation is inherent to any permutation test on a small release sample – a blunt instrument can’t answer a subtle question. Treat the analysis as a useful floor (“the panic was overblown”) rather than a ceiling (“AI coding is fine, ship it”).