*Published July 24, 2026* --- In 2025 researchers gave the phenomenon a name: AI-DDoS. In ["AI Slop is DDoSing Open Source"](https://arxiv.org/abs/2607.04003), Sadia Afroz and colleagues describe "a denial-of-service effect in which plausible but low-quality AI-generated contributions overwhelm OSS community capacity." That is not just a paper's framing. The security engineer Seth Larson, working on curl and Python, spent the year asking people to stop pointing language models at bug bounties, because the reports looked real and wasted maintainer hours proving they were not. Something broke, and it is worth being precise about what. For decades the cost of producing a pull request or filing an issue was itself the filter. The time to understand a codebase and prepare a decent contribution ensured that contributors had enough investment to produce thoughtful work, and it capped the volume a maintainer had to handle. Effort was expensive, so a high volume of contributions signaled real investment. AI dropped the cost of production close to zero. Now volume signals nothing. ## One question replaces the filter [Hiten Shah](https://x.com/hnshah/status/2066761276945211442) offers the cleanest replacement I have seen: judge a contribution by whether it removes uncertainty for the next person or pushes the cost of resolving it onto whoever has to review, merge, or maintain it. An agent-written pull request that saves one person ten minutes and costs someone else an hour is "debt with a diff attached." The real problem with AI slop is not that a machine wrote it but that it transfers a cost. A sloppy issue takes seconds to file and hands the maintainer its full ambiguity to sort out. And the cost is not flat. A defect gets more expensive the further downstream it is caught, from roughly 1x at design to 100x after release (*Beyond Legacy Code*), so ambiguity a contributor will not absorb compounds as it travels. Maintenance is worse: a carrying cost, in David Bryant Copeland's phrase from *Sustainable Rails*, is one you pay all the time, every time. ## The bar is concrete There is a corollary here for anyone worried the bar is now out of reach. Production is the part that got commoditized. Bill Kennedy draws the line between coding and engineering. Coding translates a specification into syntax, which AI now does. Engineering is the part before that: deciding what to build, what will break, what to test. The retained human value is judgment, and judgment is what a good contribution carries. So the bar is concrete. Bring context the maintainer lacks. Describe the behavior. Name the failure mode. Show an example someone can run. That is real work even when no code is written, because it changes the quality of a decision. ## A lens, not a gate The danger is turning the test into an automatic gate. As a rule for judging one contribution it is sound; as a filter that rejects at volume it backfires, and measurably so. In the same AI-DDoS study, projects that tightened review to protect capacity saw first-time contributors' merge ratio fall 18.18% below expected, the sharpest effect the authors found. They call it a rigidity trap: a project looks stable while its contributor pipeline erodes, and the cheapest defenses narrow pathways built over decades. So the test stays a judgment you apply one contribution at a time. A filter tuned to reject transferred uncertainty also rejects the newcomer who would have learned to absorb it, and today's clumsy first pull request is often next year's maintainer. Hard gating carries a cost that lands later, in fewer of them. The way through is a defense that filters on effort, not identity. [Simon Tatham](https://www.chiark.greenend.org.uk/~sgtatham/bugs.html) wrote the canonical version in 1999: a bug report exists to let the programmer see the failure, so the reporter's job is to spell out how to reproduce it. An issue template, a required reproducible example, a reproduction path each make the contributor absorb the ambiguity in a standardized, learnable form. Anyone willing to do the work can meet a template, a first-timer included, where a wall only filters on who you already are. Structured intake stops the transfer without closing the door, and teaches the format on the way in. Much of this automates, which invites the objection that bots already solve it. A bot that bounces a bare report back for reproduction steps is structured intake at machine speed, and the right kind of filter, because it sorts on effort. But no bot supplies the judgment the contribution was meant to carry; automation can route the ambiguity back to its author without doing that author's thinking. ## Where the test does not fire One boundary keeps it honest. The test is about cost pushed onto someone who did not opt in. It is not an argument for polishing everything before you ship. The ["Worse Is Better"](https://www.dreamsongs.com/RiseOfWorseIsBetter.html) tradition, from Richard Gabriel to Jamie Zawinski's Netscape years, is right that a working, imperfect thing in users' hands often beats a perfect thing still in development. You are not there to write code, Zawinski said, you are there to ship products. That holds precisely because the person shipping carries their own downstream cost and the users chose to try it. Ship rough when you are the one who pays for it. The test only fires when the bill goes to someone who did not. Strip it to what a contributor and a maintainer can each hold onto: - If you are contributing, do the work of resolving the ambiguity before you hand it off. Context, the failure you saw, an example someone can run. - If you are receiving, ask for reproduction, not credentials. Effort is something a newcomer can supply; standing is not. - And keep the question a lens. The moment it becomes an automatic gate, it starts rejecting the people you most want to keep. I did not arrive at this as a spectator. It is the test I hold my own contributions to before they reach anyone else: remove the uncertainty, or do not send it. Anyone can produce a contribution now. The ones worth keeping carry the judgment someone already spent, instead of leaving you the bill. --- ## Sources - Sadia Afroz, Courtney Miller, Tyler Menezes, Edward Gilmour, Anita Sarma & Zixuan Feng, "AI Slop is DDoSing Open Source," arXiv 2607.04003 (2026) — https://arxiv.org/abs/2607.04003 - Hiten Shah, "I Don't Read Code. That's Why I'm Learning GitHub." — https://x.com/hnshah/status/2066761276945211442 - Simon Tatham, "How to Report Bugs Effectively" (1999) — https://www.chiark.greenend.org.uk/~sgtatham/bugs.html - Richard P. Gabriel, "The Rise of Worse is Better" — https://www.dreamsongs.com/RiseOfWorseIsBetter.html - Jamie Zawinski, in *Coders at Work* (Peter Seibel, 2009) - Bill Kennedy (Ardan Labs), on the coding-versus-engineering distinction - David Bryant Copeland, *Sustainable Rails* (carrying costs) - David Bernstein, *Beyond Legacy Code* (defect-cost escalation)