Lorenzo Stoakes, who has long served as a reviewer for Linux kernel memory management, has posted patches to the mailing list removing his reviewer entries in five areas. His stated reason is that the influx of AI-generated patches has left him short of time for reviews. What he gave up is the reviewer role, not his duties as a maintainer. The move suggests the impact on kernel development as AI code generation spreads and the burden on human reviewers grows.
Stoakes steps down as reviewer in five areas amid a surge of AI-generated patches
On November 10 (UTC), Stoakes posted four patches to the Linux Kernel Mailing List (LKML). Three of them remove his reviewer entries from the MAINTAINERS file, which lists the maintainers and reviewers for each area. The removals total five lines: one line in the first patch and two lines each in the second and third. The affected areas are core memory management, other memory management, memory reclaim, memory management for Rust, and the Rust allocator. The fourth patch adds six lines to the CREDITS file recording his past work as a co-maintainer of THP (Transparent Huge Pages). Zi Yan has taken over THP, so Stoakes explained there is no need for him to return to that role.
In the MAINTAINERS file, "M:" denotes a maintainer and "R:" a reviewer. Only the five "R:" lines were removed, and his maintainer entries are unchanged. In the patches' cover letter, Stoakes explained that with AI-generated patch series flooding in, he cannot afford to review areas beyond those he maintains. Going forward, he plans to concentrate his working time on the areas for which he bears responsibility as a maintainer.
Tom's Hardware, which reported on the matter on November 11, treats THP as one of the areas he stepped away from. However, the actual patches show that for THP, the change records his past contributions in the CREDITS file rather than removing a reviewer entry, which differs from the other five areas. In replies on the mailing list, Stoakes also described how AI-generated patches have grown. At first he only occasionally saw low-quality AI output, so-called "AI slop," but the frequency rose to once a week or more, then every few days, and he now says such patches make up half or sometimes more of what he sees. This is not the result of a statistical survey, however, but an impression based on his own experience.
Up to half of networking changes may be AI-driven; wireless and staging limit acceptance
The burden from the rise in AI-generated patches is also a problem in other areas of the Linux kernel. Kicinski, who handles networking, reported the number of changes he and co-maintainer Paolo merged in the pull request for Linux 7.3. The breakdown was 632 for "net" and 648 for "net-next," and he said that between a third and a half of the net-next changes were low-priority fixes and code cleanups that appeared to be AI-driven. Phoronix reported the remark on August 20, 2026.
Estimated number of changes merged in net-next for Linux 7.3 that were AI-driven
Total net-next changes
648
Apparently AI-driven changes
About 216–324
About 33–50% estimated to be AI-driven out of 648 total
Source: Calculated from Kicinski's rough estimate. This is not a statistic that individually verified whether AI was used.
One third of 648 is 216, and half is 324. However, Kicinski himself noted that this is a rough estimate, not a figure from a strict classification of apparently AI-driven changes. The proportion also applies to the merged net-next changes, not to all submitted patches or to the 632 changes on the net side.
Meanwhile, in the wireless subsystem, there is a move to be stricter about what gets reviewed. Johannes Berg, who is responsible for it, stated on LKML a policy of ignoring nearly all AI patches generated by syzbot, except those he can judge to be obviously correct after a check of about three seconds. He said he does not intend to attach ordinary review comments to LLM-generated patches and continue discussions asking for fixes. Phoronix reported this policy on August 6, and also said that the staging subsystem has begun refusing AI/LLM-generated patches other than security fixes.
These responses differ from one another. Stoakes reduced the review areas he covers, Berg excluded most AI-generated patches from what he checks, and staging refuses them in principle. All are measures to direct limited human resources toward higher-priority work. However, Stoakes did not restrict the acceptance of patches themselves, and he left open the possibility of reviewing other areas when needed. Kicinski, who handles networking, is also exploring using AI in review work rather than excluding it.
AI is also being used to make review more efficient, but human checks remain essential
Stoakes described the change on the mailing list as a "purely administrative measure." He said that even after removing the reviewer entries, he might end up reviewing many of the same patches as before. He also cited being busy with KVM (Kernel-based Virtual Machine) work as one reason, so the decision cannot be attributed to AI-generated patches alone. In the same reply, however, he called the surge in AI-generated patches a serious problem and said the situation is getting worse. That recognition that the review burden is growing is consistent with the reason for this change.
There are also efforts to bring AI into review work in response to these problems. Kicinski explained that, with support from Meta, he has secured LLM usage quota and reviews each patch with multiple state-of-the-art models. He wants to use LLMs in the associated administrative work as well, such as patch management with Patchwork and editing commit messages. He acknowledged, however, that there are limits to what AI can handle in review. In addition, an LWN article dated July 21 reported that Ted Ts'o hopes the AI review tool "Sashiko" will reduce his workload.
Past cases also show that AI-assisted patch creation is not necessarily seen as a problem. An LWN article dated July 2 compared developers' reactions to two large LLM-assisted patch series. Kiryl Shutsemau's series went through seven revisions, and the use of LLMs itself never became an issue in review. He explained that he personally checked the generated code eight to ten times before posting, and LWN judged it could be an acceptable patch series. By contrast, Stoakes sharply criticized a 40-patch series submitted by Rik van Riel, saying it was "not mergeable as it stands. Not even close."
On the difference between the two, LWN analyzed that what mattered was not the use of AI tools itself but how much effort a human put in before submission. Even if AI is used, a patch may be accepted if the developer has thoroughly verified the code and addressed the problems raised in review. Conversely, if large numbers of patches that have not been adequately checked are posted, the work of verifying them is pushed onto kernel reviewers. The core of the problem is less the use of AI itself than the quality of the generated code and the burden on the humans who check it.
The cases confirmed here, in memory management, wireless, staging and networking, show that responses to the growth in AI-generated patches are not uniform. Some developers narrow what they review, while others use AI to make review more efficient. All are efforts to address the shared problem that human review time is limited. These cases alone, however, cannot establish a trend for Linux kernel development as a whole, and it remains to be seen whether each subsystem's response continues.
If reviewer entries are restored in any of the five areas Stoakes left, or if restrictions on AI-generated patches are eased in wireless or staging, that would mean the current policies have changed. And if Kicinski publishes the share of apparently AI-driven changes in future networking updates, it would provide a point of comparison for the patch inflow. However, estimates made on the same basis may not continue, and it would be difficult to evaluate the effect of AI review from changes in the share alone.
The Linux kernel underpins a wide range of products, from servers to embedded devices, so changes in the review structure may also affect how quickly fixes are accepted and delivered. The key question going forward is which approach, limiting the acceptance of AI-generated patches or using AI to make review more efficient, can reduce developers' burden while maintaining code quality. What matters is not simply increasing the number of patches that can be processed, but whether problematic changes can be reliably caught and the amount of human checking reduced.