The Linux Kernel Drew a Line on AI-Generated Code — And It's Simpler Than You Think

The world’s most battle-tested open-source project just weighed in on AI-generated code. The Linux kernel — the software running billions of devices from Android phones to cloud servers — has added official guidelines for AI coding assistants to its documentation. The verdict isn’t a ban. It’s something more interesting: a restatement of a principle the project has held for decades, applied to a new reality.

Why the Kernel Had to Say Something

The Linux kernel processes tens of thousands of patches per year. Maintainers were already drowning in review work before AI entered the picture. Then the floodgates opened.

Patches generated with Copilot, ChatGPT, and Claude started showing up on the kernel mailing list with increasing frequency. Many looked plausible on the surface but missed the deep contextual understanding that kernel code demands — subtle memory management constraints, concurrency assumptions, architecture-specific behavior. Maintainers found themselves repeatedly asking the same question: “Did you actually write this, or did an LLM?”

The pattern was clear enough that the community decided it needed a formal policy rather than ad hoc gatekeeping.

The Core Rule: You Sign It, You Own It

The kernel’s AI policy boils down to one principle: whoever puts their Signed-off-by tag on a patch bears full responsibility for that code.

This isn’t new. The kernel has used the Developer Certificate of Origin (DCO) for years — a lightweight legal framework where contributors certify that their code complies with the project’s open-source licensing. When you sign off on a patch, you’re personally vouching for its correctness, its license compliance, and its adherence to kernel coding standards.

AI doesn’t change this equation. Used a language model to draft the code? Fine. But your signature means you’ve verified every line as if you’d written it yourself. The tool is irrelevant. The responsibility is not.

Why AI Can’t Be a Co-Author

Some open-source projects have started listing AI tools as co-authors using Co-authored-by tags. The kernel won’t allow this, and the reasoning is straightforward.

In the kernel’s contribution system, authorship is tied to legal accountability. If a patch introduces a license violation or a critical bug, there needs to be a person who can be held responsible. AI is not a legal entity. It can’t answer questions on a mailing list. It can’t be held to account. Listing it as a co-author creates an accountability gap the kernel community isn’t willing to accept.

Linus Torvalds himself has been notably pragmatic about AI tools — he’s not opposed to developers using them. What he objects to is developers using AI as a shortcut to skip the understanding part. There’s a difference between using a tool to write code faster and using a tool to submit code you don’t understand.

Maintainers Get Explicit Veto Power

The guidelines formalize something that was already happening in practice: maintainers can demand that a patch submitter explain their code in detail, and they can reject patches when the submitter can’t.

On the kernel mailing list, this plays out predictably. A maintainer asks: “Walk me through the logic here.” If the developer stumbles — if they clearly don’t understand what their own patch does — it’s dead on arrival. This has always been true, but now it’s codified with AI specifically in mind.

The implication is blunt. If you want to contribute to the kernel using AI-generated code, you need to be able to explain every line as fluently as if you’d written it from scratch. The bar isn’t “it compiles and passes tests.” The bar is “you understand it deeply enough to defend it under questioning.”

What This Signals for Open Source

When the Linux kernel sets a policy, the rest of the open-source world pays attention. This isn’t just one project’s internal rule — it’s the closest thing to a precedent-setting decision that open source has.

The broader ecosystem is wrestling with hard questions. Who owns the copyright on AI-generated code? If an LLM trained on GPL-licensed code produces output that resembles it, is that a license violation? What happens when AI-generated low-quality pull requests overwhelm volunteer maintainers?

The kernel’s answer sidesteps the thorny IP debates entirely by framing this as a question of responsibility, not technology. It doesn’t matter how the code was produced. What matters is that a human reviewed it, understood it, and put their name on it. Tools evolve. The principle that a person stands behind the code they ship does not.

For over 30 years, the Linux kernel has been setting the standard for what “good code” looks like. Its response to AI isn’t tighter regulation or an outright ban — it’s a reaffirmation of the rule that’s always been there. Use whatever tools you want. But when you sign your name to code, you’d better understand it well enough to answer for it. The real question isn’t whether AI can write kernel-quality code. It’s whether you can vouch for it.