Linux kernel moves to drop its AI ‘Assisted-by’ tag, and Torvalds calls tool bans ‘utterly stupid’

What is changing in the kernel’s AI rules?

The Linux kernel is about to stop asking contributors to confess when an AI model helped them. On 9 October 2026 Sasha Levin posted a two-line patch description to the kernel mailing list: “The Maintainers Summit reached consensus to deprecate the Assisted-by tag. Remove the documentation requiring it.” The diff touches four files, deleting 51 lines and adding one.

It removes the Attribution section of the kernel’s guide for AI coding assistants, which says contributions “should include an Assisted-by tag.” It removes the “Using Assisted-by:” section of the main patch-submission guide, which warns that failing to add the tag “may impede the acceptance of your work,” along with its Italian translation. It strips the tag’s special handling from checkpatch.pl, the script maintainers use to check patch formatting. And it edits the step-by-step procedure for AI tools that hunt for bugs, so the instruction “add an Assisted-by tag” disappears from the line that tells them to commit a fix.

The change is not yet in effect. When Laurent Pinchart asked Levin to explain the rationale in the commit message, Levin replied that he would withdraw the patch until LWN’s report on the summit was published, and explained that the topic “wasn’t even on the schedule”: Jonathan Corbet, who maintains the kernel’s documentation, asked whether anyone still found the tag useful, “no one really voiced a strong opinion in favor,” so they agreed to send a patch. On 15 October the guide in the mainline tree still contained the Assisted-by section.

Where the Assisted-by tag came from

The rule is less than a year old. Levin’s December 2025 commit adding AI coding-assistant documentation set out guidance on licensing, Signed-off-by requirements and an attribution format, “per the consensus reached at the 2025 Maintainers Summit,” and pointed AI tools to the file so they could parse and follow the community’s rules. According to The Register, the labelling proposal first took shape in July 2025 and became part of the documentation in January 2026.

The tag was already trimmed once. On 1 July 2026 Christian Brauner simplified the attribution rule, writing that requiring contributors to name specific models “provides free advertising to proprietary software companies while adding little or no useful information.” Since then the format has been “Assisted-by: LLM,” optionally followed by specialised analysis tools such as coccinelle, sparse, smatch or clang-tidy. Basic tools such as git, gcc, make and editors were never meant to be listed.

In August a separate change by Willy Tarreau added a procedure for AI-driven bug hunting, because, in his words, the quality of AI bug reports was “still lacking a lot.” It tells tools to record the commit they tested, write the fix in the same session that found the bug, build and test it, and leave the Signed-off-by line to a human. That procedure stays; only its mention of the tag goes.

What stays the same for AI-assisted patches

Dropping the label does not loosen the kernel’s legal rules for AI help. The coding-assistants guide still says AI agents “MUST NOT add Signed-off-by tags,” because only a human can certify the Developer Certificate of Origin, the statement that a contributor has the right to submit the code under the kernel’s licence. The human submitter remains responsible for reviewing all AI-generated code, checking licence compliance, adding their own sign-off and taking full responsibility for the contribution.

Code must still be compatible with GPL-2.0-only and carry the right SPDX licence identifiers. Maintainers keep the power they have always had to reject a patch for any reason. What disappears is the expectation that a contributor announces which kind of tool was involved, and the warning that leaving the tag off could count against a submission.

Why maintainers say the tag failed

Senior maintainers who backed the patch say the tag simply did not work. Greg Kroah-Hartman, whose July post other developers cited as the earlier consensus, wrote that he had changed his mind: “it didn’t work out at all and maintainers are really annoyed by it so let’s just drop it and focus on the content of the patch itself (and push back on _ANYTHING_ you feel is wrong).”

Kees Cook gave the patch a Reviewed-by and said the tag had become “as redundant as specifying what editor I use.” He explained that he uses an LLM “constantly for almost all aspects” of his development work, so under the old rule every one of his patches would carry the tag, and that it was meaningless as a signal because “it’s the human wielding it that matters.” The Register reported that Jeff Layton of Red Hat had made a similar case: not everyone follows the rule, it advertises proprietary model vendors, and it is not clear why the project collects the information at all.

Lorenzo Stoakes acked the change while conceding the tag had helped reviewers push back. “The only long-term strategy for slop is to aggressively ignore it,” he wrote. “What kills the project is having 1,000 slop submissions that 2 or 3 people have to do something with.”

The case for keeping some disclosure

Not everyone agreed. Pinchart, a kernel developer and founder of Ideas on Board, said the absence of a tag was the useful part: it let him ask a submitter whether they had forgotten it, and in many cases they never replied. “I’m not happy removing the tag without adding another mechanism for required disclosure,” he wrote, adding that he had proposed putting the disclosure in a patch series’ cover letter instead of the git history, an idea few people supported. He pointed to Mesa, the open-source graphics stack, which requires LLM-generated code to come with a human-written commit message and human-written code comments.

Steven Rostedt, who was not at the summit, objected that policy changes should be argued on the mailing list rather than in LWN articles, and said he would like a “Vibe-coded-with:” tag. When he runs git blame to ask an author why they made a change, he wrote, he would not expect much of an answer from someone who only prompted a model. Krzysztof Kozlowski asked for the summit’s arguments to be written down, since the patch reverses a consensus reached on the list in July, and Randy Dunlap said he still agreed with that July position. Jori Koolstra floated requiring newcomers to show “proof-of-effort,” such as attending conferences or being vouched for; Pinchart and others replied that this would shut out people who cannot afford or reach those events.

What Torvalds wrote

Torvalds answered Pinchart directly on 13 October. “What you are about is something entirely different,” he wrote. “It has nothing to do with ‘expectations’, and it has everything to do with your hangups. I don’t understand this whole idiotic concept of ‘don’t use AI for X’.”

He then proposed mock rules: no compilers, because a contributor who cannot write the code in assembler clearly does not understand what the machine is doing, and no editors for commit messages, because they make it easy to backspace and hide typing mistakes. “Do you not see how UTTERLY STUPID those kinds of rules would be?” he asked. “So no. We’re not going to make stupid rules that say ‘you can’t use tools for X’.”

His own expectation, he wrote, is that people do their best and understand what they are doing, and “that understanding has very little to do with what tools they use.” He ended: “the people I respect and call intelligent are not the ones that shy away from using new and interesting tools.” The message came days after Torvalds posted his own Claude Code-assisted page-cache series.

What happens next

Levin has said he will resend the patch with a fuller explanation, and Kroah-Hartman agreed the changelog needs to describe what he called a “change in policy.” LWN’s report on the 2026 Maintainers Summit is now published, though it is available only to subscribers for now. Once the documentation change is merged, contributors will no longer be asked to add Assisted-by, and checkpatch.pl will stop treating it as a special tag.

For maintainers, the debate moves from labels to review load. Posters in the thread described dealing with low-effort, model-generated submissions, a problem that tools such as the Sashiko review system shown at LPC 2026 try to address, and that a Harvard study of coding agents also found: agents produce more code, but review becomes the bottleneck. The kernel’s answer, for now, is that a patch is judged on its content, and the person who signs it answers for it.