The cost of AI-accelerated development doesn't stay on your machine. It travels down the dependency graph until it lands on the maintainer of a project you've probably never thought about — and they're running out of capacity to absorb it.
In January 2026, Daniel Stenberg shut down the curl bug bounty program he had been running since 2019. In six years, it identified 87 confirmed vulnerabilities and paid out over $100,000 to security researchers. He ended it because in the first three weeks of 2026, he received twenty security submissions and not one of them was valid. Every single one was AI-generated. The cost of triaging them — reading, evaluating, responding, closing — had made the program unsustainable.
curl runs on roughly 20 billion installations. It ships with every major operating system and is embedded in mobile apps, cloud infrastructure, and firmware. Stenberg maintains it largely alone. The bug bounty was his mechanism for channeling legitimate security research from the wider community. That mechanism is now gone. Not because the research dried up. Because the noise made the signal unreachable.
The Economics Don't Work for Maintainers
The specific dynamic here is worth understanding precisely, because it's not about bad actors. Most of the people submitting AI-generated bug reports to curl weren't trying to waste anyone's time. They were doing what AI tools make easy: point a model at a codebase and ask it to find vulnerabilities. The model produces a plausible-looking report. Submit.
Generating that report costs thirty seconds. Triaging it — reading the report, checking whether the identified code path actually exists as described, verifying whether the claimed vulnerability is real, writing a response — costs a maintainer twenty minutes. If a thousand developers each submit one report, the maintainer spends over three hundred hours on triage. None of that produces a security fix. All of it displaces the work that would.
This is why the paper published on arXiv in April 2026 by Sebastian Baltes, Marc Cheong, and Christoph Treude uses the phrase "tragedy of the commons." The original commons problem is an incentive structure issue: each farmer benefits fully from adding one more cow to a shared pasture, while the overgrazing cost is distributed across all farmers. Individually rational behavior depletes a shared resource.
AI slop in open source has the same structure. The submitter captures all the benefit of having submitted. The maintainer bears the full cost of review. There is no mechanism to transfer any portion of that cost back. When submission costs fall toward zero, volume grows. Reviewer capacity doesn't.
Well-Formed Noise
On January 15, 2026, Steve Ruiz announced that tldraw would begin automatically closing pull requests from external contributors. He introduced a term for what had changed: "well-formed noise." PRs that claimed to fix a bug that didn't exist, or solve a problem the project didn't have. Correct syntax. Plausible commit messages. Apparent understanding of the codebase. But wrong in ways that required expert judgment to identify as wrong — the same review effort as a legitimate contribution.
What made Ruiz's situation particularly interesting is that he traced part of the problem to his own tooling. He had been using a Claude Code command to turn rough notes into well-formed GitHub issues. The issues were good enough that external contributors — also using AI — were feeding them into their models and generating PRs in response. His machine-generated drafts became the input for other people's machine-generated code. A feedback loop with no humans in it, and the cost landed on him when he had to evaluate the output.
Node.js dealt with a 19,000-line AI-generated pull request. Ghostty closed its doors to outside contributors within months of launching publicly. Jazzband sunsetted entirely — its lead maintainer described the flood of AI-generated spam PRs and issues as making the project unsustainable. Django's Security Team created a formal classification for AI-generated vulnerability reports after their volume required significant expert time to reject. The curl incident looks isolated. It is not.
What Maintainer Burnout Costs You
The abstract framing is "open source sustainability." The concrete framing is: the libraries in your dependency tree are maintained by people, and some of those people are approaching the limit of what they can absorb.
A paper from Q1 2026 auditing 947 codebases found that 93% contained at least one "zombie component" — an open source dependency with no development activity in the past two years. A zombie component means that any vulnerability discovered in it stays unpatched. Security researchers are not reporting to an active project. There is no one triaging.
The connection to AI slop is not that AI directly creates zombie components. It's that AI accelerates the maintainer burnout that leads to them. Jazzband's packages are now in that category. So is any project whose maintainer decided the cost of participation had exceeded the benefit.
curl is not a zombie component. Stenberg is still actively maintaining it. But the bug bounty program — the distributed security research mechanism that found 87 real vulnerabilities since 2019 — is. The future vulnerabilities that would have come through that channel will now be found differently, if they're found before they're exploited.
The Asymmetry Nobody Fixes
The commons framing is useful because it clarifies why individual behavior change is insufficient. Baltes, Cheong, and Treude explicitly note this. If you stop submitting AI-generated reports to curl, that's a marginal improvement for Stenberg. If 999 other developers don't, his situation is unchanged.
The structural fix requires something at the platform or tooling layer: friction at the submission point, signal on AI-generated content, institutional mechanisms that make maintainers' time more defensible. Ostrom's principles for enduring commons institutions include boundaries, collective choice arrangements, and monitoring. None of those currently exist at meaningful scale for open source contribution.
What does exist is the judgment of the individual submitter, which is worth applying even if it doesn't solve the systemic problem.
The relevant question before submitting an AI-generated PR or bug report is not whether the output looks plausible. It's whether you understand it well enough to vouch for it. Whether you've read the code the report cites and confirmed the vulnerability is real. Whether you've run the PR locally and verified it solves the actual problem. Whether you've looked at the issue tracker and confirmed the problem exists.
That's a meaningful filter. It requires you to actually do the work the AI simulated doing. It slows you down. It costs you something.
It costs Daniel Stenberg considerably more if you skip it.
The Hidden Transfer
AI productivity tools work partly by compressing work you used to do yourself. Research, boilerplate, pattern matching, initial implementation. The compression is real and the speed gains are real. What often goes untracked is where the compressed work goes.
Some of it stays compressed — genuinely accelerated and gone. Some of it relocates. Review cycles, correction passes, validation work you still have to do. We've documented that internally, in IDE logs and PR cycle time. It shows up in deletion rates, review duration, the ratio of tokens consumed to lines committed.
The third category is the cost that doesn't relocate to you. It relocates to the person on the other end of the submission. The maintainer. The reviewer. The person keeping the library you depend on running. That cost is completely invisible to your metrics. It doesn't appear in your commit history, your sprint velocity, your AI billing dashboard. It appears in the closing of a bug bounty program and the sunsetted repo you didn't notice until you ran a dependency audit.
curl is on 20 billion machines. The program that found its security vulnerabilities is closed. That has a cost. It just doesn't show up in your productivity dashboard.