Lorenzo Stoakes will reduce his review work on the Linux kernel because the volume of patch series generated with artificial intelligence has exceeded the time he can devote to them. The Arm principal software engineer is not leaving the project: he will retain his maintenance duties and limit general reviews to the areas under his direct responsibility.
The decision was formalized in a series of four patches sent to the kernel mailing list on November 10. In it, Stoakes proposes stepping down from review roles in several memory management areas, while redistributing those duties among other maintainers. As he explained, the current volume of AI-generated series leaves him unable to offer general reviews outside the areas he maintains.
“Given the current throughput in the kernel resulting from AI-generated series, I unfortunately lack the bandwidth to generally be able to offer review except in those areas I maintain.”
— Lorenzo Stoakes, Arm principal software engineer
A partial step back, not a departure from the project
The change affects review roles, not the maintenance responsibilities Stoakes is retaining. In comments to The Register, he clarified that he does not intend to give up those responsibilities: he wants to reduce the load in his inbox and stop reviewing generally outside the subsystems he maintains.
The distinction matters because reviewing and maintaining are not interchangeable tasks. Stoakes lists four memory management-related areas he maintains on his résumé: memory mapping, its locking, the madvise interface, and reverse mapping between physical and virtual memory. According to his own message, the adjustment lets him focus his work on those areas instead of taking on broad availability to review other contributions.
The series sent to the mailing list organizes the reviews he is stepping back from by area and assigns them to David Hildenbrand, Andrew Morton, and Alice Ryhl along with Danilo Krummrich. It also adds an entry to CREDITS for his work maintaining THP, transparent huge pages. Stoakes explains that, following Zi’s appointment as co-maintainer, he no longer expects to need to get involved there.
More proposals, the same review capacity
The problem Stoakes points to is a difference in scale: producing patches has become easier, but the number of people available to check them has not increased in the same way. A proposal needs to reach someone who understands the area, evaluates the changes, and decides whether they fit. AI can speed up code generation; it does not eliminate that evaluation work.
Stoakes described a clear progression to The Register: AI-assisted contributions went from appearing once a week to arriving daily, and now account, by his estimate, for half of what he sees during reviews. He added that the impact extends across memory management as a whole. He also said he often ends up working nights and weekends, a routine he links to the risk of burnout.
For project maintainers, the immediate consequence is not just a longer queue. If a reviewer reduces their availability, the work has to be distributed among others or wait; in this case, Stoakes separated the patches by area so other maintainers can take them on. The decision avoids presenting review as an unlimited obligation for one person, but it also reveals that the bottleneck is expert attention, not the amount of code that can be generated.
Greg Kroah-Hartman, quoted by The Register after a question-and-answer session at the previous month’s Open Source Summit, expressed a similar concern: he said there are not enough people to review all the patches generated by LLMs and that maintainers have been exhausted for years. His comment places Stoakes’s case within a broader tension in kernel maintenance: the increase in proposals is reaching a community that, according to Kroah-Hartman, already lacks enough reviewers.
The contrast with AI-assisted fixes
The review workload coincides with another, more positive sign. Linuxiac reports that Linus Torvalds highlighted the growing use of AI-assisted fixes in Linux 7.4-rc2. In his November 8 announcement, he wrote that much of the recent maintenance work had used them and that he might stop mentioning it because it could become commonplace.
Torvalds also cited BPF maintainer Alexei Starovoitov, who observed that in that subsystem the pace of fixes already exceeds that of new bug reports. Torvalds cautioned that this is not true in most other areas: he presented it as a possible sign of progress in BPF, not as a general improvement in the kernel. Linuxiac also notes that he did not identify which tools produced the fixes or which specific patches were AI-generated.
Thus, two effects coexist: tools can help find and fix bugs, but they also increase the flow of material that someone has to review. More fixes do not mean less review work if every proposal still needs human evaluation and the number of reviewers does not grow at the same pace. The difference between the two cases also matters: Torvalds’s comment concerns fixes entering development; Stoakes is talking about the workload posed by all the series he receives for review.
What changes for those who maintain software
The episode makes an organizational limitation clear for companies that depend on Linux: a project can receive more contributions without gaining the capacity to integrate them. In Stoakes’s case, the response is to limit his availability and distribute responsibilities, not to abandon the subsystems he maintains.
For those submitting changes, this context raises the cost of a proposal that arrives without adequate preparation: it consumes review time even if it is not ultimately integrated. Hardware Upgrade describes the same problem in other open-source projects and mentions concerns among Godot developers about AI-generated contributions. The example does not make the Linux case a general prohibition; it shows that each community has to decide how to manage a volume its reviewers may not be able to absorb.
Stoakes’s decision also defines what can be expected of someone with several responsibilities: maintaining one area does not mean reviewing the entire kernel. By formalizing his departure from certain roles and reassigning the series, he makes explicit what work he can continue to offer. The practical question for projects and the companies that use them is how to sustain reviews when generating proposals costs less and less, but the judgment of people who know the code remains a limited resource.
Stoakes has not given up his maintenance duties and wants his inbox to be more manageable. The four changes sent to the mailing list translate that decision into concrete changes in responsibilities.
Sources: theregister, Hardware Upgrade, Linuxiac, Linux kernel mailing list (Lorenzo Stoakes’s original post), Tom's Hardware
