AI Is Now Writing and Reviewing Linux Kernel Code. Here's the Fallout
AI-generated patches and bug reports are reshaping Linux kernel development, forcing new disclosure rules and straining maintainer bandwidth.
What’s happening with AI in the Linux kernel?
AI tools are now writing patches, flagging bugs, and generating security reports for the Linux kernel at a scale the project has never dealt with before. Submissions tagged as AI-assisted have reportedly reached around 16% of patches in recent release cycles, not as a replacement for human-written code but stacked on top of it. That’s pushed release candidates to record sizes, forced the kernel community to write a formal AI disclosure policy, and reignited a debate over whether the flood of automated contributions is helping the project or quietly burning out the small group of people who review everything.
TL;DR
- AI-assisted patches now make up a meaningful share of kernel submissions, with Linus Torvalds noting one August release candidate as among the biggest RC6 builds in years, largely due to AI-driven fixes.
- A formal disclosure policy now exists specifically to govern AI use in the kernel, requiring contributors to declare when AI tools were used and to remain personally accountable for the resulting code.
- Accountability stays human. The policy explicitly rejects the idea of AI as a code “owner.” A person must be able to explain and defend the patch on the mailing list, not point to a chatbot.
- Most AI-driven changes are small fixes spread across drivers, filesystems, networking, and architecture code, rather than concentrated in one subsystem.
- Maintainer bandwidth is the real bottleneck. The kernel has thousands of contributors but only a few hundred core maintainers doing the bulk of review, and that imbalance shapes how the project reacts to any tool that increases patch volume.
- Old, unused drivers are getting culled faster partly because AI tools are generating bug reports against hardware almost nobody runs anymore, adding noise maintainers have to triage anyway.
- The AI debate echoes the Rust debate. Both are framed by maintainers like Greg Kroah-Hartman less around developer convenience and more around what actually reduces reviewer workload.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
How did AI patches and bug reports start showing up in the kernel?
There wasn’t a clean starting point. Before any formal policy existed, AI-assisted contributions were already trickling in without much fanfare. The patch generally credited as the trigger for the wider conversation came from kernel developer Sasha Levin. Shortly after that contribution, the mailing list erupted into a sustained argument about how AI should be used in kernel development, whether it should be used at all, and if it was going to be used, how contributors were supposed to be transparent about it.
That discussion didn’t stay theoretical for long. It became one of the more heated threads in recent kernel history, touching on everything from what counts as “AI-generated” to whether AI-assisted bug reports deserve the same weight as reports from a human who actually tested the failure. The result was a policy the project now points to whenever the topic resurfaces.
What does the kernel’s AI disclosure policy actually require?
The policy isn’t really about restricting AI use itself. It’s about visibility and responsibility. Contributors who use AI tools to help write or review code have to declare it, so maintainers know a patch had AI involvement somewhere in its lifecycle. More importantly, the human submitting the patch remains fully accountable for it. AI cannot be listed as the author or treated as the entity responsible for defending the change.
That distinction matters because kernel development runs on mailing-list conversation. When a maintainer has questions about why a patch does something a certain way, they need a person who understands the logic well enough to answer, argue, and revise. A chatbot can’t do that. The policy essentially forces every AI-assisted contribution back through a human filter before it becomes part of the record.
Why is the volume of AI-related patches straining maintainers?
The kernel has a lopsided structure: thousands of developers submit code, but a much smaller pool of core maintainers, often cited around 150 people, actually reviews the bulk of it. That imbalance has always shaped how the project evaluates new tooling, and it’s exactly why AI-generated volume is a bigger deal than it might sound.
Torvalds himself flagged this dynamic in early August, describing a release candidate as unusually large “even by normal standards,” calling it possibly the biggest RC6 in years by commit count, and attributing a lot of the fixes to review by various AI tools. He was careful to note this wasn’t necessarily bad, just that it had become the new normal. Most of the changes he pointed to were small, spread across drivers, GPU and sound code, networking, filesystems, and architecture-specific code. A few larger items stood out, including fixes tied to S390/zcrypt, the return of Btrfs fix-up worker infrastructure, and Netfilter IP set fixes, but the bulk of the increase was just volume, not complexity.
Remy doesn't write the code. It manages the agents who do.
Remy runs the project. The specialists do the work. You work with the PM, not the implementers.
More patches to review, even small ones, means more time spent per release. When that review capacity doesn’t scale with submission volume, the strain lands directly on the maintainers who already have the least slack in their schedules.
Is the rise in AI bug reports connected to the CVE spike?
Part of what’s driving frustration is that AI tools aren’t just writing patches, they’re also generating bug and security reports, some against hardware and code paths that see essentially no real-world use anymore. That’s contributed to a broader pattern: old drivers and support for legacy hardware getting dropped from the mainline kernel at a noticeably faster pace than before.
Dropping unused drivers isn’t new. The kernel has trimmed dead weight for years. What’s different now is the frequency. When AI-driven scanning surfaces a report against an ancient platform nobody runs in production, maintainers still have to triage it, even if the eventual answer is “remove the driver entirely.” Multiply that across dozens of subsystems and it becomes easier to understand why maintainers increasingly favor cutting support for hardware with no active user base rather than keep chasing reports nobody benefits from.
Whether this fully explains any specific rise in reported CVEs isn’t something that can be pinned down precisely from public discussion alone, but the mechanism is straightforward: more automated scrutiny surfaces more issues, some of which are genuinely new discoveries and some of which are noise against code nobody depends on anymore.
How does this connect to the kernel’s broader tooling debate?
The AI discourse doesn’t exist in isolation. It’s running in parallel with the kernel’s slow adoption of Rust, and both debates get argued in similar terms by senior maintainers. Kroah-Hartman has framed Rust’s value almost entirely around reviewer workload rather than developer comfort, arguing that because the kernel has far more developers than reviewers, tooling decisions should optimize for what reduces reviewer burden, not what makes writing code more pleasant.
The same logic applies to AI. A tool that generates ten patches a reviewer has to manually verify isn’t obviously a win, even if each patch is individually correct, because review time is the actual bottleneck. A tool that catches a real bug and hands a maintainer a clean, well-explained report is a different story. The kernel’s response to AI so far, disclosure requirements plus insistence on human accountability, is essentially an attempt to keep the technology in the second category and out of the first.
Frequently Asked Questions
Does the Linux kernel allow AI-generated code?
Yes, but only under a disclosure policy that requires contributors to state when AI tools were used and to remain personally responsible for explaining and defending the code on the mailing list.
Can an AI tool be credited as the author of a kernel patch?
No. The kernel’s policy is explicit that a human must own the contribution. AI cannot be treated as the accountable party for a change.
Why are AI-generated bug reports controversial in the kernel community?
Because they add to the review burden of a relatively small group of core maintainers, and some reports target hardware or code paths with little to no active use, creating triage work without a corresponding benefit.
Is AI contribution volume actually shrinking older kernel submissions?
No, it’s additive. AI-assisted patches are showing up on top of the existing volume of human-submitted patches, which is part of why recent release candidates have grown noticeably larger.
How does the Rust-in-the-kernel debate relate to AI in the kernel?
Both are evaluated by maintainers primarily through the lens of reviewer workload. Rust is favored where it reduces the kinds of bugs reviewers have to manually catch; AI tools are judged by whether they reduce or increase that same review burden.