Linus Torvalds on AI-Written Linux Kernel Patches: Inside the Debate
How the Linux kernel maintainer summit tackled LLM-generated patches, the Sashiko review bot, and why Torvalds now won't code without an LLM.
What did Linus Torvalds say about AI-generated kernel patches?
At a recent Linux kernel maintainer summit, Torvalds argued that the real problem isn’t large language models, it’s people who don’t know the kernel using those models to generate patches anyway. He said LLMs “can do a good job,” but when driven by contributors with no understanding of kernel internals, the output is ugly even if it looks plausible. His proposed fix wasn’t to ban AI tools. It was to deprioritize patches from unknown or low-reputation contributors, regardless of whether a human or a model wrote them.
TL;DR
- Linus Torvalds told the kernel maintainer summit that LLMs aren’t the core issue, inexperienced contributors using LLMs to generate patches they don’t understand are.
- Sashiko, an agentic review tool used on kernel code changes, sparked a long debate about when human reviewers should step in versus trust automated review.
- Maintainers floated reputation-based prioritization for reviewing patches, but multiple participants warned that any reputation system gets gamed, citing social media as the obvious precedent.
- Torvalds revealed he personally started using an LLM on his own kernel work after months of custom setup, and now says he’s unwilling to go back to working without one.
- The group discussed signals for spotting bot-generated submissions, including overly verbose changelogs, wide sweeping changes across unrelated subsystems, and whether a reply triggers a human or an agent response.
- Jonathan Corbet raised a deeper worry: the kernel may be accumulating code that nobody fully understands or will maintain, a concern Rob Herring countered by noting no single person has ever understood the whole kernel.
- Torvalds suggested that requiring heavier LLM-assisted cleanup work (via something like an agent configuration file) would naturally filter out casual or underfunded contributors, which he said is intentional.
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
What is Sashiko and why did it start the argument?
Sashiko is an agentic review tool that automatically scans Linux kernel code changes, flagging issues before or alongside human reviewers. It’s one of several tools kernel developers already use to catch problems in submissions, but its growing role in triaging patches forced a broader conversation about review priorities.
The discussion split along subsystem lines. In ext4, maintainers said a single patch from an unknown contributor is often treated as likely “LLM-generated crap” and pushed down the review queue, while larger patch series get an architecture-level look regardless of who sent them. In networking, Paolo Abeni described a more formal scheme that weighs a contributor’s reputation, their history of reviews, and even their employer’s standing in the community.
Not everyone liked that approach. Dave Airlie warned that tracking contributor reputation creates privacy problems and invites gaming. Konstantin Ryabitsev agreed, pointing out that any reputation system eventually gets exploited, the same way people farm karma or engagement on social platforms, by finding subsystems with laxer review and padding their numbers there.
Laurent Pinchart raised a fairness complaint: some human developers feel they have to defend their work against Sashiko’s automated criticism, while LLM-generated patches from others sail through untouched. Abeni pushed back, arguing that automated review has measurably cut down the number of patches that introduce bugs. Peter Zijlstra summed up the ambivalence well, saying that reading LLM-generated review comments “shuts my brain down,” but admitting the tool still catches real problems.
Why did Torvalds say he can’t work without an LLM anymore?
Torvalds described experimenting with an LLM on a separate project for several months before trying one on actual kernel work for the first time. He took an old patch, ran it through the model for revision, and came away unwilling to go back to working without the tool. He plans to post that patch series publicly.
His reasoning was practical: why manually search for every call site of a function you’ve just changed when a tool can find and fix them automatically? But he was clear that this only works because he’d already spent roughly six months tuning his setup so the LLM wouldn’t produce bad responses. He declined to share his training materials, saying each developer has to go through that calibration process individually.
That’s an important nuance in his stance. Torvalds isn’t endorsing “open a chat window and let it write kernel code.” He’s describing a workflow built after months of configuration by someone who already deeply understands the codebase. For him, the tool amplifies expertise rather than replacing it.
How can maintainers tell a bot-generated patch from a real one?
Several heuristics came up during the summit, none of them foolproof.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Christian Brauner noted that overly verbose changelogs are often a tell, though he cautioned it’s not reliable since some human contributors are naturally verbose too (and the community has mistakenly accused real people of using AI before, a problem familiar from online art communities). Zijlstra suggested a more interactive test: reply to a patch and see what comes back. If a human is behind it, you’ll get an actual response; if not, the thread stalls or returns more generated text.
Corbet described encountering a series of over 100 patches sent within a single hour from a brand-new account, touching unrelated parts of the kernel tree, a pattern he said was obviously the output of an unsupervised bot. He noted the kernel saw nearly 800 first-time contributors in a single release cycle (7.3), many submitting non-trivial, wide-ranging changes they likely don’t understand and won’t be around to maintain.
Shuah Khan offered a quieter signal: she still spends time reviewing simple spelling-fix patches, reasoning that almost nobody instructs an AI agent to go fix typos. Trivial, low-value contributions have become an unlikely filter for identifying genuine human contributors, since bots are typically pointed at more “useful” code generation instead.
What happened to the Assisted-by tag?
Kernel development has experimented with attribution tags to disclose AI involvement in a patch, similar to existing tags like “Signed-off-by” or “Reviewed-by.” The summit’s discussion made clear this remains unsettled territory: tying trust or review priority to self-disclosed AI use is hard to enforce and easy to game, since nothing forces a contributor to admit a model wrote their patch. The broader consensus leaned toward judging patches by contributor track record and patch quality rather than relying on disclosure tags that nobody can verify.
Is deprioritizing new contributors the right fix?
This was the most contested part of the debate. Torvalds repeated several times that maintainers should simply deprioritize patches from contributors who haven’t established themselves, regardless of whether AI is involved. Jens Axboe (Hildenbrand in the discussion) pushed back, asking how that’s supposed to work in practice when you can’t always tell a serious new contributor from a drive-by one.
Christoph Hellwig offered the blunt answer: maintainers have always had the right to ignore patches. Nothing about LLMs changes that, and the idea that every submission deserves a response was never actually a kernel community rule.
Miguel Ojeda raised the harder long-term question: if the community deprioritizes new contributors wholesale, how does it keep finding talented people to replace developers who eventually age out? Ojeda and others suggested focusing mentorship on contributors who show signs of sticking around, like attending conferences or engaging past a single patch, rather than spreading review effort evenly across everyone.
Torvalds also floated making kernel contribution deliberately more resource-intensive, for instance through an agent configuration file requiring thorough automated cleanup passes that can take hours per session. He acknowledged this is too expensive for a free LLM account, and likely too expensive for many paid accounts too. When asked if that risks pushing out developers without money or resources, Torvalds said the kernel project wants serious developers, and that includes having the resources to participate. He clarified, after pushback from Pinchart, that he isn’t trying to force out people who don’t use LLMs at all, just stating that contributing now requires either deep personal effort or financial investment in tooling.
What about private kernel forks and AI-generated kernels?
The conversation also touched on companies maintaining private kernel forks instead of upstreaming their changes, a long-standing tension that AI tooling may sharpen. Ojeda noted that someone had already used an LLM to generate a complete kernel written in Rust, raising the question of whether working upstream is still cheaper than just generating your own.
Torvalds was skeptical this changes anything soon. He said the hard part was never writing code that works for one configuration, it’s handling the enormous diversity of real-world hardware and edge cases, which current AI-generated kernels aren’t close to solving. Sergei Starovoitov said he was aware of five such AI-generated kernels already in existence. Torvalds’s response was essentially: not worth worrying about yet.
Frequently Asked Questions
Did Linus Torvalds ban AI-generated patches from the Linux kernel?
No. He explicitly said he isn’t trying to exclude LLM use or push out developers who don’t use AI. His focus was on deprioritizing patches from contributors who don’t understand the kernel, independent of whether a model was involved.
What is Sashiko in the context of Linux kernel development?
Sashiko is an agentic review tool used to automatically analyze kernel code changes, flagging potential issues for maintainers. It became a focal point in debates over how much weight automated review should carry compared to human reviewers.
Does Linus Torvalds personally use AI tools to write code?
Yes. He described using an LLM on his own kernel patches after months of tuning a setup to avoid bad output, and said the experience made him unwilling to work without the tool going forward.
Why are so many new Linux kernel contributors suspected of using AI?
Jonathan Corbet noted a surge in first-time contributors, nearly 800 in a single release, with many submitting wide-ranging, non-trivial changes across unrelated subsystems in short bursts, a pattern maintainers associate with unsupervised bot activity rather than genuine learning contributors.
Is there an official tag for disclosing AI-assisted patches in the kernel?
The summit discussion suggests this remains unresolved. Attribution tags for AI involvement are hard to enforce since nothing compels a contributor to disclose model use, so maintainers are leaning more on contributor history and patch quality than self-reported tags.
