Linux Kernel Networking Maintainers Overwhelmed by AI-Generated Patches
Maintainers say a third to half of the net-next patches for the Linux 7.3 development cycle appear to be low-priority AI-generated fixes.
The engineers who maintain the Linux kernel networking subsystem say they are struggling to manage an influx of AI-generated code submissions. According to reports on the Linux 7.3 development cycle, the sheer volume of these patches is beginning to obstruct ordinary maintenance work. Linux networking subsystem maintainers admit they are ‘completely overwhelmed’ by AI-generated patches, with the problem described as a recent and accelerating phenomenon within the development tree.
Networking maintainer Jakub Kicinski provided an estimate of the scale, noting that roughly one-third to one-half of the 648 net-next patches queued for Linux 7.3 appear to be AI-driven low priority fixes. This suggests hundreds of patches that may offer marginal improvements in code style, minor bug fixes in rarely used drivers, or trivial documentation updates, rather than substantive changes needed to move the network stack forward.
The core of the issue is not that the patches are incorrect or malicious, but that they consume the same finite review bandwidth required for critical security fixes, new hardware driver support, and performance enhancements. Every minute a senior maintainer spends verifying a syntactically correct but functionally trivial AI patch is a minute not spent on work that genuinely advances the subsystem. The review process for kernel code is famously rigorous, and automating the generation of plausible-looking submissions does not automate the judgment required to triage them.
This creates a classic scaling problem for open-source projects built on volunteer or loosely coordinated labor. AI tools lower the barrier to generating a patch, but they do not lower the cost of evaluating its actual utility within a complex, production-critical codebase. The result is an asymmetry where the rate of patch generation can now far outpace the human capacity for meaningful review, threatening to turn the maintainer’s inbox into a filter for noise rather than a queue for signal.
For now, the problem appears concentrated in the networking subsystem, but the pattern is one any large, actively developed open-source project could face. The story here is not about a single wave of bad code, but about what happens when an automation designed to assist development instead begins to overwhelm the very human processes that give a project its direction and quality. The maintainers are not complaining about the existence of AI coding tools, but about their unmanaged output flooding a pipeline never designed for it.