AI 程式工程
AI Code Reviews Drive More Than 400 Fixes into Linux 7.2-rc7, Shifting the Maintainer Bottleneck to Human Triage
Late in the Linux 7.2-rc7 release cycle, more than 230 contributors submitted over 400 fixes, some stemming from issues identified by AI review tools. AI has not replaced the core maintenance workflow, but agents such as Sashiko have pushed bug-finding speed beyond humans’ capacity to triage and validate reports.
Linux release candidates are normally expected to shrink as they approach a final release, but 7.2-rc7 still incorporated more than 400 fixes involving over 230 contributors. Linus Torvalds described this elevated volume of fixes as a “new normal” enabled by various AI review tools. The changes were spread across drivers, file systems, networking, and architecture code rather than resulting from a single major regression. AI’s role here is primarily to scan existing code or patches under review and flag potential issues. Fixes must still be written or confirmed by humans, then pass through subsystem maintainers and the normal merge process.
A representative example is Sashiko, which is implemented in Rust and monitors the LKML mailing list. It uses a staged protocol to simulate specialized reviews covering architecture, security, resource management, concurrency, and other areas. Maintainers previously used Gemini 3.1 Pro to backtest 1,000 known issues carrying a `Fixes:` tag and claimed that it identified roughly 53% of the bugs missed during the original reviews. The service has processed tens of thousands of patchsets. However, these results come from the project’s own testing, its estimated false-positive rate remains close to 20%, and multiple tools may repeatedly report the same issue—turning machine time saved into additional triage costs for maintainers.
For engineering teams, the key change is not that “AI has started writing Linux,” but that code-review throughput has become imbalanced. Models can generate large numbers of candidate defects in parallel, while humans must still reproduce them, assess their impact, deduplicate reports, and take responsibility for the fixes. The next things to watch are whether reports include executable reproducers, whether they can be deduplicated against public issues and already-merged fixes, and whether individual subsystems adopt different false-positive thresholds. The number of commits in rc7 alone cannot prove that every fix was discovered by AI, nor can a higher patch count be directly equated with a more secure kernel.