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

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

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

It's worth understanding why, because the correct diagnosis points to a 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 it), wrote the sharpest line about this in the project's updated AI policy. His framing: agentic programming eliminated the natural, effort-based backpressure that used to limit low-effort contributions, and it's now far too easy 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 project you didn't already know. Clone the repo. Get it to build. Read enough of the code to find where your change fit. Run the tests. Work out why a test broke.

Nobody designed that as a quality system. But it functioned as one. The effort was a toll, and the toll guaranteed a floor: almost anyone who got 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 a few minutes and no understanding at all. The quality floor that existed as a side effect of effort vanished along with the effort.

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

The asymmetry that breaks the system

Generating code got dramatically cheaper. Reviewing code got no cheaper at all.

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

Daniel Stenberg's own summary, in his post "death by a thousand slops", was blunt: not only does the volume go up, the quality goes down, so you 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 ignore them. Dismissing a real vulnerability has a catastrophic cost. So every invented report has to be investigated seriously before it can be dismissed. The cost of generating approaches zero; the cost of responsibly discarding stays high.

An honest footnote: curl reopened the program about a month later, when report quality climbed back up. Notably, what came back wasn't the slop — it was high-volume, high-quality, human-verified reports. Which is the whole point: the problem was never 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 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, and it gets less reliable as models improve. A detector with a 5% false-positive rate, pointed at a project taking a hundred PRs a month, accuses five human contributors of fraud every month. It takes one of those becoming a public thread for the project to lose more than it gained.

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

A model-written PR that's read, understood, tested, and defended by a human is a legitimate contribution. A hand-typed PR from someone who can't explain what they did is junk, without a line of AI involved.

The variable that matters isn't where the code came from. It's whether a human understands what was submitted.

What projects are already doing by hand

The most telling detail is what these projects' policies actually ask for.

matplotlib's contributing guide names the real failure mode directly: it warns against using AI output without ensuring you fully understand it, or without verifying it's the correct approach — and says it will flag and reject low-value contributions on those grounds. Ghostty's next move wasn't a better detector either; it was a Vouch Request, where a first-time contributor has to explain themselves in their own words — explicitly not written by AI — before they can submit a PR at all.

None of this is really "don't use AI." It's a request for proof of understanding — applied by hand, one PR at a time, spending exactly the scarce resource the policy was meant to protect.

And the maintainers say as much. When tldraw closed external PRs, it framed the move as temporary, pending better tooling. Here's the part that stopped me: in GitHub's own public discussion on low-quality contributions, a GitHub product manager floated, as one possible direction, defining a set of rules or prompts and evaluating pull requests against them. The platform itself reached for the same idea. There's written demand for a product that doesn't quite exist yet.

Restore the backpressure, don't police the origin

If the diagnosis is that the effort toll disappeared, the fix isn't to guess who used AI. It's to rebuild the toll — and charge it in the right currency.

The right currency is understanding. And understanding is measurable in a very old way: by asking questions.

The shape is simple. When you open a PR, you get two or three specific questions about that diff — questions you can only answer if you understood the change, not if you skimmed the description. You answer. The merge unblocks.

This has properties a detector never will:

It accuses no one. You don't claim "this was AI-generated." You ask someone to explain their own work — something any good-faith contributor finds reasonable, and something several projects already ask for in prose.

False positives are cheap. If the questions are too easy for an experienced contributor, they lose thirty seconds. A detector's worst case is calling a human a fraud; a quiz's worst case is mild annoyance.

It's tool-agnostic and future-proof. It doesn't matter whether the code came from a model, from Stack Overflow, or from the person's own head. The question stays the same three model generations from now: is there a human who understands this?

It rebuilds the toll exactly where it used to be. It doesn't add new friction — it puts back the friction that was always there, and only ever looked invisible because it came free with the manual work.

The objections worth naming

A quiz can be answered by AI. It can — but that requires pasting the diff and the questions into a model, reading the answer, and submitting it. That's a toll again, and the toll is the point. The goal was never to make it impossible; it was to make it not free.

And there's an accessibility tension that shouldn't be waved away: questions in English penalize non-native contributors, and timed tests penalize neurodivergent people. Any serious version of this has to be configurable by the maintainer, untimed, and able to exempt established contributors. A filter that only passes people who write fluent English isn't measuring understanding — it's measuring something else, and reproducing an exclusion open source already has plenty of. (I care about this one personally: I'm not a native English speaker, and I'd fail a badly built version of my own idea.)

What this means

The public conversation framed 2025 and 2026 as the moment AI invaded open source. That framing leads to bans, detectors, and fights over code provenance — and none of them solve the problem.

The more useful reading: open source ran for decades on a quality filter nobody designed and almost nobody noticed — the effort of understanding before contributing. AI didn't break open source. It removed an accidental filter, and forced us to build on purpose what used to come for free.

I'm erickdevz, a full-stack developer from Brazil. I'm building an open-source tool that does exactly this: comprehension-gate asks a contributor a few questions about their own PR before it can merge. Not a detector — a comprehension check, configurable and untimed. It's early and I'm looking for projects to try it on.