Please Do Not Vibe Fuck Up This Software

Original Article ↗ Hacker News Discussion ↗

A long‑trusted open source tool, rsync, has recently seen tens of thousands of AI‑assisted code and test changes, coinciding with reports of regressions in backup workflows and build problems on some systems. Commenters are split between alarm over “vibe‑coded” changes to critical, mature infrastructure and sympathy for an overburdened volunteer maintainer trying to fix security issues with new tools. The exchange raises broader questions about responsible use of coding assistants, how much stability users can expect from free software, and what constitutes acceptable behavior when criticizing open source maintainers.

Context: rsync, AI assistance, and regressions

  • Thread centers on rsync 3.4.3+ regressions appearing after a burst of AI‑assisted (“Claude”) commits.
  • Users report backup failures, broken incremental copies with multiple --compare-dest, higher CPU usage, and build failures on older kernels.
  • Many are alarmed that a long‑trusted, “finished‑feeling” backup tool is seeing tens of thousands of LOC changes in weeks.

What actually broke (as discussed)

  • One highlighted regression is tied to a specific commit (30656c5e) that changed syscall / path‑handling logic; it affects incremental backups using --compare-dest.
  • Several issues are linked to hardening changes that fix path‑traversal CVEs in daemon mode with chroot = false; some workflows that relied on previous behavior now fail.
  • Another issue: build failures on Linux <5.6 and older Darwin; these platforms were already effectively deprecated.
  • Many AI‑coauthored commits are test-suite and CI changes, including a full rewrite of shell tests into Python, which some see as destabilizing the safety net.

Debate over AI and “vibe coding”

  • Critics: AI encourages “vibe coding” (large, poorly understood changes, weak review), increases regression risk, and is especially dangerous in core tools like rsync.
  • Supporters: AI is a reasonable assistant for security audits, edge‑case tests, and refactors; bugs and regressions have always existed.
  • Disagreement over whether AI materially increased bug rate; some demand evidence, others argue correlation (big AI burst → visible regressions) is already worrying.

Open-source maintenance and user expectations

  • One side stresses: maintainers are volunteers, owe users nothing, can choose any tools, and users should pin versions or fork if unhappy.
  • The other side: “no warranty” doesn’t preclude criticism; breaking trusted backup software is akin to “pissing in the free soup.”
  • Several note chronic underfunding of critical OSS and suggest structural funding (taxes on big tech, public funding, better social safety nets).

Process, testing, and issue etiquette

  • Many say root cause is inadequate regression testing, not AI per se; correctness of tests is as critical as main code.
  • Some argue mature, widely deployed tools should change slowly, in small, reviewable patches.
  • The original GitHub issue is widely criticized as low‑effort, hostile, and more like social‑media brigading than a proper bug report, though others see it as a legitimate alarm about declining reliability.