Torvalds Draws the Line on Kernel LLMs

Linus Torvalds just settled an argument that had been simmering in kernel circles. In a reply on the linux-media list, he shut down the idea that Linux should treat large language models as something to wall off or quietly discourage. The message is blunt: the kernel is not an anti-AI project, AI is a useful tool, and people who cannot live with that can fork or leave.

That is not a soft nudge. It is the top-level maintainer putting his foot down on culture as much as on process. For anyone writing systems software, shipping drivers, or building tools that touch the kernel workflow, the signal matters more than the specific thread about Patchwork and Sashiko.

The Position, Without Soft Edges

Torvalds was responding to a discussion that had drifted into whether LLM use itself should be constrained. Roman Gushchin had noted that some earlier framing looked like a general anti-LLM stance. Torvalds agreed with the observation and then rejected the stance:

Linux is not one of those anti-AI projects, and if somebody has issues with that, they can do the open-source thing and fork it. Or just walk away.

He frames AI the same way the project has always framed compilers, static analyzers, and fuzzers: a tool. "It's clearly a useful one." A year earlier that claim might still have been debatable; he says it is no longer in question. People who still doubt usefulness "clearly haven't actually used it."

He is not claiming perfection. He calls out the real costs: extra maintainer workload, and LLMs that keep surfacing embarrassing bugs. The fix is not refusal. The fix is making the tools help maintainers instead of dumping more noise on them. Nobody is forced to use LLMs. He will, however, "very loudly ignore" people who try to stop others from using them.

The deeper framing is classic Torvalds. The kernel exists to produce better technology. Social and cultural angles are side effects, not the point. Decisions rest on technical merit, not fear of new tools. Calling the project a "social warrior" effort gets an explicit no.

Why This Lands Differently Than Other AI Debates

Most open-source projects that have argued about AI have done it through codes of conduct, contribution guidelines, or quiet maintainer preference. The kernel has none of that ambiguity now. The person who can reject patches and set release criteria has said the project will not become a refuge for anti-AI sentiment.

That matters because the kernel is still the reference point for serious systems work. If LLMs are legitimate there, they are legitimate in drivers, filesystems, networking stacks, and the tooling around them. The old purity argument ("real kernel hackers don't need autocomplete") no longer has cover from the top.

It also flips the burden. The interesting questions are no longer "should we allow this?" They are the ones Torvalds lists: how the economics shake out, and how to keep the tools from making maintainer life worse. "Is it useful" is closed.

What Changes for People Who Touch the Kernel

If you send patches, expect AI-assisted review to become normal rather than exceptional. Maintainers who already use LLMs for triage, diff reading, or bug hunting now have explicit cover. That does not mean sloppy generated code sails through. Torvalds notes the models keep finding embarrassing bugs; the inverse is also true. Generated or heavily assisted patches that introduce subtle lifetime, locking, or ABI mistakes will still get rejected, and the rejection will be sharper because the tooling is better at spotting them.

Practical implications:

• Treat LLM output the way you treat any other automated helper. You own the patch. The commit message, the changelog, and the technical justification still have to stand on their own.
• If you build or integrate tools (review bots, Patchwork extensions, static analysis front-ends), the mandate is clear: reduce maintainer pain. Noise that forces humans to re-verify every suggestion will get ignored or blocked, AI or not.
• Do not waste list bandwidth arguing that other people should not use the tools. That argument has been pre-emptively declared irrelevant.

For maintainers, the pressure goes the other way. The models will keep surfacing issues. Ignoring them because the source is an LLM is no longer a defensible posture. The work is to wire the useful signal into existing queues (Patchwork and friends) so that the extra eyes help rather than multiply the inbox.

The Caveats Still Matter

Torvalds is not selling a miracle. He explicitly pairs the usefulness claim with the observation that natural intelligence is not always great either. That is the right calibration. LLMs still hallucinate APIs, invent flags, and miss architecture-specific constraints. In kernel space those failures are not cosmetic; they are security and stability bugs.

The economy question he leaves open is real for contributors too. Model access, cost, and whether the best models stay behind paid APIs will shape who can actually use the tools effectively. That is outside the kernel's control, but it will affect contribution patterns over time.

None of that changes the core ruling. The project will judge patches and processes by technical result. Fear of the tool is not a technical argument.

The Signal, Not the Slogan

This was never really about one integration between Patchwork and Sashiko. It was about whether the kernel would treat LLM assistance as a legitimate part of the engineering toolkit or as a cultural contaminant. Torvalds chose the former, and he chose it without hedging.

For professional developers the takeaway is simple. AI-assisted systems work is no longer fringe inside the most conservative large open-source codebase that still matters. The remaining work is the unglamorous part: make the tools quieter, more accurate, and actually useful to the people who merge the code. Everything else is noise he has already said he will ignore.