Linux Kernel Draws a Line on AI-Generated Code

A nineteen-line patch shouldn't start a war. But when that patch turned out to be AI-generated and nobody mentioned it until after the fact, the Linux kernel development community spent six months sorting out what that means.

The patch itself was unremarkable—a hash table replacement, the kind of refactoring that happens regularly in any large codebase. Clean enough that reviewers approved it. Clean enough that it merged into kernel 6.15. The problem showed up later, when developer Sasha Levin gave a talk at an open-source summit about using large language models for kernel development and pointed to that patch as an example.

The reviewers who'd signed off on the code were baffled. As one put it in the ensuing mailing list discussion: "I am baffled that he apparently saw no need to disclose this when he was posting the patch."

What followed was what you'd expect when you combine transparency concerns, copyright questions, and engineers who take code quality seriously. The Linux Kernel Mailing List lit up.

The Performance Regression Nobody Caught

The patch had a bug. A small one—it removed a "read_mostly" optimization flag that the reviewers assumed was included in the new function definition. It wasn't. Performance regressed slightly. Someone fixed it. The world kept turning.

But several reviewers said they would have caught the bug if they'd known the code was AI-generated. "It would have been nice if Sasha mentioned it was completely generated by an LLM because I would have taken a deeper look at it," one wrote.

This strikes me as an odd position. The entire purpose of code review is to put on your thinking cap and evaluate whether the code does what it claims to do. If your review rigor depends on knowing the author's methodology rather than examining the code itself, you're reviewing the wrong thing.

A nineteen-line change is a nineteen-line change. Either you verify that it works or you don't. The "read_mostly" flag was visible in the diff. Any careful reviewer should have noticed its removal, regardless of whether the patch came from a human, an LLM, or a very industrious parrot with a keyboard.

The Rules They Settled On

After half a year of debate, the kernel team published new guidelines. They're straightforward:

First, disclose AI use. If you used an LLM to generate code, say so.

Second, AI agents cannot add "Signed-off-by" tags. They can add "Assisted-by" tags, but a human must take responsibility. As the document states: "Any line of code that hits the potential to become merged into the kernel, somebody has to say, 'Hey, I own this code. Hey, I fully understand it. I've done 100% of the review and I say this code is good.'"

This is reasonable. It establishes a clear chain of accountability. It acknowledges that AI tools exist and can be useful while ensuring that a human being who understands the code vouches for it.

But these rules are almost certainly temporary.

The Learning Problem

Buried in the discussion is a more interesting concern than disclosure requirements or liability: "The explicit goal of generating code with LLMs is to make every developer more productive at writing patches, meaning there will be more patches to review and reviewers will be under more pressure. And in the long term, there will be fewer new reviewers because none of the junior developers who outsource their understanding of the code to an LLM will be learning enough to take on that role."

This gets at something real. Junior developers learn by writing code badly, having it reviewed, understanding why it's bad, and writing it better. If the AI writes it for them, what exactly are they learning? How to prompt? That's not nothing, but it's not the same as understanding how a hash table works or why "read_mostly" matters.

The kernel community has always been a training ground. Experienced developers review patches from newcomers, teaching them the standards and practices that keep Linux stable. If AI short-circuits that process, where do the next generation of experienced reviewers come from?

Nobody has a good answer yet.

The Pressure That Won't Stop

The video creator I'm covering here—who runs a developer-focused channel—predicts these guidelines won't last more than a year or two. His reasoning: the volume of incoming patches could increase tenfold as developers lean harder on AI assistance. Reviewers won't be able to keep up. Eventually, someone will argue that AI review tools are better than human reviewers at catching bugs, so why not let them sign off?

I've watched enough technology adoption cycles to know he's probably right about the pressure. Whether Linux yields to it is another question.

Linus Torvalds has never been particularly susceptible to hype. The kernel has maintained remarkably consistent quality standards for three decades precisely because the maintainers refuse to optimize for velocity at the expense of correctness. "I somehow doubt that Linus is gonna allow Linux to be sloppified," the video creator says, "but the pressure from the slop trebuchet, it's intense."

Slop trebuchet is good. I'm stealing that.

What This Actually Tests

The copyright questions are real—Microsoft felt compelled to create a "Customer Copyright Commitment" specifically to indemnify Copilot users against IP claims. The clean-room engineering question is legitimate: if an AI's training data includes copyrighted code, can its output ever truly be clean?

But the more fundamental question is whether software development can maintain quality standards in an environment where generating code becomes trivial and reviewing it remains hard.

As one commenter in the discussion noted: "I think writing code is already the easiest and most enjoyable part of software development. So it seems like the worst part is trying to be automated away."

That's the tension. The part of software development that AI excels at—generating syntactically correct code that solves a well-defined problem—is the part most developers already find straightforward. The hard parts—figuring out what to build, understanding systems deeply enough to make good architectural decisions, reviewing someone else's work with enough care to catch subtle bugs—those remain stubbornly resistant to automation.

The Linux kernel is now a test case. If the most rigorous, most publicly scrutinized open-source project in the world can figure out how to use AI assistance without sacrificing quality or institutional knowledge transfer, that tells us something useful. If it can't, that tells us something too.

Either way, we'll know more in two years than we do now. The kernel developers will make sure we do—that's what five decades of archived mailing list arguments are for.

—Bob Reynolds