Artificial intelligence is already reviewing every patch submitted to the Linux kernel’s networking subsystem, but the experiment is producing a less comfortable conclusion than expected: automating code review does not necessarily eliminate human work. Jakub Kicinski, one of the Linux Networking maintainers, says maintainers have spent around 50% of their time trying to disprove findings generated by AI, while the project receives roughly 150 patches every working day.
The key points about AI reviewing Linux in 20 seconds
- Linux Networking has used AI to review every submitted patch since the Linux 7.0 development cycle.
- Sashiko runs models such as Gemini, while another instance has used Claude and additional frontier models.
- Maintainers have spent around 50% of their time checking or disproving AI-generated reviews.
- Human review coverage improved again in Linux 7.3, although the team says it remains “completely overwhelmed.”
- Google and Meta are funding parts of the infrastructure and model usage.
The Linux experiment is particularly interesting because the project provides something rarely available elsewhere: public data showing what happens when AI stops being an occasional coding assistant and becomes a permanent part of the software development process.
And the figures reveal a paradox. AI can find useful bugs, but it also produces false positives that someone has to investigate. At the same time, generative tools allow more developers to produce code faster. The result may be that the capacity to write software is increasing much faster than the available human capacity to review it.
From reviewing some patches to having AI read them all
Linux Networking began running an artificial intelligence reviewer on every contribution during the Linux 7.0 development cycle.
It later adopted Sashiko, a tool initially developed by Roman Gushchin and other Google engineers and transferred to the Linux Foundation under the Apache 2.0 license. According to the figures compiled in the supplied material, its public instance had already produced more than 141,000 reviews across 90 mailing lists.
The idea makes considerable sense.
The Linux kernel receives an enormous amount of code, while there is a limited number of experienced developers capable of reviewing it. A model can perform an almost immediate first pass, identify potential errors, check patterns and flag possible problems before a maintainer gets involved.
But the machine does not have the final say.
That is where a cost that can initially go unnoticed appears: whenever an AI flags a possible bug, a developer has to determine whether that problem actually exists.
During one development cycle, Kicinski estimated that around 13 out of every 100 observations produced by the system were incorrect or not useful enough to pass on to developers. An even more revealing figure emerged later: maintainers were spending approximately half their time trying to disprove AI-generated reviews.
In other words, AI can reduce the cost of finding a potential problem, but it does not reduce the cost of proving that the problem is real by the same amount.
Linux 7.3 improves the numbers, but the team remains overwhelmed
The evolution of human review reveals another interesting trend.
According to Kicinski’s published statistics, as reproduced in the supplied material, the percentage of accepted code that had previously been read by a person fell from 71.77% in Linux 6.18 to 64.64% in Linux 6.19.
With Linux 7.0, the first cycle in which every submission received automated review, it dropped to 60.30%. In Linux 7.1 it fell to 53.36%, before reaching a recent low of 50.84% in Linux 7.2.
Linux 7.3 reverses that trend, recovering to 64.42%.
A second metric may be even more interesting: the percentage of code reviewed by someone working for a company different from the patch author’s employer.
That figure declined from 53.58% in Linux 6.18 to 49.92% in 6.19. It subsequently fell to 47.85% in 7.0, 42.85% in 7.1 and 39.76% in 7.2. With Linux 7.3, it climbed back to 53.98%.
| Cycle | Code read by a person | Writer and reviewer at different companies |
|---|---|---|
| Linux 6.18 | 71.77% | 53.58% |
| Linux 6.19 | 64.64% | 49.92% |
| Linux 7.0 | 60.30% | 47.85% |
| Linux 7.1 | 53.36% | 42.85% |
| Linux 7.2 | 50.84% | 39.76% |
| Linux 7.3 | 64.42% | 53.98% |
The recovery cannot simply be attributed to models becoming better replacements for reviewers.
The process itself has changed. With more than 300 patches awaiting review at certain times, maintainers began prioritizing contributions that had already received human review. Those patches therefore became more likely to make it into the kernel tree.
The number of contributors also increased by 4.5%, according to the figures cited. However, many newcomers submit code produced with the assistance of models while doing little or no reviewing of other developers’ contributions.
This points to a problem that could extend far beyond Linux.
AI is democratizing code production, but it is not democratizing the expertise required to take responsibility for reviewing that code at the same rate.
Using two models to control AI hallucinations
Linux Networking is also testing a solution characteristic of the current AI race: using more AI to check AI.
Kicinski explained in August that the project had secured enough budget to run multiple frontier models on each patch, an approach intended to eliminate some hallucinations.
The supplied article reports that Google funds the public Sashiko instance, while Meta funds another instance used specifically by Linux Networking. Different instances can run different models against the same code and compare their findings.
There is an obvious advantage. Two models can make different mistakes, helping maintainers identify questionable findings.
But it also raises an uncomfortable question for an open-source project such as Linux.
If reviewing every contribution starts requiring substantial quantities of tokens from commercial AI models, who pays for that infrastructure permanently?
Roman Gushchin brought the long-term sustainability of Sashiko to the Maintainers Summit agenda. Among the concerns is the project’s potential dependence on infrastructure and AI budgets provided by external companies.
This does not mean those companies are interfering with kernel development. The issue is structural: an open-source tool could become economically dependent on commercial AI services whose costs it does not control.
Human attention is becoming the bottleneck
The Linux case challenges one of the most frequently repeated assumptions about AI-assisted programming.
If a developer can produce ten times more code, an organization does not automatically obtain ten times more useful software.
That code still has to be understood, tested, integrated, maintained and, in particularly sensitive projects, reviewed by someone willing to take responsibility for it.
Linux Networking provides an extreme example. Four people are listed among its principal maintainers: David S. Miller, Eric Dumazet, Jakub Kicinski and Paolo Abeni. According to the cited count, just two of them handled a large share of the 1,280 patches in the cycle examined.
Meanwhile, AI can participate at both ends of the process.
It can help write a patch, and another model can subsequently review it. Kicinski estimated that between one-third and one-half of certain changes merged during the Linux 7.3 cycle may have been written with model assistance, although he explicitly described this as an estimate that he could not prove.
AI is also being used for less critical tasks. Andrew Morton used Gemini to draft summaries of memory-management changes, which he then reviewed himself.
Even Linus Torvalds has experimented with models to write commit messages, according to the episodes compiled in the source material.
This probably illustrates a more realistic role for AI in software development: rather than suddenly replacing programmers, it is gradually appearing in almost every stage surrounding the code itself.
The risk begins when there is no longer a human who sufficiently understands what is happening between those stages.
Linux has an especially important safeguard against that scenario: its review culture, public mailing lists and tags such as Reviewed-by, through which a person records that they have examined a change.
If, in the future, one machine writes the code, another reviews it and a third eventually applies it automatically, that line will stop being a formality.
It will become the answer to a much more important question: which person actually read the code before it ended up running on millions of systems?
Frequently asked questions
Does Linux use artificial intelligence to review code?
Yes. The Linux Networking subsystem has run AI-based reviews on every patch it receives since the Linux 7.0 cycle, although automated review does not formally replace the responsibility of human maintainers.
Is AI reducing the workload of Linux maintainers?
Not necessarily. Kicinski reported that maintainers were spending around 50% of their time trying to disprove findings from automated reviews, although the models also identify genuine problems.
How much Linux Networking code is still reviewed by humans?
In Linux 7.3, 64.42% of the merged code had been read by a person, up from 50.84% in Linux 7.2. The percentage reviewed by someone working at a different company from the author increased from 39.76% to 53.98%.
Who pays for the AI models used to review Linux?
According to the information compiled in the supplied material, Google funds the public Sashiko instance, while Meta provides funding for another instance used by Linux Networking. This dependence has also opened a discussion about the long-term sustainability of using commercial AI models for open-source code review.