Submitted the rsync issue to HN under its blunt original title, amplifying the maintainer's plea. The framing emphasizes that rsync is critical infrastructure for backups and data sync, where LLM-generated code that 'compiles and reads fluently' can silently corrupt terabytes through subtly wrong delta logic.
Argues that rsync's tiny maintainer headcount versus its outsized infrastructure footprint makes AI PR triage an existential time sink. Notes that LLMs excel at producing code that passes obvious tests while quietly mishandling untested edge paths — exactly the failure mode that corrupts backups silently.
Points to curl's Daniel Stenberg publicly documenting a flood of fabricated AI-generated CVE reports, informal Linux kernel norms against unattributed AI patches, and Python steering council discussions. Frames rsync's outburst as a tonal escalation of an industry-wide maintainer revolt that's been building for over a year.
A faction of the HN thread argued that the maintainer's stance amounts to gatekeeping against a tool that's now ubiquitous in developer workflows. They framed AI-assisted contributions as an inevitability that projects will have to adapt to rather than resist.
Commenters identifying as open-source C maintainers countered the gatekeeping framing with concrete claims: review load has measurably worsened in the last twelve months, and separating a thoughtful human patch from a confident hallucination now costs hours per PR. Their lived experience grounded the thread against abstract pro-AI arguments.
On the rsync GitHub repo, issue #929 — bluntly titled *"Please Do Not Vibe Fuck Up This Software"* — hit the HN front page with 284 points. The maintainer's ask is simple: stop opening pull requests written by Claude, GPT, Cursor, or whatever agentic IDE happens to be in vogue this quarter. The thread isn't a manifesto. It's a tired person asking strangers to stop wasting their time.
rsync is not a side project. It is the file-copy primitive that backs a non-trivial percentage of the world's backups, CI artifact moves, and cross-region data syncs — and it has roughly the maintainer headcount of a mid-sized indie game. The codebase is C, the protocol is decades old, and the failure modes include silently corrupting terabytes if delta calculations go subtly wrong. "Subtly wrong" is exactly the failure mode LLMs are best at producing: code that compiles, passes the obvious tests, reads fluently to a reviewer, and quietly mishandles the one path nobody wrote a test for.
The HN comment thread split predictably. One camp argued the maintainer is gatekeeping and that AI-assisted contributions are inevitable. The other camp — heavily weighted toward people who actually maintain open-source C projects — pointed out that the review burden has measurably gotten worse over the last twelve months, and that distinguishing a thoughtful human patch from a confident hallucination now eats hours per PR.
This is not the first project to raise the alarm. The curl maintainers have been public for over a year about the flood of AI-generated security reports that look credible, cite CVEs convincingly, and turn out to describe vulnerabilities that don't exist. Daniel Stenberg wrote an entire blog post titled *"The I in LLM stands for intelligence"* about exactly this dynamic. The Linux kernel has informal norms against unattributed AI patches. The Python steering council has discussed it. What's new with rsync isn't the policy — it's the tone, which has shifted from polite discouragement to open exhaustion.
The economics are worth stating plainly. An LLM can generate a plausible patch in 30 seconds. A senior C maintainer reviewing that patch needs to read the diff, understand the surrounding 200 lines of context, mentally simulate the network protocol state machine, check whether the change handles the four edge cases the test suite doesn't cover, and decide whether the contributor actually understood what they submitted or just shipped whatever the model produced. That's 30 minutes minimum. The asymmetry is roughly 60:1, and it scales linearly with how many people decide to "help."
The deeper problem is that LLM-generated contributions destroy the most valuable signal in open-source review: the assumption that the contributor has skin in the game. When a human submits a patch, the reviewer can reasonably infer they understand the code, care about the outcome, and will respond to feedback. When an agent submits a patch on behalf of a human who is mostly along for the ride, that inference breaks. You're no longer reviewing code with an author — you're reviewing code with a prompt-and-paste intermediary who can't defend the design choices when you ask why.
The rsync maintainer's frustration is the natural endpoint of this dynamic playing out across every infrastructure-critical project simultaneously. The same agentic coding tools that VCs are valuing at tens of billions are externalizing their review costs onto unpaid volunteers maintaining the software those tools depend on. rsync is in the dependency tree of every cloud provider, every CI system, every backup product. Cursor is not paying rsync's maintainers. Anthropic is not paying rsync's maintainers. The user who fired off a 400-line refactor PR after a 20-minute Claude Code session is definitely not paying rsync's maintainers.
If you ship infrastructure code, the first concrete implication is policy. Add a CONTRIBUTING.md clause now, before you need it, stating that AI-generated patches must be disclosed and that undisclosed ones will be closed without review. The curl project's wording is a reasonable template. Don't ban AI-assisted contribution outright — that's both unenforceable and counterproductive for routine cleanup work. Ban *undisclosed* AI generation and require the submitter to demonstrate understanding in the PR description.
The second implication is for your own internal use of agentic coding against external dependencies. If you're using Cursor or Claude Code to file patches against upstream projects, the courteous default is: don't, unless you can defend every line in review without the agent's help. Use the tool to draft, then read what it produced line by line, then either own it fully or close the tab. The maintainer can't tell the difference between you and a script-kiddie running an autonomous agent until they've already spent 20 minutes on review.
Third, this is a leading indicator for vendor risk. The supply chain underneath your stack — rsync, OpenSSH, glibc, OpenSSL, sqlite, every transitive C dependency — is held together by maintainers who can quit at any time and increasingly are. Expect to see more high-profile resignations citing AI slop fatigue over the next twelve months. Budget for it. Sponsor the projects you depend on through GitHub Sponsors or direct contracts. The XZ backdoor was a warning shot about what happens when a critical-infra maintainer hands the keys to a stranger; the next failure mode is the maintainer simply walking away because reviewing slop isn't worth their weekend.
The interesting question is whether the tooling vendors will respond. Anthropic, OpenAI, and Cursor all have direct visibility into how their products are being used against open-source projects, and all of them benefit commercially from the health of the underlying ecosystem. A built-in "do not submit this PR without reading it" friction step would cost them nothing and meaningfully reduce the slop volume. Whether they ship it before more rsync-style blowups force the issue is the bet to watch. In the meantime: if your name is on the PR, the code is yours. Defend it or don't send it.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.