From ‘vibe coding’ to broken backups
AI-assisted coding in open-source projects, often called “vibe coding,” refers to using large language models to quickly generate patches, refactors, or features that compile and pass basic checks but may introduce subtle bugs, regressions, or technical debt that maintainers must later uncover and repair through manual review, expanded tests, and stricter governance policies. This tension is no longer theoretical. In rsync, a widely used backup utility, incremental backups began failing for some users after a security-focused update to version 3.4.3. What started as a routine bug report escalated when users noticed dozens of commits attributed to “tridge and claude,” revealing that rsync creator Andrew Tridgell had been working with an AI assistant. A frustrated GitHub post titled “Please Do Not Vibe Fuck Up This Software” captured growing anger that AI code quality issues were now affecting core infrastructure once trusted to be quiet and predictable.
Rsync’s AI regression: a governance wake-up call
The rsync incident shows how vibe coding problems can slip past existing safeguards. Version 3.4.3 aimed to fix several security issues, but it also introduced regressions in “valid (but unusual) use cases” that were not covered by the project’s test suite. Without tests for those patterns, automated code review pipelines could not catch the failure before release. When users traced the regression back to a period with many “tridge and claude” commits, discussion spilled from GitHub into Reddit and Hacker News, shifting from a single bug to a broader argument about AI in critical open source software. According to The Register’s reporting on Tridgell’s Medium post “Rsync and Outrage,” rsync is a long‑standing, widely deployed tool, which makes any perceived drop in reliability especially alarming. For many maintainers, this episode is proof that AI code automation needs tighter governance, not blind trust.
Rust’s policy experiment: drawing lines around AI tools
While rsync wrestles with fallout, the Rust project is trying to get ahead of similar AI code quality issues through explicit rules. Rust’s strict compiler and borrow checker make it an attractive target for automated agents, because they gain a fast feedback loop: the model keeps revising code until it compiles. Yet this also opens the floodgates to syntactically correct but low‑quality pull requests that strain maintainers and continuous integration resources. After more than a month of internal debate and around 3,000 Zulip messages, a draft policy for rust-lang/rust contributions proposes a conservative stance: AI tools are welcome for reading, analysing, and learning from code, but not for generating code that lands in the repository. Automated comments, documentation, compiler diagnostics, and AI-only review approvals are all banned. The goal is to separate AI as a learning aid from AI as an unvetted source of production commits.
Stricter governance, sabotage detection, and human authority
To cope with vibe coding problems at scale, open source governance is turning more formal and less trusting. Rust’s draft rules introduce a middle category for limited, disclosed AI use, such as machine translation, trivial edits, and constrained review bots that must run under separate accounts and cannot block merges without a human’s explicit approval. An experimental exception allows selected ai-assisted patches in complex areas, but only when reviewers invite them, tests are strong, and both author and reviewer can fully explain the logic. The policy also warns against turning enforcement into a new burden, arguing that “the optimal amount of fraud is not zero” and treating lies about AI use as a code of conduct violation. Together with rsync’s experience, these moves signal a wider shift toward automated code review backed by active sabotage detection, while making clear that human maintainers still have the final say.
