The Linux kernel recently merged a new document into its official process documentation: Documentation/process/coding-assistants.rst. It landed on Hacker News with 442 points and over 300 comments, which tells you something about the weight people attach to it. The kernel having a formal, versioned, maintainer-approved position on AI tools is genuinely new territory.
But reading the discussion around it, a lot of the reaction misses what the document is actually doing. It is not a ban. It is not an enthusiastic endorsement. It is the kernel community encoding something they have always required into language that addresses a new way of violating it.
The Document’s Context
This is not the first time the kernel community has had to deal with AI-generated patches. Greg Kroah-Hartman, one of the most active kernel maintainers, wrote publicly in 2023 about the surge of AI-generated patch submissions hitting subsystem mailing lists. His assessment was blunt: the patches looked superficially reasonable, followed some formatting conventions, but contained subtle errors that only someone who understood the subsystem would catch. Worse, when maintainers asked clarifying questions, the submitters could not explain their own patches. They had let a language model write the code and then signed off on it.
This is the failure mode the document is addressed at.
The Developer Certificate of Origin Is the Core Issue
The kernel’s contribution process requires every patch to carry a Signed-off-by line. This is not a formality. It is the contributor’s assertion of the Developer Certificate of Origin, a legal-ish document that certifies, among other things, that the contribution was created in whole or in part by you and that you have the right to submit it under the open source license indicated.
The critical phrase is “created in whole or in part by you.” When a contributor pastes a function they do not understand into a patch and attaches their Signed-off-by, they are making a certification that is, at minimum, misleading. They did not create the code. They prompted for it and forwarded the output.
The coding-assistants.rst document forces that question into the open. It makes explicit that using an AI tool to generate code you submit does not relieve you of the obligation to understand and stand behind what you are submitting. The Signed-off-by is still yours. The explanation in the cover letter is still yours. The responsibility for what the patch does to the kernel is still yours.
What the Document Actually Covers
The document addresses several practical dimensions of AI tool use in kernel development.
It distinguishes between using AI as a comprehension aid versus using AI as a code generation shortcut. Looking up how a particular subsystem works, asking an LLM to explain an unfamiliar locking pattern, or using AI-assisted search to navigate 28 million lines of C code, these are reasonable uses that do not affect the authorship question. The contributor still understands what they are submitting; they just used a new kind of reference material.
The problem is code generation without comprehension. The kernel’s patch review process presupposes that the author can defend their implementation choices. The cover letter is supposed to explain why the change is made this way and not another way. Reviewers ask questions. Maintainers push back. If you cannot engage with that process because the code came from a prompt you do not fully understand, you are not actually contributing, you are creating review burden.
The document also addresses licensing. The GPL licensing of the kernel creates a non-trivial question about AI-generated code: if a model was trained on GPL-licensed code and produces output that reproduces or is substantially derived from it, does that output carry GPL obligations? This remains legally unsettled, and the kernel’s position is essentially that contributors are responsible for ensuring their submissions are clean. An AI tool does not provide that assurance.
Why the Kernel Is a Useful Test Case
Most codebases have review processes. The Linux kernel’s review process is extreme. A patch touching a driver might go through the subsystem maintainer, a tree maintainer, and then Linus himself before landing. The kernel development statistics show thousands of patches per release cycle, contributed by hundreds of engineers across hundreds of companies. The review bandwidth is finite and precious.
This matters because it makes the AI assistance problem concrete in a way that a typical web application codebase does not. When Kroah-Hartman or another maintainer has to review a patch that introduces a subtle race condition because the model hallucinated a locking pattern that does not apply in that subsystem, the cost is real reviewer time diverted from patches that would actually improve the kernel.
AI tools lower the cost of producing code. They do not lower the cost of reviewing code. When the production cost drops and the review cost stays fixed, the review queue grows. The kernel has seen this directly.
The Legitimate Uses Are Real
None of this means AI tools have no place in kernel development. The kernel is notoriously hard to navigate. The interaction between memory management, the scheduler, and specific driver subsystems involves a level of contextual knowledge that takes years to build. An experienced systems programmer contributing to a new subsystem for the first time can genuinely benefit from using an LLM to accelerate their ramp-up.
The key distinction the document draws is about authorship and accountability. Using AI to understand code so that you can write better code yourself is fine. Using AI to write code that you then submit without understanding it is not.
This mirrors how good engineers already use documentation, StackOverflow, or the kernel.org archives. You read, you understand, you write. The tool is in service of the engineer’s judgment, not a replacement for it.
The Broader Lesson
The kernel’s formal documentation of this position is worth paying attention to beyond its immediate context. Most serious open source projects are going to arrive at similar places eventually. The questions the kernel is asking, what does authorship mean, who is accountable for submitted code, how do maintainers protect their review capacity, are not unique to kernel development.
What is unique is that the kernel asked these questions and wrote down the answers in a canonical, versioned document that is now part of the official process documentation. Other projects typically have informal norms, mailing list threads, or individual maintainer preferences. The kernel has coding-assistants.rst.
For developers who use AI tools responsibly, the document changes nothing. The standard was always that you understand what you submit. The document just makes that standard explicit in a context where it has become possible to violate it in new ways.
For developers who have been using AI output as a shortcut past the comprehension requirement, the document is a clear statement that the kernel’s maintainers know the difference and will not accept it. The Signed-off-by line means something specific, and attaching it to code you cannot explain is a misrepresentation, regardless of how the code was generated.