The Linux kernel’s process documentation has a new entry. It covers the use of AI coding assistants when contributing to the kernel: what’s permitted, what’s discouraged, and where the responsibility lies. On Hacker News it drew 442 points and the expected range of takes, mostly focused on whether AI tools are capable enough to help with kernel code at all.
That framing misses something. The document is not primarily a capability assessment. It is a clarification of an expectation that the kernel community has always held but rarely needed to write down: that every line of code you submit is code you understand, fully and personally. AI tools didn’t create this expectation. They made it visible by creating the first widespread mechanism for submitting code you have read but not derived.
What the Document Actually Says
The document does not prohibit AI tool use. It describes the conditions under which AI-assisted contributions are acceptable, and those conditions are not especially permissive.
The central requirement is that the submitter must understand every piece of code they submit, regardless of how it was produced. This is not a suggestion about good practices. It is a precondition for submitting at all: if you cannot explain the code, you should not be sending the patch. The document notes that maintainers may ask contributors to explain their code in detail, and that inability to do so is grounds for rejection.
Beyond understanding, the document raises the copyright issue. AI models are trained on large code corpora with varying licenses. Code they produce may reproduce fragments from non-GPL-compatible sources, and the submitter has no reliable way to audit this. The GPLv2 requirement is not negotiable in the kernel context, and the document is explicit that contributors bear responsibility for the licensing of what they submit. This is not hypothetical caution; it is the reason the Software Freedom Conservancy and Linux Foundation have both been cautious about AI tools reproducing GPL code.
The document also acknowledges a quality problem the community has observed directly. AI-generated kernel patches have been submitted and rejected at volume. Reviewers have noted hallucinated function names, incorrect use of locking primitives, memory management errors that look correct but violate invariants, and code that is structurally plausible but semantically wrong in ways specific to kernel internals.
Why Kernel Code Is Uniquely Hostile to Current AI Tools
Application code and kernel code look superficially similar. Both use C. Both have function calls, data structures, and loops. The differences are in the invariants, and the invariants are dense.
Consider locking. In a typical application, getting a lock wrong tends to produce a deadlock or a data race that shows up under load testing. In kernel code, the consequences depend on which lock, in which context, with which other locks held. Linux’s lock dependency validator (lockdep) exists specifically because the locking rules are complex enough that humans cannot track them by inspection alone. An AI model generating code that calls spin_lock_irqsave where spin_lock would suffice, or acquiring locks in the wrong order, is not producing obviously wrong code. It is producing code that will compile, may pass basic testing, and will cause an intermittent kernel panic under conditions that are hard to reproduce.
Memory management in the kernel follows rules with no analog in userspace. The difference between kmalloc and kzalloc matters. Whether you can sleep during allocation depends on the GFP_ flags and the calling context. Returning from an interrupt handler with a kernel preemption count imbalance will eventually corrupt something, and the corruption will manifest far from the cause. AI models have been trained on kernel code, so they know these function names. They do not reliably understand when each is appropriate because the when depends on context that spans the entire call stack, not the current function.
The same issue applies to RCU (Read-Copy-Update), which is the kernel’s preferred mechanism for protecting data structures accessed frequently from read paths. The rules for what you can do inside an RCU read-side critical section, how you signal that a read-side critical section has ended, and when it is safe to reclaim memory are subtle enough that the documentation for RCU spans dozens of pages and the correct usage patterns took years to stabilize even among experienced kernel developers. A model that has seen many examples of RCU usage will produce code that looks like RCU usage. Whether the specific pattern is correct for the specific call context is a different matter.
This is not a solvable problem by making the model larger or by training it on more kernel code. The issue is that correctness depends on reasoning about the global program state at the point where the code runs, including execution context, interrupt status, lock state, and the memory management zone. No amount of pattern matching on past kernel code substitutes for that reasoning.
The Review Burden Problem
The kernel review process is already resource-constrained. Maintainers for major subsystems handle large volumes of patches, and the bottleneck is not contributor throughput; it is reviewer attention. Linus Torvalds has noted repeatedly that reviewers are the limiting factor and that patches requiring significant reviewer effort to validate are patches that take slots from patches that could go in.
AI-generated patches that are subtly wrong create a specific kind of review burden. The code looks plausible; it follows conventions; it does something reasonable. Finding the error requires the reviewer to reason through the kernel’s invariants at the relevant point in the call path. If the contributor cannot do this reasoning (which is why they used an AI tool in the first place), the reviewer is doing it for them. Multiplied across the volume of AI-generated patches that have reached kernel mailing lists, this is a real drain.
Greg Kroah-Hartman, who maintains the stable kernel tree and the USB subsystem, has been direct about this. Patches that require reviewers to verify what the contributor should have verified themselves are not welcome, and this predates AI tools. What AI tools change is the volume and the profile of the contributor. Previously, a developer who submitted code they did not understand was usually inexperienced and the deficit was visible in other ways. Now, a competent developer can submit code they genuinely did not derive, and the surface characteristics of the patch may look like competent work.
What AI Tools Are Actually Useful For in Kernel Development
The document is not a dismissal of AI tools as a category. It describes the risks and limitations, but contributors who read it carefully will find space for legitimate use.
Understanding existing code is the clearest legitimate use. The kernel codebase is enormous; around 30 million lines as of recent counts. A developer working in an unfamiliar subsystem can use an AI assistant to understand what a function does, why a particular locking pattern is used, or what a comment means in context. This does not produce code to submit; it produces understanding that the developer then uses to write code themselves. The liability concerns largely disappear because the output is comprehension, not generated code.
Writing commit messages, documentation, and comments is another legitimate use. The kernel’s documentation requirements are specific and the formatting conventions are documented in Documentation/process/submitting-patches.rst, but the actual prose does not carry the same invariant complexity as C code. A commit message that inaccurately describes a change is a problem, but it is a correctness problem the submitter can verify by reading it; there is no hidden call-stack context that determines whether the explanation is right.
Generating test code and small, isolated helper functions where the specification is complete and the correctness can be mechanically verified falls somewhere in between. The document does not address this explicitly, but the standard it sets, which is full understanding of submitted code, can be satisfied here because the contributor can verify correctness by inspection in a way that is harder for code that touches complex kernel internals.
The Expectation the Document Makes Explicit
There is a habit in software development of treating code review as a quality control gate: if the reviewer approves, the code is good. The kernel community has never fully embraced this framing. The expectation is that the submitter understands the code well enough to defend it, explain it, and take responsibility for its behavior in production. Reviewers are a second set of eyes, not a safety net that can compensate for the submitter’s lack of understanding.
This expectation predates AI tools and would exist without them. What AI tools do is create a new mechanism by which code can be submitted without being understood, and they do so at a scale and by contributors whose other work looks competent. The document is the community writing down the expectation formally because the assumption that it was shared has turned out to be incorrect.
For developers who already held this standard, the document changes nothing. For developers who thought AI-generated patches were acceptable as long as they compiled and passed basic testing, the document is clarifying that the standard was never that low, and it is not going to be lowered to accommodate the tools.
The harder question the document leaves open is what happens to the contributor pipeline over time. If using AI tools well for kernel development requires deep enough understanding of kernel internals that the tools offer limited leverage, then the barrier to entry remains approximately where it has always been. The tools are most useful to people who already understand what they are doing, which is also true of most tools in complex technical domains.