Yesterday Asahi Linux relicensed every repository from MIT to GPL to fight AI code theft. Today the other shoe dropped, and it landed on a person. Lorenzo Stoakes, an Arm engineer who has worked on the Linux kernel's memory management code for over a decade, announced he is stepping down as a reviewer for the MM, core, misc, and Rust areas. His reason was not a new job, a falling out, or burnout in the usual sense. It was volume. AI-generated patch series have flooded the kernel mailing list past the point where one human can keep up.
A maintainer with rare credentials
Stoakes is not a drive-by contributor. He has worked on kernel memory management since 2014, is employed by Arm, and wrote the book on the subject, literally: The Linux Memory Manager. He reviewed patches across four areas, which made him one of the load-bearing walls of the subsystem that decides how the kernel hands out memory, the code everything else stands on. He is keeping the maintainer roles he already holds. What he is dropping is the extra review work, the unpaid reading of other people's patches that keeps bad code out.
The flood has a paper trail
This did not come out of nowhere. In April the kernel published its official AI policy: AI-assisted code is allowed but must carry an "Assisted-by" tag, and AI tools can never add a Signed-off-by. Humans review, humans certify, humans take the blame. By August, maintainers were telling reporters they were overwhelmed by the surge of AI-generated patches anyway. The 7.4 merge window set a commit record, and the talk on the lists was that the AI share of the flood was a big part of it. The policy governed what patches may say about themselves. It did nothing about how many arrive. Source: https://www.zdnet.com/article/linus-torvalds-and-maintainers-finalize-ai-policy-for-linux-kernel-developers/
Why this matters more than the Asahi story
The Asahi relicensing was a project defending itself with licensing. Stoakes stepping back is a maintainer defending himself with the only lever he has left, his own time. Licensing can be contested in court. Time cannot be recovered in any venue. Every area he stops reviewing now has to find someone else willing to read patches against a rising tide, or the patches start landing with less scrutiny than they got last year. LWN's development statistics for 7.3 had Stoakes at 89 patches, 0.5 percent of the whole tree. Small numbers in a tree with tens of thousands of commits. That is the point. Review bandwidth was already scarce, and the flood did not need to be all AI-authored. It only needed to be big enough that a human reader could no longer tell at a glance which patches deserve a careful read and which deserve a skim. Plausible-looking code is the whole problem. Source: https://lwn.net/Articles/1100241/
The squeeze is coming from three directions at once
AI tools are being used to steal in-development code, which is what pushed Asahi to GPL. They are being used to generate the patch flood that drowned Stoakes's inbox. And they are eroding the trust that makes review possible, because once you cannot assume a patch came from a human who understands it, every patch costs more to check. The kernel is the most heavily reviewed codebase on earth. If it is feeling this, every smaller project is about to feel it worse.
What happens next
Watch for more shoe-falls. Either more maintainers prune their review roles and the flood meets less resistance, or the project tightens the rules in ways the April policy avoided: rate limits, per-contributor caps, or stronger disclosure. There is also the awkward middle path, where maintainers quietly deprioritise AI-flavoured series, which punishes honest contributors who use the tools openly while doing nothing about the ones who stay silent. Git is already considering a vote on its own LLM policy. The kernel will not be the last project to learn that writing a policy was the easy part. Source: https://www.phoronix.com/news/Lorenzo-Stoakes-AI-Flood