The Linux Kernel Formally Addresses AI Coding Assistants, and the Reasoning Matters

The Documentation/process/ directory in the Linux kernel tree is not where opinions go to live. It is where hard-won process knowledge gets codified after years of mailing list lessons, failed submissions, and maintainer burnout. That directory contains submitting-patches.rst, coding-style.rst, email-clients.rst, and the DCO guidance. It is the canonical, durable record of how the project works.

So when a new file called coding-assistants.rst appears there, that is not a mailing list thread or a blog post from a maintainer. That is the kernel project deciding the question of AI-assisted contributions is settled enough to put into official documentation. The bar for that decision is high.

The document does not ban AI assistance. That would be unenforceable and probably counterproductive. Instead it lays out the risks specific to kernel contributions, guidance on how to use these tools responsibly, and disclosure expectations. Understanding why those specific risks matter requires thinking about what makes kernel development different from most software projects where AI coding tools have been normalized.

Why Kernel Code Is a Particularly Hard Case

Most discussions about AI coding tools focus on productivity: how many lines written, how fast PRs merge, whether tests pass. The kernel development community is thinking about a different set of problems.

The correctness stakes are categorically different. A subtle race condition in a locking primitive or a wrong memory barrier in an architecture-specific path can cause data corruption, silent state inconsistencies, or security vulnerabilities that affect every system running that kernel. Those bugs may not appear under test conditions or normal load. They surface years later in production under specific timing circumstances, and by then the causal chain is nearly impossible to reconstruct.

The review bottleneck is a second distinct problem. Greg Kroah-Hartman, who maintains the stable kernel tree, has been explicit on the mailing list about the consequences of low-quality submissions. Maintainers are already at capacity. When patches arrive that appear plausible at a glance but contain hallucinated function names, incorrect assumptions about API behavior, or fixes for bugs that do not actually exist in the described form, reviewers burn real time on them. The cost is not just the time spent on that patch. It is the attention not spent on the legitimate, careful submissions waiting in the queue.

The third concern is license provenance. The kernel is GPL-2.0-only, and that is not a formality. The entire distribution ecosystem depends on it. LLMs trained on heterogeneous codebases with varied licenses produce output with no clean chain of provenance. Whether that output constitutes a derivative work of training data, and under what license, is a question that has not been resolved by courts or clear consensus. The kernel project is not positioned to absorb that legal uncertainty.

The Hallucination Problem in Systems Programming

There is a specific failure mode with LLMs in low-level systems code that does not have a clean analog in higher-level application development: confident incorrectness in exactly the domain where that confidence causes the most damage.

An LLM writing a web API handler that gets an HTTP status code wrong produces a bug that is easy to reproduce and obvious in testing. An LLM writing kernel memory ordering code that omits a necessary barrier on architectures with weak memory models, like ARM or PowerPC, produces code that may work perfectly on x86 (which has a strong memory model) and silently corrupt state elsewhere. x86’s memory model papers over a lot of mistakes. The rest of the architectures the kernel supports do not.

Current models have been trained on large volumes of kernel code. That sounds reassuring until you consider that they have also been trained on Stack Overflow answers that simplify memory models for pedagogy, blog posts that describe older API semantics, and documentation that predates architectural changes. A model can reproduce the pattern of a memory barrier call without understanding the invariant it is supposed to maintain, and the resulting code will look like correct kernel code to a reviewer who is moving quickly.

The kernel’s existing static analysis tools, including sparse and smatch, catch some classes of errors. They are not sufficient for memory ordering mistakes, which require reasoning about hardware execution models rather than syntactic or data-flow properties.

How Rust Fits Into This

Rust entered the kernel tree in version 6.1, adding a second language to a codebase that had been C for its entire history. The ownership and borrowing model gives Rust a structural advantage for a class of memory safety bugs: use-after-free, double-free, and certain data race patterns become compile errors rather than runtime surprises.

But Rust’s safety guarantees come with a significant caveat in kernel context: unsafe blocks are common and necessary when interfacing with hardware or C code. The rules for what is actually safe inside an unsafe block in kernel Rust are not the same as the rules for unsafe in userspace Rust, and they are not something a model has reliably internalized from training data. The situation is arguably harder than kernel C in one respect: developers may incorrectly assume Rust’s safety guarantees extend into regions where they explicitly do not.

This is not an argument against Rust in the kernel. The safety wins for the code that stays in safe Rust are real. It is an argument that AI tools interacting with kernel Rust need the same skeptical scrutiny as AI tools interacting with kernel C, and in some cases more, because the safety signal is misleading.

Disclosure and the DCO

The kernel’s existing accountability mechanism is the Developer Certificate of Origin, expressed as the Signed-off-by tag in every commit. It is a legal statement: you have the right to submit this code, you understand it will be distributed under the project’s license, and you stand behind it. That accountability structure is what makes the kernel’s distributed development model work. Maintainers can apply patches from strangers because each patch has a legal attestation attached.

The AI guidance fits into this structure by extending the disclosure norm. When an AI tool substantially contributed to a patch, contributors are expected to say so. The purpose is not punitive. It is informational. Reviewers given the right context can allocate their attention correctly: verifying that referenced functions exist with the described signatures, checking that the fix addresses the actual root cause rather than the model’s inference about it, and looking harder at edge cases in the generated code.

This is the right framing for disclosure requirements in any open source project. The question is not whether AI assistance is legitimate in the abstract. The question is whether reviewers have what they need to do their job.

What Other Major Projects Are Doing

The CPython project has handled AI-generated contributions primarily through code review rather than formal policy. The core development team is small enough that the signal-to-noise ratio remains manageable, though individual reviewers have been vocal in PRs about recognizing LLM output patterns.

The Rust language project’s RFC process creates a natural filter: a convincing RFC requires understanding the interaction effects between a proposed change and the rest of the language, which is exactly the kind of deep contextual reasoning where current LLMs fall short. The process does not need to call out AI specifically because the quality bar itself does the filtering.

The kernel’s decision to document guidance explicitly, rather than relying on reviewer judgment or tribal knowledge, is consistent with how the project operates across every other process dimension. The kernel does not assume that contributors know the expectations. It writes them down in the Documentation/process/ directory and points people there.

What This Signals About Where the Tools Are

The existence of coding-assistants.rst is its own data point about the current state of AI coding tools. A document this formal gets written when the project has concluded that AI-assisted contributions are common enough and problematic enough to warrant official guidance. That threshold has now been reached in the most scrutinized open source project in existence.

The guidance that makes sense today may look different in two years. Reasoning models are improving at the specific kinds of multi-step logical inference that kernel correctness requires. Tool-integrated code review, where an AI assistant helps a human reviewer rather than replacing them, is a different use case than code generation, and one that fits better with how expert kernel contributors actually think about AI assistance. The document’s placement in Documentation/process/ means it can evolve as the tools evolve.

But the underlying framework, centered on disclosure, accountability, and reviewer-centric thinking rather than contributor convenience, is the right foundation. Kernel development is hard because it requires getting details right that are invisible to most software engineering contexts. AI tools that help contributors navigate that complexity are valuable. AI tools that create the appearance of correctness while introducing subtle errors are a net negative for the project, and the guidance draws that distinction clearly.