A Quarter of Open Source PRs Are AI Slop, Say Maintainers

There is a sentence I have been turning over all week, and it comes from a survey, not a flame war. The Linux Foundation asked open source maintainers about life in the generative AI era, and the answers landed on October 20: respondents estimated that a quarter of incoming pull requests are low-quality "AI slop," rising to 31 percent on large projects. In the same survey, those same people estimated that AI cut their code-authoring time by 52 percent on average.

Read those two numbers together and you get the whole story of open source in 2026. Writing code got cheap. Reading it did not. And the bill for the difference is being paid by the smallest, most exhausted group in the entire ecosystem: the people who review.

The review is the product

Here is the thing nobody tells you when you submit your first pull request: the code is not the hard part. The hard part is the human being on the other side who has to decide, with their name effectively attached, whether your change is safe to ship to millions of machines. That person reads your diff, reconstructs your reasoning, checks the edge cases you did not think of, and then either merges it or tells you why not. Every one of those steps costs attention, and attention is the one resource in open source that does not scale.

AI tooling scaled the easy side of that equation. Anyone can now generate a plausible-looking patch in an afternoon, including people who have never read the codebase they are patching. What did not scale is the reviewer. There is no AI that can take responsibility for a merge. There is only a maintainer, at midnight, on their own time, squinting at a diff that looks confident and means nothing.

I have been on both sides of this, and I will be blunt about which side I respect more. Submitting a patch takes an evening. Maintaining the judgment to accept or reject a thousand patches takes years. When we talk about open source "productivity," we almost always measure the first thing and ignore the second. The survey finally measured the second thing, and it turns out the second thing is on fire.

Slop is not a quality problem. It is a trust problem.

The word "slop" is doing a lot of work here, and I want to be fair about what it means. The survey figure is a maintainer estimate, not a census of every pull request on Earth; the report's own chart labels the category "low-quality and/or AI-generated." Some of those submissions are fine code written with AI help. Some are confident nonsense. The honest version of the headline is softer than the viral one, and I would rather be honest than viral.

But the softer version is still damning. Fifty-three percent of respondents disagreed that AI has improved community trust. The tools lowered the barrier to contributing, which 71 percent acknowledged, and yet most maintainers feel less sure about the community on the other side of the barrier. Lower barriers plus lower trust is not a success story. It is a queue full of strangers handing you boxes you have to open carefully, one by one, forever.

The curl project just showed us what the endgame looks like. This week curl announced it will move low- and medium-severity flaw reports to public view, because its security team was nearly overwhelmed by AI-assisted reports. A project used by practically everything had to change how it handles security reports, not because attackers got smarter, but because the inbox got louder. When triage itself becomes the vulnerability, you do not have a tooling problem. You have an economics problem.

Bans and labels will not save us

I wrote last week about the Linux kernel dropping its mandatory "Assisted-by" disclosure tag, and my position has not changed: policing which tool a contributor used is a losing game. A label does not tell a reviewer whether the code is correct, and a ban does not stop anyone determined to submit anyway. The kernel kept the only rule that ever mattered, which is that a human being stands behind the change. Everything else is decoration.

The same logic applies here. You cannot label your way out of a review bottleneck, and you cannot ban your way out either. What actually works is boring, unglamorous, and completely within every project's control: make the contributor do more of the reviewer's work before the patch ever arrives.

And here is the part nobody wants to say out loud: maintainers are allowed to say no faster. "No, this patch is too large to review, split it" is a kindness to everyone, including the contributor, who just learned the actual skill this whole ecosystem runs on. The scarcest resource in open source is not code. It is a maintainer's willingness to keep opening the inbox tomorrow.

What I would do if I ran a project

If I were setting contribution rules tomorrow, I would write exactly four lines, and I would mean all of them.

First: your patch must be small enough that a tired human can review it in one sitting. Second: it must come with tests, or a convincing reason why it cannot. Third: the description must explain the reasoning, not just the result. Fourth: if a maintainer closes it without a full review because it fails the first three, that is a complete answer, not the start of a negotiation.

None of that mentions AI. That is the point. The projects that survive this era will not be the ones with the cleverest AI policy. They will be the ones that protected their reviewers' time like it was production infrastructure, because it is.

So here is my opinion, stated plainly: stop celebrating how much code AI lets us write, and start celebrating how little of it maintainers have to throw away. The health of open source was never measured in pull requests opened. It is measured in maintainers who are still here next year, the same long game I wrote about when the AI era hit long-term support kernels.

Sources: Linux Foundation, "New LF Research Survey Shows Generative AI Cuts Open Source Coding Time in Half, but 25% of Incoming Pull Requests are Considered AI Slop" (October 20, 2026); The Register, "AI cuts coding time, but it's also filling open source's inbox with crap" (October 21, 2026). Survey figures cited are maintainer estimates from 111 respondents, not an audit of all pull requests. Related reading on this blog: the kernel's decision to drop its mandatory AI-assistance tag, what the AI era means for long-term support kernels, and running your own AI stack locally instead of renting someone else's.