Linux kernel AI slop drives a top reviewer to step back

Here’s a number that should worry anyone who runs Linux, which is to say everyone, whether they know it or not. Lorenzo Stoakes, one of the lead reviewers for the kernel’s memory management subsystem, says that roughly half of the patches landing in his inbox are now AI slop. Not “some”. Not “a growing share”. Half. Linux kernel AI slop has gone from a curiosity to a workload, and this week he decided he’d had enough of it.

Stoakes announced on the kernel mailing list that he’s stepping back from reviewing the core, reclaim, Rust, transparent huge pages and miscellaneous parts of the memory management tree. He keeps KVM and a few other duties, he’ll finish the series he’s working on, and he says he’ll still drop by now and then. No drama, no rage quit. Just a guy whose inbox finally won.

Linux kernel AI slop, by the numbers

The quote that stuck with me, as Tom’s Hardware reported, describes a curve every maintainer will recognise: “At first it was once in a while that I’d see slop. Then it was at least once a week. Then every few days. Nowadays it’s pretty much half of what I see, if not more.”

And he saw it coming. Back in July he was already warning that “the amount of time wasted on AI slop is already too much and we’re only at the start of this.” A month ago he put it even more bluntly: “what kills the project is having 1,000 slop submissions that 2 or 3 people have to do something with.”

That last sentence is the whole story. The Linux kernel doesn’t have a code-quality problem, its review process is brutal enough to shred bad patches, human or not. It has a throughput problem. A language model can crank out a plausible-looking memory management patch in thirty seconds. A human has to spend thirty minutes figuring out whether it’s subtly wrong, and in mm, “subtly wrong” means your server falls over at 3am. Multiply that by a thousand and you don’t need a conspiracy to kill a subsystem. You just need to tire out the three people holding it up.

Linus is fine with AI, maintainers pay the bill

Here’s the part I find slightly uncomfortable. Linus Torvalds has been fairly relaxed about AI-assisted contributions, pointing out that bots sometimes avoid the mistakes tired humans make, and the current line on LKML is that AI-assisted commits don’t even need to be flagged as such. On paper, that’s a reasonable “judge the code, not the tool” stance.

In practice it means the cost of the AI wave doesn’t land on the people sending patches. It lands on the reviewers. The sender spends nothing. The reviewer spends their evening. And unlike a big tech company, the kernel can’t just hire twelve more reviewers next quarter; memory management expertise takes years to build and about one bad month to lose. We’ve already seen what happens when a single under-resourced maintainer sits between a critical bug and a fix, like with that Ubuntu kernel patch nobody shipped.

Curl went through this with AI-generated security reports, and plenty of smaller projects have quietly closed their issue trackers to drive-by contributions. The kernel is just the biggest domino, and the first one where a named, respected reviewer has said out loud: this is why I’m leaving part of my job.

What would I do? If you’re tempted to point an agent at the kernel tree and “contribute”, please don’t unless you can personally explain every line of the diff to an angry Englishman on a mailing list. And if you’re a company making money from AI coding tools (there are a few), funding a couple of kernel reviewer positions would be a cheap way to stop setting fire to the commons you depend on.

The robots aren’t replacing Linux maintainers. They’re just burning them out, which turns out to be faster.