Linux drops its AI disclosure tag, Torvalds slams "don't use AI" rules

For most of 2026, the Linux kernel had a small rule about AI. If you used an advanced coding tool to create a patch, you were supposed to add a line to your commit message: Assisted-by. That rule is now gone. On 14 October 2026 kernel documentation maintainer Jonathan Corbet applied a patch that removes the Assisted-by requirement from the kernel's documentation, after the Linux Maintainers Summit agreed it was not working.

The decision would have been a footnote in the kernel's long history if not for one reply. When a developer objected that the project should keep some form of mandatory disclosure, Linus Torvalds answered on the Linux kernel mailing list with a message that quickly spread far beyond the kernel community. "Do you not see how UTTERLY STUPID those kinds of rules would be?" he wrote. His point: the kernel cares whether you understand your code, not which tools helped you write it.

What the Assisted-by tag was

The idea of labelling AI help in kernel patches took shape in July 2025, according to The Register. It became part of the official documentation in January 2026. The text was simple. Contributions made with help from AI tools should include a line in the format `Assisted-by: LLM [TOOL1] [TOOL2]`, where the optional tool names covered specialised analysis tools such as coccinelle, sparse or smatch. Basic development tools like git, gcc, make and editors were explicitly excluded. The documentation on submitting patches went further: if you used any sort of advanced coding tool and left the tag off, that "may impede the acceptance of your work."

The first version of the format was more detailed. A later documentation change, titled "coding-assistants: simplify attribution", reduced it to the plain "Assisted-by: LLM" form, so contributors no longer had to name a specific product.

The reasoning behind the tag made sense at the time. Maintainers review thousands of patches. If they knew a patch came out of a language model, they could look more closely for the typical mistakes such tools make. In July 2026 a first proposal to drop the tag was turned down for exactly that reason: maintainers wanted the signal.

Why the maintainers changed their minds

The tag came back on the agenda at the 2026 Maintainers Summit, which took place on 8 October alongside Open Source Summit Europe in Prague. Kernel developer Sasha Levin, who works at Nvidia, posted the first patch to remove it the next day. It was just two sentences long: "The Maintainers Summit reached consensus to deprecate the Assisted-by Tag. Remove the documentation requiring it."

Other developers asked for the reasoning to be written down, and on 13 October Levin sent a much longer second version. It contains the most interesting number in the whole debate. Roughly 10 percent of the 18,533 non merge commits in Linux 7.3 through rc7 carry an Assisted-by tag, Levin wrote, "while actual LLM use is far more widespread."

In other words, the tag had stopped meaning anything. Some contributors did not know about the rule. Others left the tag off on purpose. Few maintainers ever asked. As Levin put it, the absence of the tag "says nothing about how a patch was made," and for developers who use AI tools for almost everything, its presence says little more. The project had two choices: find a way to enforce the rule or drop it. According to Levin there was "a strong, though not unanimous, consensus in the room to drop it."

Red Hat kernel developer Jeff Layton had earlier summed up the case against the tag in three points, as quoted by The Register. Not everyone follows the policy. The tag "basically serves as free advertising for proprietary LLM companies." And it is not clear why the kernel wants to collect the information in the first place. Even Greg Kroah-Hartman, one of the most senior maintainers, who had argued to keep the tag in July, now supports removing it.

The objection, and the reply that went viral

Not everyone agreed. Laurent Pinchart, a kernel developer and founder of Ideas on Board, said he was "not happy removing the tag without adding another mechanism for required disclosure." He also rejected the argument that the rule should go because it cannot be enforced. "What this is about is setting our expectations, telling what we want and what we don't want," Pinchart wrote. People who cheat have always existed, he argued, and the project will keep rejecting their contributions.

Torvalds answered the same day, in his familiar style. He told Pinchart that his position had "everything to do with your hangups" and nothing to do with expectations. Then he proposed a rule of his own: "don't use compilers for any of your kernel submissions." If you cannot show that you understand what the machine is doing by writing your code in assembler, he went on, he does not want to see your contribution. And you had better not use an editor for the commit message either, because editors make it too easy to hide your typing mistakes.

The sarcasm was the point. "Do you not see how UTTERLY STUPID those kinds of rules would be?" Torvalds asked. "So no. We're not going to make stupid rules that say 'you can't use tools for X'." His actual standard was short and clear: "The kind of expectations I have is that people do their best and I expect people to understand what they are doing. But that understanding has very little to do with what tools they use." He ended with a line that many developers quoted afterwards: "the people I respect and call intelligent are not the ones that shy away from using new and interesting tools."

It is worth being precise here. The tag never banned AI. It only asked people to disclose it. Torvalds was attacking a broader idea, the notion that a project should judge contributors by their tools instead of by their work. Pinchart had asked for disclosure, not a ban, so the reply argued against a stronger position than the one on the table. That is part of why the exchange drew so much attention: it was less about one documentation line and more about how open source should treat AI at all.

What actually changes

The change itself is small and quite technical. Levin's patch removes the Assisted-by sections from two key documents, `coding-assistants.rst` and `submitting-patches.rst`, along with the matching sections in the Italian, Brazilian Portuguese and Traditional Chinese translations. It also removes the handling of the tag from `checkpatch.pl`, the script many developers run before sending a patch. Corbet replied on 14 October: "OK, I have applied this, thanks." The patch sits in the documentation tree and reaches Linus Torvalds' main tree through the normal merge process, so the old text can still be seen in the main tree for a while.

Just as important is what stays. The document `generated-content.rst` still asks contributors to be transparent about tool use, and the patch does not touch it. The Developer Certificate of Origin, the Signed-off-by line in which a contributor certifies that they have the right to submit the code, is unchanged. So is the rule that the submitter takes full responsibility for the patch. Maintainers still want to know how a patch was made, Levin wrote, but the view at the summit was that this belongs in the cover letter, where a developer can explain how tools were used, rather than in a one line tag in the permanent changelog.

So the honest summary is: Linux did not stop caring about AI generated code. It stopped pretending that a voluntary label told reviewers anything useful.

Torvalds has warmed up to AI

The reply did not come out of nowhere. On 9 October, a few days earlier, Torvalds sat on stage at Open Source Summit Europe in Prague with his friend Dirk Hohndel, head of Ericsson Software Technology. As ZDNET reported, he said he used to think AI was "just not very good," and added: "now I'm at the point where I actually really like using AI."

He uses it, he said, "to do the things that I'm bad at." For his guitar pedal hobby project he wanted a modern user interface on a small screen he had already programmed in C. "I don't do Java. I do kernels," he joked. He called vibe coding "a wonderful way to find joy in programming" and liked the idea of AI as a gateway drug for new programmers. But he also drew a line: "I think that you need to be very careful using AI when you're doing something real and important."

Earlier this month we also wrote about how Torvalds used Claude Code to build an experimental page cache optimisation for Linux. The developer who not long ago dismissed much of the AI hype as marketing is now one of the most prominent developers openly using these tools himself.

According to The Next Web, Torvalds also said in Prague that AI tools now find real security bugs in the kernel and are improving the code base, but that they are "stressing maintainers out to the point that it's a problem." About three quarters of the talks at the Maintainers Summit, he said, dealt with making AI tools less stressful. Agentic review systems such as Sashiko now post reviews on the mailing list, and some subsystem maintainers expect patches to have gone through one. "People are jokingly saying that there are bots talking to bots, and it does actually happen," Torvalds said.

Not every project agrees

Linux is taking a pragmatic line, but the open source world is split. The Next Web notes that System76 has banned AI generated content from its COSMIC desktop, and NetBSD has banned AI generated code since 2024. Even among AI tool makers there is no common standard: The Register points out that Claude adds provenance messages to commits by default, while Codex does not.

That inconsistency is part of the problem any disclosure rule faces. If one popular tool labels its work and another does not, and many developers mix several tools in one patch, a tag ends up measuring which tool someone happened to use, not how much of the work they understood.

Why it matters

The Linux kernel is one of the largest and most carefully reviewed software projects in the world. Its rules often become a model for other projects and for companies that build on Linux. By dropping the tag, the kernel is sending a clear message: AI assisted code is normal now, and the old quality bar applies to it like to any other code. You sign off on your patch, you answer for it, and if you cannot explain what it does, it will be rejected, whatever produced it.

For developers, this removes one bit of friction and one source of stigma. For maintainers, it shifts the focus back to what really protects the code: careful review, tests and accountability. The remaining worry is real, though. Maintainers are already overloaded, and AI makes it cheap to send large amounts of plausible looking code. A tag never solved that. Better review tools, and the willingness to reject low quality submissions quickly, might.

Our take

Torvalds' reply was rude, but his core argument is hard to beat. A label that roughly one in ten commits carries, while far more people use AI, is not information. It is noise that gives a false sense of control. Asking contributors to explain their process in the cover letter, and holding them fully responsible for the result, is closer to how good engineering teams already work.

Pinchart's worry also deserves a fair hearing. Clear expectations matter, especially for newcomers who may not know that "the AI wrote it" is no excuse. The kernel still says so in its documentation on generated content. The difference now is that the rule focuses on understanding and responsibility instead of on a checkbox. For a project of this size, that seems like the right trade.

Sources: Linus Torvalds on LKML (13 Oct 2026), patch v2 by Sasha Levin (13 Oct 2026), Jonathan Corbet applies the patch (14 Oct 2026), The Register (14 Oct 2026), The Next Web (16 Oct 2026), ZDNET via Yahoo Tech (9 Oct 2026), PC Gamer (16 Oct 2026).