Linux Kernel Plans to Drop the "Assisted-by" AI Tag: What Is Verified

Linux kernel developers plan to drop the requirement that AI-assisted patches carry an "Assisted-by" tag, according to a Phoronix report that reached the Hacker News front page today. A Hacker News submission titled "Linux kernel dropping Assisted-by tag" links a kernel mailing list thread whose address indicates a patch from Sasha Levin dated October 9, 2026. That is the extent of what we can confirm: we were unable to load either page's full text, so this post separates what the kernel's own documentation says today from what is reported about the plan.

If you maintain an open-source project, or you use AI tools to write patches, this is worth understanding because the kernel's rules have become a template other projects copy.

Claimed vs verified

What does the kernel require today?

The kernel's AI Coding Assistants document gives three core instructions. AI tools helping with kernel development should follow the standard development process. All contributions must meet the kernel's licensing requirements. And attribution matters: contributions should include an Assisted-by tag in the format AGENT_NAME:MODEL_VERSION followed by optional specialized analysis tools, with basic development tools such as git, gcc, make and editors left off the list.

The same document draws a hard line on legal accountability: AI agents must not add Signed-off-by tags, because only humans can certify the Developer Certificate of Origin (DCO). The human submitter reviews what the AI produced, confirms the licensing, and signs off under their own name.

The document also contains a workflow for AI-found bugs. An assistant that finds a bug must read the process documentation, try to build a reproducer for any non-trivial bug, write a fix rather than only a report, build and verify it, avoid new build warnings, pass checkpatch.pl, and say explicitly what could not be done. The stated reason is blunt: maintainers currently waste too much time on unverified reports and untested fixes. The assistant must never send anything itself; the human reporter reviews first.

Notice what that means for the proposal: the tag is only one piece of a larger policy. Removing it would not, by itself, touch the DCO rule or the reproducer rules.

How did the tag get there?

According to It's FOSS, Sasha Levin pushed for written consensus at the 2025 Maintainers Summit. What came out was human accountability for patches being non-negotiable, purely machine-generated submissions not being welcome, and tool use being disclosed. The AI Coding Assistants document shipped with Linux 7.0. The same report says Linus Torvalds was initially not convinced a dedicated tag was needed and suggested the changelog body could do the job, but the community settled on the tag anyway.

The original submission, preserved on patchew, also touched the kernel's checkpatch.pl script so that it warns when an Assisted-by line does not match the expected format. If the tag goes away, that check presumably goes too, though we have not seen the new patch to confirm.

One web source we found says the format was trimmed on July 1, 2026 to drop the model name. We could not verify that against the kernel tree, so we treat it as unconfirmed.

Why might developers want to drop it?

We cannot say what Levin's patch argues, and we will not guess at its stated reasoning. The Hacker News thread gives a hint of one common sentiment. A commenter, prologic, wrote that they are sick of seeing Co-Authored-By: Claude lines and want a PR to explain why something was done, not who or what helped (comment). That is one person's view on one thread with a single reply, not evidence about the kernel list.

There are reasonable arguments on both sides, which are worth separating from the facts:

• For keeping a tag: reviewers can calibrate scrutiny, researchers can measure AI's role, and it gives a place to record tooling such as coccinelle or sparse.
• For dropping it: tools differ in how much they contribute (autocomplete versus an agent that wrote the whole patch), a tag cannot capture that, and tag compliance is self-reported and unenforceable.
• Either way: the Signed-off-by line puts a named human on the hook, which is what the DCO protects.

What does this mean for AI-assisted contributors?

Practically, until a change is merged, follow the document as written. If you use an AI tool on a kernel patch, put the Assisted-by line in, never let an agent sign off, and test the fix. If the tag is dropped, expect maintainers to still ask whether and how you used AI during review, and expect low-effort AI patches to be rejected on quality grounds regardless of tags.

Other projects are watching because policy has fractured. QGIS banned AI-assisted contributions, COSMIC desktop banned AI-generated code, OpenJDK adopted a ban, and GCC set out its own LLM policy. The kernel took the disclosure route instead. It's FOSS notes that Gentoo banned AI-generated contributions in 2024 and NetBSD treats LLM-written code as tainted code requiring written approval.

The kernel is also not an AI-hostile project. Torvalds himself has used Claude Code to produce a patch, which we covered in Torvalds' page cache patch, and discussed his own limits in what he says he is bad at. The tension is between openness to AI help and the cost it imposes on reviewers, a theme also in our piece on the verification tax of checking AI output.

Timeline: how kernel AI policy got here

The pattern matters. The tag was never the heart of the policy; it was the visible, easily checked part. Kroah-Hartman's fuzzing workflow shows the intended model: the AI surfaces candidate issues, an experienced human decides which are real, writes the fix, and takes responsibility. That is a process rule, and no tag enforces it.

What are people asking?

Does this mean the kernel is relaxing on AI? We cannot tell from a headline. Dropping a labeling requirement is different from dropping the human-accountability, licensing and testing rules, all of which sit in other parts of the same document. Until the patch text is read, "relaxing" is an interpretation, not a fact.

Will AI-written patches now be hidden? Possibly easier to hide, since a tag is voluntary in practice, but reviewers already judge patches on content. The kernel has long relied on maintainers recognizing low-quality submissions regardless of how they were produced.

Why would a project want an AI tag at all? To track adoption, to let reviewers adjust scrutiny, and to support later research on AI-assisted defect rates. The cost is friction, inconsistent compliance, and a label that cannot distinguish a one-line autocomplete from a fully agent-written change.

What should a company shipping kernel patches do? Keep internal records of which tools touched which patches, whatever upstream decides. If a licensing question or a bug traced to AI output comes up later, your own audit trail is what you will need, not an upstream tag.

How to check this yourself

1. Open the lore.kernel.org thread linked above and read Levin's cover text and the replies from maintainers.
2. Compare the current Documentation/process/coding-assistants.rst in the kernel tree against the version in your release.
3. Watch for whether the change lands in a maintainer's tree and in a release candidate. A patch on the list is a proposal until then.
4. If you build agent workflows, treat attribution as your own audit trail even if upstream stops requiring it. For teams running coding agents, AgentBeam from the explainx.ai team stops AI agents before they take dangerous actions.

We will update this post when the patch text and its fate are confirmed.

Related reading

• QGIS bans AI-assisted contributions
• COSMIC desktop bans AI-generated code
• OpenJDK's AI-generated code ban
• GCC's AI contributions policy
• Torvalds and the Claude Code page cache patch
• Torvalds on AI, vibe coding and kernel review

Details reflect what we could verify on October 13, 2026; the proposal may change.