The Linux Kernel's AI Guidelines Expose What Responsible Contribution Actually Requires

The Linux kernel project has added a formal document on coding assistants to its official process documentation. It sits alongside submitting-patches.rst and coding-style.rst, which tells you something about how the kernel community treats this: not as a passing concern, but as a process question requiring a written answer. The Hacker News discussion drew over 300 comments, which reflects how much tension there is in the broader developer community around what this kind of policy means in practice.

The document does not ban AI tools. That framing has been applied to it by commenters who wanted a cleaner story, but the actual position is more careful. The kernel community recognizes that developers use tools, and that coding assistants are now tools developers use. What the document establishes is a set of expectations about responsibility, disclosure, and the limits of what these tools can reliably produce in a kernel context.

Why Kernel Code Is Harder Than It Looks

To understand why the policy exists at all, it helps to appreciate what makes kernel contributions structurally different from most software development.

The kernel has no standard library, no memory-safe runtime, no automatic resource cleanup, and no tolerance for a large class of bugs that would be annoying in application code and fatal in kernel space. Error handling follows a specific idiom using goto labels for cleanup paths. Locking disciplines are intricate and subsystem-specific. A function that looks correct to someone who knows C well may still be wrong because it violates RCU read-side constraints or fails to hold the right lock when accessing a protected data structure.

Here is a simplified example of the kind of pattern the kernel expects:

static int my_driver_probe(struct platform_device *pdev)
{
    struct my_priv *priv;
    int ret;

    priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
    if (!priv)
        return -ENOMEM;

    ret = my_driver_init_hw(priv);
    if (ret)
        return ret;

    return platform_set_drvdata(pdev, priv);
}

This is idiomatic. A coding assistant trained on kernel code can probably produce something that looks like this. The problem is the cases where it cannot: where a subsystem has its own resource management conventions, where the allocation path requires a specific GFP flag that only makes sense in context, or where a missing memory barrier will cause a race that only manifests on certain architectures under specific load patterns.

The bugs that AI tools tend to produce in kernel code are not the obvious ones. They are the subtle ones, the kind that pass checkpatch.pl, compile cleanly, and survive initial review before someone with deep subsystem knowledge spots the problem. Those bugs are expensive to catch and potentially dangerous.

The DCO Problem

The kernel uses a Developer Certificate of Origin for all contributions. When a developer adds Signed-off-by: Name <email> to a patch, they are certifying under the DCO that the work is their original contribution, or that they have the right to submit it under the applicable license, and that they understand it will be incorporated into the kernel under the GPL.

AI-generated code complicates this in ways that the community has been working through for a few years. The tools are trained on enormous corpora that include GPL-licensed code, including kernel code itself. The legal question of whether output from such a tool constitutes a derivative work, and what license obligations that creates, is not settled. The coding-assistants document does not resolve this question either, but it requires contributors to be aware of it and to take responsibility for what they submit. The sign-off is not a formality; it is a claim of understanding and accountability.

Greg Kroah-Hartman, one of the kernel’s most prolific maintainers, spent time in 2023 publicly rejecting patches that appeared to be AI-generated not because he opposes the tools categorically, but because the patches were low quality and their authors appeared not to understand what they had submitted. The maintenance burden of reviewing a patch that looks plausible but is subtly wrong, explaining the problem, and waiting for a revision is significant. The kernel development process runs on volunteer maintainer time, and that time is finite.

What the Document Actually Requires

The coding-assistants documentation asks contributors to disclose when they have used AI tools to help write or review code. This is the clearest and most direct requirement. It is not asking for an extensive note in every patch, but it is asking for honesty about the process.

Beyond disclosure, the document emphasizes that contributors remain fully responsible for the code they submit. Using an AI assistant does not transfer any of that responsibility. If the code is wrong, the person who signed off on it is accountable. This sounds obvious, but it addresses a real pattern where contributors were submitting AI-generated patches without carefully verifying them, treating the tool’s output as authoritative.

The document also implicitly sets expectations for how AI tools should fit into a contribution workflow. Using them to understand existing code, to draft documentation, to generate boilerplate for well-understood patterns, or to check for obvious style issues is different from using them to write core logic in a subsystem the contributor does not understand. The former is a productivity tool; the latter is a way of submitting code you cannot vouch for.

The Broader Significance for Open Source

The kernel is not the first open source project to address this, but it carries particular weight. When the Linux kernel process documentation says something, it tends to become a reference point. Projects like Python, the GCC compiler collection, and various major BSD systems are all working through similar questions. The kernel’s formal stance, emphasizing contributor accountability rather than blanket prohibition or uncritical acceptance, is likely to influence how other projects frame their own policies.

There is a broader issue here about the review economy in open source. Maintainers review contributions in exchange for the value those contributions provide. AI tools are increasing the volume of contributions, including low-quality ones, without increasing the pool of people who can review them. The asymmetric exchange at the heart of open source maintainership gets harder when the cost of review rises faster than the quality of contributions.

The coding-assistants document is partly a response to this dynamic. It says: if you use these tools, use them in a way that does not add to the review burden. Understand what you submit. Take responsibility for it. That is a reasonable ask, and it is consistent with what the kernel community has always expected from contributors using any tool.

What This Means in Practice

For developers who want to contribute to the kernel and who use AI assistants as part of their workflow, the policy is workable. Use the tools for what they are good at: navigating unfamiliar subsystems, understanding existing patterns, generating first drafts of documentation or straightforward code. Then read what they produce carefully. Run the build. Run the tests that exist. Check against the relevant subsystem documentation. Look at recent commits in the same area for conventions the tool might have missed.

Do not submit a patch you cannot explain line by line. That requirement predates AI tools; the coding-assistants document just makes clear it applies equally to AI-assisted work.

The document is a signal that the kernel community has thought carefully about this, and that the thinking is more nuanced than either “AI will write the kernel” or “AI contributions are banned.” It reflects an attempt to preserve the quality standard that makes the kernel what it is, while acknowledging that developers will use the tools available to them. That balance is harder to maintain than either extreme, and the fact that it is now written down is worth paying attention to.