'Half of it is slop': AI patch flood drives a Linux kernel developer out of code review

What's going on

Lorenzo Stoakes has worked on the Linux kernel since 2014. He's an engineer at chip designer Arm and wrote the book The Linux Memory Manager. On Tuesday, November 10, 2026, he posted a series of four patches to the official kernel mailing list, LKML. With them, he removes himself as a reviewer for several core areas, effective immediately. That's according to the French site goodtech.info. His reason: the flood of code submissions generated with artificial intelligence.

Reviewers check other people's code changes before they're merged into the kernel. Stoakes is giving up that job for the following areas:

• core memory management (MM),
• memory reclaim, which decides which memory pages to free when RAM runs low,
• the related components written in the Rust programming language,
• various other sections.

He's keeping his maintainer roles. A maintainer has primary responsibility for an area and makes the final call on which changes get merged. According to goodtech.info, this includes areas around KVM, the kernel's virtualization technology. He's handing over Transparent Huge Pages (THP) to developer Zi Yan. THP is a mechanism that manages memory in especially large blocks to save processing time.

"I no longer have the capacity"

Stoakes addressed his message to some of the project's key figures. They include Andrew Morton, the longtime memory management maintainer, David Hildenbrand, and the people behind Rust for Linux. His reasoning is blunt:

"Given the current volume of AI-generated patch series coming into the kernel, I unfortunately no longer have the capacity to do general review, except in the areas I maintain."

By his estimate, at least half of the patch series he has to review are now "AI slop", the community's term for low-quality content churned out automatically without care. A few months ago, he said, he only ran into it occasionally. Then it was weekly, then daily, until these submissions filled his entire queue. Weeding out other people's submissions takes so much time that his own development work suffers.

The move doesn't come out of nowhere. Back in July, Stoakes warned about the problem and summed it up like this:

"What kills the project is 1,000 sloppy contributions that two or three people have to deal with."

Humans are the bottleneck

The Linux kernel runs on a strict pyramid of trust. Anyone can propose changes, but only a handful of human experts review every line before it's merged. This painstaking manual work keeps the kernel stable, and the kernel runs on servers, Android phones, routers, and countless other devices. A bug in memory management can cause crashes, data loss, or security holes.

AI coding assistants like Claude or ChatGPT put this model under pressure. They let practically anyone produce code in no time that looks clean at first glance. But according to goodtech.info, it often contains subtle hallucinations, meaning made-up assumptions that sound plausible. On top of that come regressions: changes that break something elsewhere that used to work. Meanwhile, the number of people who can review all this hasn't grown. Tech site XDA Developers puts it neatly: AI has made it possible for anyone to write code, but it hasn't increased the capacity of the people who review it.

According to goodtech.info, several experienced memory management developers backed Stoakes, including Mike Rapoport and David Hildenbrand. Some confirmed that the current workload has become unmanageable.

The problem isn't limited to Linux. XDA points to the Open Home Foundation, the organization behind the smart home software Home Assistant. It's also struggling with a wave of AI-assisted submissions.

No disclosure requirement for AI code

goodtech.info sees a gap in how the project is organized. Linus Torvalds, the kernel's creator and final authority, is generally open to AI tools as an aid for developers. But the submission rules don't require explicit disclosure when a patch was generated or co-written by a language model. As a result, reviewers check these contributions "blind": they often don't know whether a human actually understood the code or whether they're looking at a chatbot's output. Paid and volunteer reviewers alike bear these hidden costs. According to goodtech.info, they're driving the very best experts to step back.

What the kernel guidelines for AI agents require

The kernel community has recognized the problem. XDA Developers describes a guide from the kernel maintainers on working with AI coding agents. These are AI programs that can read, modify, and test code on their own. XDA calls the guide one of the best on the subject its editors have read. The report doesn't make clear what official status the guide has. The key points, according to XDA:

• Process first: The agent should read the full development process documentation and other relevant material instead of just searching for keywords. That material belongs in the context window, the span of text the model can keep in view at once, from the start. A repository contains more than code: it also holds architecture, conventions, testing rules, release processes, submission guidelines, and ownership.
• Evidence, not guesses: Just handing a model the bug report isn't enough. A language model can come up with a plausible explanation for something that doesn't exist, or name a cause that has nothing to do with the error logs. So the agent should provide evidence.
• Local test loop: Debugging, fixing, and testing should happen in a local loop before anyone even thinks about submitting. Whoever is driving the agent has to verify personally that the bug is really fixed and nothing else breaks. The goal is to burden fewer people with half-baked code.
• Document provenance: The guidelines also cover provenance, meaning where the code came from. That includes, for example, which files the agent examined, what task it was given, which documentation was in its context, and which tests passed or failed.
• Human accountability: The sign-off, which a developer uses to certify a contribution's origin and legitimacy, must always come from a human. Whoever submits takes full responsibility, even if an agent wrote the code.

Maintainers can also ask for additional tests on AI-assisted contributions, look more closely, or demand explanations of the changes. If someone can't explain what their submitted code does, that's a clear red flag, according to XDA.

Analysis

This departure sends a strong signal because it doesn't involve a newcomer. Stoakes knows one of the kernel's most delicate areas so well that he wrote the standard book on it. When experts like him cut back on review work, memory management as a whole gets looked after more slowly. That also hits worthwhile contributions from people who work carefully, with or without AI.

The problem is structural. AI pushes the cost of producing code close to zero. The cost of reviewing it responsibly stays the same or even rises, because buggy AI code often looks polished, which makes mistakes harder to spot. Guidelines like the ones XDA describes target the submitters: they're supposed to provide evidence, disclose provenance, and take personal responsibility. Whether that helps against a mass of contributions whose authors don't care about such rules remains to be seen. According to goodtech.info, there's still no mandatory labeling for AI patches.

One caveat: the estimate that at least half of patches are slop is Stoakes' personal assessment of his own queue, not a measurement across the whole kernel. The sources don't mention any official response from Linus Torvalds to his step back.