The Linux Kernel Finally Has a Policy on AI Assistance, and It Says What You'd Expect

The Linux kernel source tree now contains a formal document on AI coding assistants, tucked into Documentation/process/ alongside the other contributor guidance. It landed quietly, but the Hacker News thread it generated has accumulated hundreds of comments, which tells you something about how much tension exists around this topic.

The document doesn’t ban AI tools. It doesn’t require disclosure in commit messages. What it does is draw a clear line: whatever ends up in a patch is the contributor’s responsibility, full stop. If an AI hallucinated a function call, if the locking is wrong, if the memory allocation uses the wrong flags for the context, that’s on you. The kernel project is not going to audit your toolchain. It’s going to hold you accountable for your output.

This is pragmatic and, in the context of kernel development specifically, probably the only policy that makes sense.

Why the Kernel Is Particularly Unforgiving

Most application-level code has a reasonably good feedback loop. You write something, it compiles, the tests run, maybe it crashes in QA, you fix it. The blast radius of a bug is usually contained. Kernel bugs are different. A bad patch can corrupt memory silently, cause a system to hang under specific interrupt conditions, or introduce a race that only manifests on NUMA systems with more than 32 cores under certain scheduler states.

AI models are trained on code that overwhelmingly lives in userspace. The volume of kernel C in the training corpus is small relative to the total, and crucially, the feedback signal for kernel correctness, things like “this patch caused a page fault in interrupt context on a production system six months after merge”, never makes it into the training data in a meaningful way.

The result is that AI assistants generate kernel code that looks plausible and compiles cleanly but has subtle errors in exactly the areas that are hardest to catch in review.

Consider memory allocation. In the kernel, kmalloc(size, GFP_KERNEL) can sleep, which means you cannot call it while holding a spinlock, while in interrupt context, or anywhere in an atomic section. The correct flag in those contexts is GFP_ATOMIC. An AI asked to add a buffer allocation inside a function doesn’t reliably know which context the function runs in, and the error won’t show up unless you happen to test under the exact conditions that trigger the atomic path.

/* This looks fine, compiles fine, mostly works fine */
static irqreturn_t my_irq_handler(int irq, void *dev_id)
{
    struct my_buf *buf = kmalloc(sizeof(*buf), GFP_KERNEL); /* Wrong */
    /* ... */
}

The correct allocation here is GFP_ATOMIC, because interrupt handlers cannot sleep. A reviewer who doesn’t carefully check the call context will miss this. An AI generating the handler in the first place has no reliable mechanism to know it matters.

Locking is worse. The Linux kernel uses spinlocks, mutexes, RCU, seqlocks, and per-CPU data, each with different acquisition rules and different constraints on what you can do while holding them. RCU read-side critical sections are entered with rcu_read_lock(), must not sleep, and require that any pointer dereferenced was obtained correctly under RCU protection. AI models routinely generate code that acquires a lock but fails to release it on one error path, or that accesses RCU-protected data outside a read-side critical section, or that holds a mutex while calling something that might sleep in a context where sleeping is not allowed.

Greg Kroah-Hartman, one of the kernel’s most active maintainers and the de facto owner of the stable tree, has been blunt about this. He’s publicly described receiving patches where the submitted code referenced functions that do not exist in the kernel tree, where the API signatures were wrong, where the logic was a plausible recombination of real patterns that nevertheless didn’t match how the actual subsystem works. The maintainer burden from reviewing these patches is real, and it scales with submission volume.

The Hallucination Problem Is Structural

Kernel APIs change. Functions get removed, renamed, or semantically altered between versions. The kernel’s internal interfaces carry no stability guarantee, and the tree contains explicit comments throughout warning that a given interface may change without notice. An AI trained on a snapshot of the codebase will confidently suggest APIs that no longer exist, or that were superseded by a different approach, or that were deprecated in a particular subsystem context.

This isn’t a solvable problem by improving the model. It’s a consequence of the mismatch between training data freshness and an actively developed codebase that makes thousands of changes per release cycle. The kernel merges somewhere around 10,000 to 14,000 patches per development cycle. Whatever snapshot the model was trained on is already stale.

The kernel’s own documentation on submitting patches emphasizes that patches must be tested, that the submitter must understand what they’re submitting, and that the reviewer’s time is finite and valuable. The coding-assistants document extends this logic to AI-generated code: the tool might have written it, but you tested it, you understand it, you’re standing behind it.

The License Question Is Not Resolved

One area the document touches on carefully is copyright and licensing. The kernel is GPL-2.0-only. Code contributed to it must be compatible with that license, and the Developer Certificate of Origin process requires contributors to certify that they have the right to submit the code.

AI models trained on code scraped from the internet have no reliable way to guarantee that their output is free of GPL-incompatible material. The legal analysis here is genuinely unsettled. The question of whether AI-generated code constitutes a derivative work of its training data has not been resolved in any major jurisdiction. GitHub Copilot has faced class action litigation over exactly this. The kernel’s position is effectively: you certify the DCO, that’s your legal exposure, and you need to be comfortable with what you’re certifying.

For most contributors, this is probably fine in practice. For patches to security-critical subsystems, networking stacks, or anything where a future copyright dispute could have significant consequences, it’s worth thinking about.

What Responsible Use Actually Looks Like

The document is not a prohibition, and framing it as hostile to AI tools misreads it. There are areas where AI assistance is genuinely useful in kernel development without the reliability problems described above.

Documentation is one. Writing commit messages, explaining what a patch does, generating the prose portions of changelogs, these are areas where AI assistance produces lower-risk output and where human review is straightforward. The kernel has a strong culture around commit message quality, and getting a first draft of an explanation is relatively low-stakes.

Boilerplate is another. The kernel has a large amount of structural boilerplate: device driver scaffolding, sysfs attribute definitions, error-path cleanup patterns. These are high-volume, relatively mechanical, and the kernel’s coding style tools (checkpatch.pl, sparse, smatch) will catch many common errors. Using an AI to generate the skeleton and then carefully reviewing and testing is a different workflow than using AI to implement the logic.

The dangerous pattern is using AI to implement the nontrivial parts: the locking strategy, the memory management, the interrupt handling, the synchronization between subsystems. Those are exactly where AI confidence and AI correctness diverge most sharply.

The Broader Signal

The fact that this document exists at all is meaningful. A few years ago, the kernel community’s response to AI-generated patches was largely reactive: Greg KH or another maintainer would reject a patch, sometimes publicly, and the submitter would learn the hard way. Formalizing the guidance acknowledges that the tools are being used, that the community can’t pretend otherwise, and that a clear statement of expectations is better than a series of embarrassing rejections.

Other major open source projects are grappling with the same thing. The CPython project has seen AI-generated issues and pull requests. The OpenSSL project, where the stakes around correctness are extremely high, has had similar discussions. The Linux kernel’s approach, put the responsibility on the contributor, maintain the same quality bar regardless of how the code was generated, is probably the most defensible position available to any large project without the overhead of trying to detect or police tool use.

What the document won’t do is solve the upstream problem: as AI tools become easier to use and more people attempt kernel contributions, the volume of plausible-but-wrong patches will increase. Maintainer time is fixed. The kernel community has dealt with this before with the University of Minnesota intentional bug research controversy, which resulted in the reversion of the entire UMN patch history and a serious conversation about trust in the contribution process.

The coding-assistants document is the kernel community’s attempt to set expectations before that situation compounds. Whether contributors read it, internalize it, and actually test their AI-assisted patches thoroughly before submission is a different question entirely.