Linus Torvalds Just Told AI Coders the Rules: How Linux Is Writing the Playbook for Machine-Generated Kernel Code

="">

The Linux kernel now has an official policy on AI-generated code. And it’s not what most people expected.

Rather than banning AI contributions outright or embracing them wholesale, the document — merged into the kernel’s documentation tree under Documentation/process/coding-assistants.rst — takes a characteristically pragmatic stance. You can use AI tools. But you own every line they produce, the same way you’d own code you copied from a textbook or asked a colleague to help write. No disclaimers. No excuses. Full accountability.

The new documentation file, visible in the mainline Linux kernel repository on GitHub, was authored with input from kernel maintainers and reflects months of internal discussion about how to handle the flood of AI-assisted patches arriving on mailing lists. The timing isn’t accidental. Large language models from OpenAI, Google, Anthropic, and Meta have become embedded in developer workflows worldwide, and the kernel community — responsible for the operating system running everything from Android phones to supercomputers to Mars helicopters — needed to draw clear lines.

The document’s central message is blunt: the developer who submits a patch bears complete responsibility for it. That means understanding what the code does, why it does it, and being able to defend every design choice during review. “The person using these tools is responsible for the output,” the document states. This isn’t a new legal theory. It’s an extension of the kernel’s existing Developer Certificate of Origin (DCO) framework, which requires contributors to sign off on patches certifying they have the right to submit the code and that it’s their work.

What the policy adds is explicit guidance about what AI-assisted contributions look like in practice, and where the traps are.

One of the sharpest warnings concerns code review. The document makes clear that AI tools should not be used as a substitute for human review of patches. This addresses a real and growing problem: maintainers have reported receiving patches that appear to have been generated by an LLM, submitted without meaningful human oversight, and sometimes accompanied by AI-generated commit messages that sound authoritative but contain fabricated justifications. The kernel community has dealt with low-quality patches for decades, of course. But AI has changed the volume and the veneer of competence.

Greg Kroah-Hartman, one of the most prolific kernel maintainers and the stable branch maintainer, has been vocal about this issue. In earlier mailing list discussions that preceded the formal documentation, he noted that AI-generated patches often look superficially correct but miss subtle context that only someone who understands the subsystem’s history would catch. A patch that “fixes” a warning by suppressing it, for instance, rather than addressing the underlying condition. Or a refactoring that introduces a race condition invisible to static analysis.

The policy doesn’t require contributors to disclose whether they used AI tools. This was a deliberate choice, and a controversial one.

Some open-source projects have gone the other direction. The Gentoo Linux distribution, for example, adopted a policy in early 2024 explicitly requiring disclosure of AI-generated content, as documented in GLEP 76. The Python Software Foundation has discussed similar requirements. But the Linux kernel’s position is that disclosure is less important than competence. If you understand the code and can stand behind it, the tool you used to write it is irrelevant. If you don’t understand it, no amount of disclosure will save you — or the kernel — from the consequences.

This philosophy aligns with how Linus Torvalds himself has historically approached tooling debates. He has consistently argued that tools are means, not ends, and that the quality of the output is what matters. In a February 2025 interview at the Open Source Summit in Australia, Torvalds acknowledged that AI coding tools are “clearly getting better” but expressed skepticism about their ability to handle the kind of deep systems programming the kernel requires. He compared the current state of AI code generation to autocomplete — useful for boilerplate, dangerous for anything involving concurrency, memory management, or hardware interaction.

The new documentation reflects that nuance. It explicitly acknowledges that AI assistants can be helpful for generating test cases, writing documentation, and producing initial drafts of straightforward code. But it warns that kernel development involves constraints that LLMs handle poorly: strict memory models, real-time requirements, backward compatibility obligations stretching back decades, and an enormous implicit knowledge base about why things are done certain ways.

Not just technical constraints. Social ones too.

The Linux kernel’s development process is famously rigorous and sometimes abrasive. Patches go through multiple rounds of review on public mailing lists. Maintainers ask pointed questions. Contributors are expected to explain their reasoning, respond to criticism, and revise their work — sometimes extensively. An AI tool can generate a patch in seconds. But it can’t participate in the review process. It can’t explain why it chose one approach over another. It can’t respond to a maintainer’s concern about a subtle ABI compatibility issue. That work falls entirely on the human submitter, and the documentation makes this obligation explicit.

The broader industry context here matters. Microsoft’s GitHub Copilot, now deeply integrated into Visual Studio Code, has become the most widely used AI coding assistant, with more than 1.8 million paying subscribers as of early 2025. Google’s Gemini Code Assist, Amazon’s CodeWhisperer (now part of Amazon Q Developer), and a growing roster of open-source alternatives like Codeium and Continue are all competing for developer attention. These tools are trained on vast corpora of open-source code — including, in many cases, the Linux kernel itself.

This creates a recursive problem the documentation doesn’t address directly but that looms over the entire discussion. LLMs trained on kernel code may generate output that closely resembles existing kernel patches, raising questions about copyright and the GPL license. The kernel is licensed under GPL v2, which requires derivative works to be distributed under the same license. If an AI tool produces code that is substantially similar to GPL-licensed kernel code, is the output a derivative work? The legal answer remains unsettled. The Linux Foundation has not issued formal guidance on this point, though it has funded research into AI and open-source licensing through its OpenSSF initiative.

The Free Software Foundation, which maintains the GPL, has taken a cautious position. In statements published on its website, the FSF has argued that AI-generated code may not be copyrightable at all under current U.S. law, since copyright requires human authorship. If that’s the case, AI-generated code couldn’t be licensed under the GPL — or any other license. This would create a gap in the kernel’s licensing framework that no policy document can fill.

The Linux kernel’s new documentation sidesteps this legal morass by placing the burden squarely on the contributor. By signing the DCO, you’re certifying that you have the right to submit the code. If your AI tool produced something that infringes someone else’s copyright, that’s your problem. The kernel community won’t investigate the provenance of every patch. But if a problem surfaces later, the contributor who signed off is on the hook.

Pragmatic. Maybe ruthless. Definitely effective as a governance mechanism.

The document also addresses a more mundane but equally important concern: code style. The Linux kernel has one of the most detailed and strictly enforced coding style guides in the open-source world, documented in Documentation/process/coding-style.rst. AI tools frequently produce code that violates these conventions — wrong indentation, incorrect brace placement, overly clever constructions that prioritize brevity over readability. The new policy reminds contributors that AI-generated code must conform to all existing style requirements, and that “the AI made it that way” is not an acceptable explanation during review.

Several kernel subsystem maintainers have already begun enforcing these guidelines more aggressively. Dan Williams, who maintains parts of the memory subsystem, posted on the kernel mailing list in March 2025 that he had started rejecting patches that showed telltale signs of AI generation without adequate human review — including generic commit messages, unnecessary refactoring of stable code, and the introduction of helper functions that serve no clear purpose. “I’m not against AI tools,” Williams wrote. “I’m against patches that waste reviewer time.”

That sentiment captures the kernel community’s fundamental concern. Reviewer time is the scarcest resource in open-source development. The Linux kernel has roughly 1,700 active contributors in any given release cycle, but only a few hundred people do the bulk of the review work. Every low-quality patch that lands on a mailing list consumes minutes — sometimes hours — of a maintainer’s attention. Multiply that across thousands of patches per release, and the cost becomes staggering. If AI tools increase the volume of patches without increasing their quality, the net effect on the project is negative.

The documentation acknowledges this explicitly. It asks contributors to consider whether their AI-assisted patch actually solves a real problem before submitting it. Not every cleanup is worth doing. Not every compiler warning needs a patch. And not every suggestion from an AI tool represents an improvement.

This restraint is unusual in an industry that has spent the last two years breathlessly promoting AI’s potential to transform software development. Consultancies like McKinsey have published reports claiming AI tools can boost developer productivity by 30 to 50 percent. Venture capital firms have poured billions into AI coding startups. And yet here is the most important open-source project in the world saying, essentially: slow down. Think. Make sure you actually understand what you’re submitting.

The contrast with the corporate world is striking. Companies like Google, Meta, and Microsoft have reported using AI tools internally for code generation at significant scale. Google’s internal code completion system reportedly suggests code that is accepted by developers roughly 30 percent of the time. But these companies have internal testing infrastructure, continuous integration pipelines, and dedicated review teams that can catch problems before they reach production. The Linux kernel’s review process, while rigorous, relies heavily on human judgment exercised by volunteers. The margin for error is thinner.

And the stakes are higher. A bug in the Linux kernel can crash millions of servers. A security vulnerability can expose critical infrastructure. The xz utils backdoor discovered in March 2024 — which involved a sophisticated social engineering attack on an open-source maintainer — demonstrated how a single compromised dependency can threaten the entire software supply chain. AI-generated code introduces a new vector for similar risks, not through malice but through the mundane accumulation of subtle errors that no one fully understands.

The kernel’s new policy is, in this light, a risk management document as much as a coding guideline.

It’s also a signal to the rest of the open-source world. The Linux kernel sets norms that propagate across thousands of projects. When the kernel adopted the DCO as an alternative to contributor license agreements, other projects followed. When it standardized on specific email-based workflow practices, tools were built to support them. If the kernel’s approach to AI-assisted development proves workable, it will likely become a template for other major projects.

Some projects are already watching closely. The FreeBSD project, the Apache Software Foundation, and the Eclipse Foundation have all been discussing AI policies internally, according to mailing list archives and public board meeting minutes. None has yet adopted anything as formal as what the Linux kernel now has in its documentation tree.

The document itself is relatively short — a few hundred words of clear, direct prose, consistent with the kernel’s documentation style. It doesn’t attempt to predict where AI tools are headed or prescribe specific workflows. It sets principles. You’re responsible for your code. You must understand it. You must be able to defend it. The tool you used to write it doesn’t change any of these obligations.

Simple rules for a complicated problem. That’s the Linux kernel’s way. It always has been.

Whether those rules will hold as AI tools grow more capable is an open question. Today’s LLMs struggle with the kind of low-level systems programming the kernel demands. But the models are improving rapidly. GPT-4 and Claude 3.5 already demonstrate meaningful competence at understanding and generating C code, including code that interacts with hardware and operating system internals. Future models may be able to produce kernel-quality patches that pass review without human intervention.

When that day comes — if it comes — the kernel community will need a different set of rules. But for now, the message from the world’s most consequential open-source project is clear: AI is a tool, not a developer. Act accordingly.