AI tools are helping reviewers find more bugs in the Linux kernel, and that may be one reason recent release candidates contain unusually large numbers of fixes. But this does not mean artificial intelligence is taking control of Linux development. Human maintainers still review the work, test the changes and accept responsibility for every patch.
Key takeaways
- Linus Torvalds linked part of Linux 7.2-rc7’s large fix count to reviews performed with AI tools.
- Linux requires a human developer to inspect, test and sign off every AI-assisted contribution.
- Publicly disclosed AI-assisted commits remain a small part of overall kernel development.
- More fixes in a release candidate do not automatically mean the kernel has become less reliable.
What happened in Linux 7.2-rc7?
The seventh release candidate for Linux 7.2 arrived with more fixes than Linus Torvalds would normally like at this stage of development. In the official Linux 7.2-rc7 release message, he expressed concern about its size and described the steady flow of fixes as a possible new normal, with many resulting from reviews performed by different AI tools.
The important word is review. The release was not one giant AI-generated feature. Its changes were spread across drivers, filesystems, networking and processor architecture code. Several larger groups involved s390 cryptography, Btrfs and netfilter ipset fixes, while much of the remaining work consisted of small corrections.
Linux 7.2 was still expected to reach its stable release soon unless another serious problem appeared. We are following that timing separately in our Linux 7.2 release tracker, while our Linux 7.2-rc7 report covers the release candidate itself.
Why AI review can produce more fixes
Kernel code receives extensive review already, but AI-assisted tools can scan large patches and search for patterns that are easy to overlook. They may flag an incorrect error path, a missing check, unsafe memory use or a mismatch between a function and its documentation. A developer can then reproduce the issue and decide whether a patch is justified.
This changes the economics of bug hunting. A tool can examine more code than one reviewer has time to read line by line. The result may be a longer list of small fixes close to release, even when the underlying software is not suddenly worse.
| What a larger fix count can mean | What it does not prove |
|---|---|
| More potential defects were detected | That AI wrote the entire release |
| Reviewers examined more paths and edge cases | That every suggested fix was correct |
| Maintainers chose to correct issues before stable | That Linux has become less secure |
There is also a trade-off. Finding a possible defect is only the beginning. Maintainers must understand it, reproduce it where possible, inspect the proposed change and make sure the fix does not create a regression. AI can increase the number of leads, but human review remains the bottleneck that protects quality.
Is AI writing the Linux kernel?
No—not in the sense that an autonomous system can submit code and become a kernel developer. AI assistance may be used to review code, explain a suspicious pattern, create a reproducer or help prepare a fix. The person submitting the patch is still responsible for its origin, licensing, technical accuracy and testing.
This distinction matters because “AI found a bug” and “AI wrote Linux” describe very different situations. A tool may identify a questionable line, but an experienced developer must determine whether the warning is real and whether the proposed repair belongs in the kernel.
Linux’s rules for AI-assisted work
The Linux kernel documentation now includes a specific process for coding assistants. It says the human contributor must read the relevant development rules, identify the change being fixed, create a reproducer when practical, build and test the patch, and explain anything that could not be tested.
An AI agent must not add its own Signed-off-by line. That certification belongs to the human contributor, who accepts responsibility under the kernel’s development process. When assistance is material, the contribution can disclose it with an Assisted-by trailer naming the agent, model and tools used.
In simple terms, Linux treats AI as a tool—not an author or maintainer.
What the disclosed data shows
A community tracker called Assisted-By scans public Linux commits for disclosed Assisted-by tags. At the time we reviewed its data on 11 August 2026, it reported the following figures:
| Measure | Reported figure |
|---|---|
| Disclosed AI-assisted commits merged | 169 |
| Lines added by those commits | 3,320 |
| Total Linux commits since 1 January 2026 | 26,079 |
| Disclosed AI-assisted share of commits | 0.65% |
| Disclosed share of newly added lines | 0.29% |
These numbers should be read as a verifiable minimum, not a measurement of every AI tool used privately. The tracker can count only work that includes the public disclosure tag. Even with that limitation, the data shows that openly identified AI-assisted work is still a small portion of total kernel development.
Could AI-assisted review make Linux safer?
It can help, especially when tools find bugs that would otherwise survive until a later release. Earlier detection gives maintainers more time to correct memory errors, validation gaps and unusual edge cases before users encounter them.
However, a high-quality result depends on the full review chain. AI tools can produce false positives, misunderstand hardware behaviour or suggest code that looks convincing without being correct. A weak review process would simply turn more suggestions into more noise. The Linux approach is sensible because it keeps responsibility with identifiable human developers and maintainers.
The most likely long-term change is not that AI replaces kernel programmers. It is that maintainers receive more machine-generated findings and must develop better ways to verify, prioritise and document them.
What this means for normal Linux users
For desktop and server users, there is no immediate action required. Release candidates are test builds, and a busy week of fixes is part of the process that happens before a stable kernel reaches mainstream distributions.
If AI-assisted review helps locate real defects, users may ultimately receive a more thoroughly checked kernel. If a late issue creates unacceptable risk, Torvalds can also add another release candidate rather than rushing the stable version. That decision is based on the quality and seriousness of the remaining problems, not just the raw number of commits.
What to watch next
Three signals will show whether this is truly the “new normal”: how often Linux release messages mention AI-assisted reviews, whether disclosed Assisted-by commits continue to rise, and whether maintainers report that the findings save time without increasing review mistakes.
The bigger story is therefore not a single large release candidate. It is the beginning of a measurable, public experiment in how one of the world’s most important open-source projects can use AI while keeping humans accountable.
Frequently asked questions
Did AI write Linux 7.2?
No. Some tools assisted with reviews and fixes, but human developers and maintainers remained responsible for the submitted and merged code.
Why did Linux 7.2-rc7 contain so many fixes?
The changes covered many kernel areas, and Torvalds said a number of fixes resulted from reviews performed by AI tools. Most changes were small corrections rather than one major new feature.
Are AI-assisted Linux patches automatically trusted?
No. A human must inspect, test and sign off the work. AI agents cannot certify patches with their own Signed-off-by line.
Comments