AI didn't break open source. It removed a filter nobody designed

XaviDev1 pts0 comments

AI didn't break open source. It removed a filter nobody designed. — Erick Xavier

2026-08-06 · ai, open-source, software-engineering, productivity

AI didn't break open source. It removed a filter nobody designed.

Ler em português →

By erickdevz · full-stack developer, Viçosa, Brazil

In January 2026, the curl project shut down a bug bounty it had run<br>since 2019. Not because the money ran out — it had paid out more than<br>US$100,000 across dozens of confirmed vulnerabilities. It shut down<br>because the economics of triage had collapsed. Around the same window,<br>the Jazzband collective, which maintained 84 Python projects, announced<br>it was winding down. tldraw's founder flipped the repository to<br>auto-close every external pull request. Ghostty adopted a zero-tolerance<br>policy for low-effort AI submissions.

None of these projects hit trouble from a lack of people wanting to<br>contribute. They buckled under the opposite.

It's worth understanding why, because the correct diagnosis points to a<br>very different fix than the one most of the industry is building.

The filter nobody knew was there

Mitchell Hashimoto, who created Ghostty (and co-founded HashiCorp before<br>it), wrote the sharpest line about this in the project's updated AI<br>policy. His framing:<br>agentic programming eliminated the natural, effort-based backpressure<br>that used to limit low-effort contributions, and it's now far too easy<br>to produce large volumes of bad content with minimal effort.

Sit with the word backpressure, because it's the whole argument.

Think about what it took, up to 2023, to open a pull request against a<br>project you didn't already know. Clone the repo. Get it to build. Read<br>enough of the code to find where your change fit. Run the tests. Work out<br>why a test broke.

Nobody designed that as a quality system. But it functioned as one. The<br>effort was a toll, and the toll guaranteed a floor: almost anyone who got<br>as far as a PR had understood something along the way.

The toll is gone. Producing a patch that compiles and passes CI now costs<br>a few minutes and no understanding at all. The quality floor that existed<br>as a side effect of effort vanished along with the effort.

Hashimoto is emphatic that this is not an anti-AI position — Ghostty is<br>written with heavy AI assistance and its maintainers use AI daily. The<br>line isn't about the tool. It's about contributors who outsource the<br>thinking to a model and then hand the verification bill to the<br>maintainer.

The asymmetry that breaks the system

Generating code got dramatically cheaper. Reviewing code got no cheaper<br>at all.

That asymmetry is fatal to any system with an open front door. The<br>curl numbers<br>make it concrete: the share of vulnerability reports that turned out to<br>be real had run above 15% for years, then fell below 5% in 2025 as<br>AI-generated reports flooded in. In the first three weeks of 2026, curl<br>received twenty submissions — seven of them inside a single sixteen-hour<br>window — and, after the security team read each one, tried to reproduce<br>it, and traced the code paths, not one described a real vulnerability.

Daniel Stenberg's own summary, in his post<br>"death by a thousand slops",<br>was blunt: not only does the volume go up, the quality goes down, so you<br>spend more time than ever to get less out of it than ever.

Security reports are the cruelest version of this, because you can't just<br>ignore them. Dismissing a real vulnerability has a catastrophic cost. So<br>every invented report has to be investigated seriously before it can be<br>dismissed. The cost of generating approaches zero; the cost of<br>responsibly discarding stays high.

An honest footnote: curl<br>reopened the program<br>about a month later, when report quality climbed back up. Notably, what<br>came back wasn't the slop — it was high-volume, high-quality,<br>human-verified reports. Which is the whole point: the problem was never<br>AI. It was unreviewed output with the effort stripped out.

Why detecting AI is the wrong answer

The market's instinct was to build detectors: tools that score a PR by<br>how likely it is to have come from a model.

This fails for two independent reasons, and both are fatal.

The first is technical. Detecting AI-generated content isn't reliable,<br>and it gets less reliable as models improve. A detector with a 5%<br>false-positive rate, pointed at a project taking a hundred PRs a month,<br>accuses five human contributors of fraud every month. It takes one of<br>those becoming a public thread for the project to lose more than it<br>gained.

The second is conceptual, and it matters more. AI-generated code isn't<br>the problem. The maintainers loudest about slop use AI assistants every<br>day and say so. The clearest example in the whole saga: a security<br>researcher sent Stenberg a large batch of AI-assisted findings that led<br>to fixing around fifty real bugs. Same tool, opposite outcome — because a<br>human understood and verified the output before submitting it.

A model-written PR that's read, understood, tested, and defended by a<br>human is a...

effort open because nobody project code

Related Articles