The Linux Kernel's New AI Policy Document Is About Accountability, Not Bans

The kernel is not a normal codebase. It powers everything from Android phones to supercomputers, receives tens of thousands of patches per year, and treats style violations as blocking issues. It carries thirty years of institutional memory in its review process, its mailing list archives, and its contributor documentation. So when Documentation/process/coding-assistants.rst appears in the tree as official guidance, it is worth reading carefully.

The document sits alongside the contribution guidelines that every kernel developer is expected to read before submitting patches, and that placement matters. This is not a blog post from a maintainer or a comment in a patch review thread; it is policy, in the same directory as the submission process, the coding style guide, and the documentation on stable tree rules. The kernel community codifying its position on AI tools is significant not because it bans them, but because it formalizes expectations around something that maintainers have been handling informally for the past couple of years.

Why the kernel is a difficult target for AI tools

Most AI coding assistants were trained on publicly available code, and the kernel is well-represented in that training data. There is a catch, though: the kernel’s internal APIs change constantly, and the relationship between kernel versions and their API surfaces is not something most language models track reliably. A model might confidently suggest calling pci_request_region() in a context where the modern approach uses pcim_enable_device() with managed resources, or suggest memory allocation patterns that were correct in 3.x but are subtly wrong in 6.x.

The kernel also uses programming patterns that look deeply strange to a model trained on userspace C. RCU (Read-Copy-Update) is the canonical example. The rules around rcu_read_lock(), when you can and cannot sleep, what rcu_dereference() provides, and when you need rcu_assign_pointer() instead of a plain assignment are non-obvious even for experienced developers. Getting these wrong does not produce a compile error. It produces a race condition that manifests under specific scheduling conditions at runtime.

Locking presents the same challenge. The kernel’s lock validator (lockdep) catches many real bugs at runtime, but there are still ordering constraints and sleeping-in-atomic-context bugs that require genuine understanding of the execution environment. An AI tool that pattern-matches against similar-looking code can produce something that compiles and passes basic testing while containing a correctness issue.

Here is a representative example. An AI might generate something like this for an interrupt handler:

static irqreturn_t my_irq_handler(int irq, void *dev_id)
{
    struct my_device *dev = dev_id;

    spin_lock(&dev->lock);
    /* AI-suggested: wrong allocation flag for atomic context */
    dev->buf = kmalloc(BUF_SIZE, GFP_KERNEL);  /* BUG: can sleep */
    spin_unlock(&dev->lock);

    return IRQ_HANDLED;
}

The correct allocation flag in an interrupt handler is GFP_ATOMIC. GFP_KERNEL can sleep, which is illegal inside a spinlock and illegal in interrupt context. The AI knows what kmalloc does and knows the general pattern, but it does not model the execution context that makes GFP_KERNEL wrong here. Lockdep will not catch this specific issue without additional runtime conditions. This is the failure mode the kernel’s new documentation is concerned about: plausible code that is quietly wrong.

What the documentation asks contributors to do

The coding-assistants.rst document acknowledges that AI tools exist and that contributors use them. It does not mandate disclosure in every case, but it establishes clear expectations around quality and responsibility. If you use an AI tool and submit a patch, the patch is yours. The maintainer reviewing it holds you accountable for its correctness, not the tool.

This connects directly to the kernel’s existing accountability mechanisms. The Developer’s Certificate of Origin, represented by the Signed-off-by tag on every patch, is an assertion that you understand what you are submitting and have the right to submit it. Using an AI to generate the patch does not change that assertion. It raises the bar for how thoroughly you need to verify the output before signing off.

The document also calls out AI-generated commit messages as a specific problem. A good kernel commit message explains why a change is being made, what the problem is, what the fix does, and often includes information about how the bug was found or what testing was performed. AI tools produce plausible-sounding but vague commit messages that are frequently wrong about the actual motivation for a change. Maintainers have been rejecting patches on this basis for a couple of years, and the new documentation formalizes what was previously informal feedback in patch review threads.

The review burden underneath the policy

There is a practical concern underneath the policy discussion. Kernel maintainers are mostly volunteer reviewers with finite bandwidth. AI tools have the potential to dramatically increase the volume of low-quality patches, a problem that has already materialized in several major open source projects. The kernel has seen what maintainers describe as hallucinated patches, where the contributor clearly used an AI tool but did not verify the output against actual kernel behavior, current API documentation, or relevant subsystem conventions.

The Rust for Linux effort, which integrates Rust as a second implementation language in the kernel tree, has a compounded version of this problem. Its APIs and safety abstractions are new enough that AI training data is sparse and often outdated. Using an AI to write Rust kernel code is currently more likely to produce plausible-looking but incorrect unsafe blocks than to produce something a maintainer will accept without significant revision.

The cumulative effect on maintainers is real. When a significant fraction of submitted patches require extra scrutiny because the submitter offloaded verification to a tool, the review queue slows down for everyone. The new documentation is partly about protecting that shared resource.

What responsible use looks like in practice

The document’s framing suggests treating AI tools as a first-draft engine rather than an authority. Use them to scaffold the structure of a new driver, to generate boilerplate for a new subsystem file, or to recall the syntax for something you do not write often. Then verify every part of it against the actual kernel documentation, the relevant subsystem’s existing code, and the available testing infrastructure.

This is broadly how experienced contributors who use these tools describe their workflow. The AI is useful for repetitive, well-documented patterns. It is counterproductive for anything involving kernel-specific semantics, because the model’s confidence is not calibrated to its knowledge of kernel internals.

There is also a testing obligation. The kernel’s own test infrastructure, KUnit for unit tests and kselftest for broader integration-style coverage, exists partly to catch subtle correctness bugs of exactly the kind AI tools tend to introduce. Using AI to generate code raises the testing obligation, not the other way around.

The broader signal

The kernel adding this document to its official process documentation means the community has crossed a threshold. The problem is common enough and well-understood enough that informal guidance from individual maintainers needed to become written policy.

Other major projects have not gotten here yet. CPython’s developer documentation does not have equivalent guidance. Neither does LLVM’s developer policy. But the underlying pressure is identical: more contributors using AI tools, more reviewers working through patches that look plausible but contain hallucinated APIs or wrong semantics, and a finite pool of maintainer time to absorb it.

The kernel’s approach, which is essentially “use whatever tools you want, but own the output completely,” is a reasonable baseline for any high-stakes codebase. It does not treat AI tools as inherently suspect, and it does not lower the bar for what gets merged. Whether that balance holds as AI tools improve and their use becomes more pervasive is a genuinely open question. For now, the kernel has done something that most projects have avoided: it has written down what it expects, and those expectations live in the same place as all the other non-negotiable rules.