The Linux Kernel's AI Coding Assistant Guidance Is More Warning Than Welcome

The Linux kernel project recently added a formal documentation page on using AI coding assistants when contributing. It lives in Documentation/process/, alongside submitting-patches.rst and coding-style.rst, which is itself a signal: this is process documentation, not a feature. The kernel maintainers are not celebrating a new tool. They are drawing a boundary around an existing reality.

The document does not ban AI assistance. That would be unenforceable and arguably counterproductive. What it does is restate, with unusual precision, what has always been true: when you put your Signed-off-by on a patch, you are certifying that you understand the change, that you have the right to submit it, and that you take responsibility for it. The Developer Certificate of Origin predates AI by many years, but the kernel community now finds it necessary to spell out that “I ran it through Copilot and it looked fine” does not satisfy that certification.

Why Kernel Code Is a Particularly Hard Target

Most discussions of AI-generated code quality stay at the level of correctness: does it compile, does it pass the tests, does it do what the comment says? Kernel development adds several layers that make this question much harder to answer.

The first is subsystem-specific locking semantics. The kernel has dozens of subsystems, each with its own locking disciplines, some of which are documented, many of which live in maintainer memory and review history. Getting locking wrong in the networking stack looks different from getting it wrong in the block layer. An AI tool trained on the entire kernel source has no reliable way to distinguish these contexts. It will produce code that follows the surface syntax of correct locking, while missing the invariants that the surrounding code depends on.

The second is the kernel’s memory model. The Linux Kernel Memory Model (LKMM) is notoriously subtle. It governs how memory accesses are ordered across CPUs, how READ_ONCE and WRITE_ONCE interact with compiler and hardware reordering, and when smp_mb() variants are required. Subtle violations of the memory model produce bugs that are essentially impossible to reproduce reliably. They surface as rare crashes on specific hardware, under specific load patterns, months after the change lands. An AI tool can produce code that looks correct against the C standard while being incorrect against LKMM.

The third is error handling. Kernel code has strong conventions around error propagation, resource cleanup, and goto-based unwinding. These conventions vary by subsystem and have evolved over decades. AI-generated code tends to handle error paths optimistically, producing code that works in the success case but leaks resources or leaves state inconsistent on failure.

/* A pattern that looks reasonable but is subtly wrong in many kernel contexts */
int do_something(struct device *dev)
{
    struct resource *r = allocate_resource(dev);
    if (!r)
        return -ENOMEM;
    
    int ret = configure_resource(r);
    if (ret)
        return ret;  /* resource r is leaked here */
    
    return 0;
}

This kind of error is not exotic. It is the kind of thing that appears in AI-generated kernel patches regularly, and it is the kind of thing that a maintainer who has reviewed thousands of patches will catch immediately and a contributor who copy-pasted from a suggestion will miss entirely.

The History Behind the Document

The kernel community’s caution here is not hypothetical. Greg Kroah-Hartman, one of the most active kernel maintainers, has written and spoken publicly about receiving AI-generated patches that were syntactically plausible but semantically broken, and about the reviewer time wasted on them. He has been blunt: if a patch looks like it was generated by an AI and the submitter cannot explain the reasoning behind it, it will be rejected.

The backdrop for this is the University of Minnesota incident in 2021, in which researchers submitted intentionally buggy patches to study how the kernel review process handled them. The kernel community’s response was swift and decisive: they reverted all UMN contributions and banned the university’s email domain from further submissions. The incident sharpened the community’s thinking about what it means to submit code in good faith, and it is part of why the explicit responsibility framing in the new documentation matters.

Since then, the volume of AI-assisted patch submissions has grown. Maintainers have developed informal heuristics for identifying them: characteristic phrasing in commit messages, generic variable naming, error handling that follows surface patterns without subsystem-specific awareness. The new documentation is partly a response to this, an attempt to raise the bar before review time gets consumed at scale.

What the Document Actually Asks For

The guidance is not “do not use AI.” It is closer to: if you use AI assistance, you must treat the output as a first draft that requires deep review, not as a finished contribution. Specifically, contributors are expected to understand every line of code they submit, be able to explain the reasoning behind design decisions, verify the correctness of locking and memory ordering, and confirm that the change handles all error paths correctly.

This is a higher bar than many contributors realize. The kernel review process is designed around the assumption that the submitter has done this work. Reviewers are not proofreaders; they are the second set of eyes on code that the author already believes is correct. When that assumption breaks down, the review process degrades from quality assurance into basic triage, which is expensive at the scale of a project receiving thousands of patches per release cycle.

The document also touches on copyright and licensing. AI-generated code raises unresolved legal questions about whether output from a model trained on GPL code carries GPL implications. The kernel is GPLv2, which makes this more than an academic concern. Contributors are advised to be aware of the provenance of AI-generated suggestions and to verify that they are not reproducing substantial portions of existing code in ways that could create attribution or licensing complications.

The Pragmatism Here Is Worth Noting

Some open source projects have responded to AI-generated code with outright bans. Certain competitions and academic settings have done the same. The kernel’s approach is different, and it reflects the community’s general philosophy: tooling is not the point, correctness is.

The kernel has always demanded that contributors understand what they submit. The C preprocessor, inline assembly, and the full machinery of the kernel’s internal APIs are all tools that can be misused by contributors who do not understand them deeply. AI coding assistants are one more tool in that category. The expectation is the same: know what the tool is doing and why, and be prepared to defend every line.

What makes the documentation interesting is that it exists at all. The kernel process documentation is not written for hypothetical contributors. It is written in response to observed patterns. The fact that maintainers felt it necessary to codify AI-specific guidance means the issue has crossed a threshold of frequency and cost that warranted formalization.

What This Means for the Broader Ecosystem

The kernel is an extreme case. Few projects match its complexity, its distributed maintainer structure, its historical depth of context, or its stakes. But the underlying tension it is navigating is not unique.

Every large, long-lived codebase has areas where the surface syntax of correct code diverges from its actual correctness. Locking and concurrency are the most obvious, but there are also API contracts, performance assumptions, and behavioral invariants that live in comments, documentation, and institutional memory rather than in the code itself. AI tools are good at producing code that satisfies local syntactic and structural patterns. They are not yet reliable at reasoning about these deeper constraints.

The kernel’s documentation is one of the cleaner statements of what responsible AI-assisted development looks like in a high-stakes context: use the tools if they are useful, but do not let them substitute for understanding. The sign-off is yours. The responsibility is yours. The AI is not a coauthor; it is an autocomplete.

For anyone contributing to the kernel, or to any project where correctness matters more than velocity, reading the full document alongside the existing submitting patches guide is worth the time. Not because the guidance is surprising, but because having it written down clarifies what was always implicitly required.