Soursen

Independent writing on infrastructure, AI, security and crypto.

Linux & open source

Linux & open source

The Linux Kernel Just Dropped Its AI Disclosure Tag, and the Fight Over It Says More Than the…

At the Maintainer Summit in Prague, the people who run the Linux kernel reached a rough consensus to deprecate the Assisted-by tag, the little line in a commit that says AI helped write it. I went through who proposed it, the real numbers behind it, and the argument it set off, including Linus Torvalds calling the whole idea of AI disclosure rules utterly stupid, because the kernel is quietly becoming one of the most AI touched projects in open source.

Last verified Also on Medium

Banner for “The Linux Kernel Just Dropped Its AI Disclosure Tag, and the Fight Over It Says More Than the…”
Banner for “The Linux Kernel Just Dropped Its AI Disclosure Tag, and the Fight Over It Says More Than the…”
On this page
  1. What the tag was supposed to do
  2. Where the tag came from in the first place
  3. The 3 reasons it is going away
  4. The people who wanted to keep it
  5. Then Torvalds ended the discussion
  6. How much the ground has already shifted
  7. The kernel is already an AI heavy project
  8. What this actually changes
  9. Sources and further reading

For about a year, a Linux kernel commit could carry a small line called Assisted-by, a tag that said AI was used somewhere in making that change. It was meant to be a signal, a way to know a model had a hand in the code. On 8 October 2026, at the Maintainer Summit in Prague, a room of roughly 30 senior kernel developers reached a rough consensus to get rid of it. The next day, Sasha Levin, an Nvidia engineer who co-maintains the stable and long term kernels, sent the patch to deprecate the tag and remove the documentation requiring it. Jonathan Corbet queued the change into the docs branch. The tag is on its way out.

The decision itself is small. The argument around it is the interesting part, because it exposes how the kernel’s leadership actually thinks about AI, and how much AI is already in there.

What the tag was supposed to do

The idea behind Assisted-by was data. If you want to know how much AI is flowing into the kernel, which developers lean on it, how that changes over time, a tag in the commit gives you a record you can count. Sasha Levin was in favor of it originally for exactly that reason, to track how things are changing, not to police anyone. A commit with the tag told you a model helped. A commit without it told you, in theory, that none did.

That theory broke down fast, and the reasons it broke are why the tag is being dropped.

Where the tag came from in the first place

The Assisted-by tag was written into kernel policy less than a year ago. On 23 December 2025, a document called coding-assistants.rst, about 59 lines, was committed to the kernel tree, approved by documentation maintainer Jonathan Corbet and built on consensus reached at the 2025 Maintainer Summit. Sasha Levin championed it, and the naming went through a few rounds before it stuck. His first RFC in July 2025 floated a Co-developed-by tag, then after suggestions from David Hildenbrand and Konstantin Ryabitsev it became Assisted-by. The kernel’s own patch checker, checkpatch.pl, at first rejected the new tag, and Levin had to send a second version to make the tooling accept it.

The policy did more than name a tag. It set the rules that still hold even with the tag going away. Only a human can add the Signed-off-by line, because that line certifies the Developer Certificate of Origin, the legal statement that you have the right to contribute this code. An AI agent cannot sign off, full stop. The human who submits AI assisted code reviews it, checks it is compatible with the kernel’s GPL-2.0-only license, adds their own Signed-off-by, and takes full accountability for it. The tag format itself was specific, AGENT_NAME:MODEL_VERSION followed by any static analysis tools in brackets, with the policy’s own example reading Claude:claude-3-opus coccinelle sparse. Ordinary tools like git, gcc, and your editor were never meant to be listed. Even in that original policy, Levin said enforcement was deliberately avoided. The tag worked as a forensic record for spotting bug patterns by model, and skipping it carried no penalty.

The 3 reasons it is going away

Levin’s own analysis is the clearest look at the problem. He went through 18,533 regular commits across a recent development cycle and found that about 10% carried the Assisted-by tag. He is the first to say that figure almost certainly understates real AI use, because the tag only catches the people who bothered to add it.

That gap is the whole issue, and it comes down to 3 things. First, plenty of developers do not know the rule exists, so they never add the tag even when a model helped. Second, some developers know and leave it off on purpose. Third, maintainers rarely chase a missing tag, so there is no real enforcement. Put those together and a commit without the tag tells you almost nothing. The absence could mean no AI, or it could mean someone who did not know, forgot, or chose not to say. A tag that cannot be trusted when it is missing is not giving you clean data, it is giving you a floor and a shrug.

A second objection has nothing to do with accuracy. The tag often named a specific commercial product, the model or the agent used. A lot of people were uncomfortable turning kernel commit history into free advertising for proprietary AI companies. Greg Kroah-Hartman’s position captured the compromise, make up a generic name if you have to, all he wanted was the signal that a model was involved so he could review the change with that in mind, and if someone lied about it, that was on them.

Figure 1. Why the Assisted-by tag stopped being useful. Across 18,533 commits in a recent cycle, about 10% carried the tag, and the missing 90% is a mix of no AI, developers who did not know the rule, and developers who left it off, so the absence of a tag means little.

Figure 1. Why the Assisted-by tag stopped being useful. Across 18,533 commits in a recent cycle, about 10% carried the tag, and the missing 90% is a mix of no AI, developers who did not know the rule, and developers who left it off, so the absence of a tag means little. Source: Author chart based on Sasha Levin’s kernel commit analysis

The people who wanted to keep it

The consensus was rough, not unanimous, and the pushback is worth hearing because it is not coming from people who hate AI. Laurent Pinchart, one of the more AI skeptical voices among the maintainers, made a practical point. For him the useful thing was the absence of a tag, because it gave him a reason to ask a submitter whether they had forgotten to add it, and in many cases the submitter simply went quiet. Someone who sends a patch that looks machine generated, gets asked to tag it, and then ghosts the reviewer has told you something. Pinchart did not want the tag removed without some other required disclosure in its place, otherwise submitters just push back on the question and there is nothing to point to.

Pinchart raised a second idea that cuts deeper. Requiring a human written commit message, he argued, is a cheap filter. Most LLM generated commit messages are easy to spot today because they run more verbose than a person would bother with, and asking for a human written message is a quick way to ignore patches from what he called meat proxies, people passing a model’s output through as their own. He also named the obvious counterargument himself and answered it. When someone says the tech will improve and the tells will vanish, his reply was that the process can change when that happens, there is no need to rewrite the rules now for a problem that does not exist yet.

Kees Cook, another longtime maintainer, agreed the tag was unenforceable, and then said something more honest than most of the thread. His own recent commit logs, like his code, are a mix of his work and an LLM’s, and he trims and edits and reorganizes until the line between the 2 is gone. He admitted he had already failed a reverse Turing test, assuming a colleague’s genuinely human, genuinely verbose commit messages were AI generated. His read was that the point where you can clearly tell human from model is either here already or arriving fast. Once you cannot reliably tell, a disclosure tag built on the honor system is worth even less.

Then Torvalds ended the discussion

Linus Torvalds does not weigh in on everything, and when he does it tends to settle the direction. On 13 October 2026 he replied to Pinchart on the mailing list, and he was blunt. He said the disclosure argument had nothing to do with expectations and everything to do with people’s hang ups, and he called the whole concept of don’t use AI for this specific thing idiotic.

Then he reached for an analogy. Here is a new rule just for you, he wrote, do not use compilers for any of your kernel submissions, because if you cannot show you really understand what the machine is doing by writing your code in assembly, he did not want to see your contribution. He kept going, and you had better not use an editor to write your commit message either, because an editor lets you backspace and hide the mistakes you made while typing. He was being facetious, obviously. The point underneath was serious. You already do not understand everything the machine does when you use a compiler, and you trust it anyway, so singling out LLMs as the tool that proves you do not know what you are doing makes no sense. The expectation, he said, is that people do their best and understand what they are doing, and that understanding has very little to do with which tools they used.

Figure 2. The kernel’s AI stance, by who holds it. From Torvalds, who committed code built with Claude Code, through pragmatists like Kroah-Hartman and Cook, to skeptics like Pinchart who still want disclosure, no major figure is calling for an outright ban.

Figure 2. The kernel’s AI stance, by who holds it. From Torvalds, who committed code built with Claude Code, through pragmatists like Kroah-Hartman and Cook, to skeptics like Pinchart who still want disclosure, no major figure is calling for an outright ban. Source: Author diagram of kernel maintainer positions, October 2026

This was not an abstract position for Torvalds. A few days earlier he had published a branch where he used an AI coding assistant himself. The series rewrote part of the page cache, the code that handles many threads reading the same file at once, where all those reads were hammering a single shared counter. His 8 patches skip that per read step and let memory leaving the cache wait briefly before reuse so readers can copy safely. On his own laptop, 8 threads reading 1 file went from about 10 million reads a second to between 30 and 33 million, with some protections turned off for the test. The commit credits Claude Code, under his direction, with the code, the test programs, the review, and a first draft of the message. Torvalds is not claiming the model did the engineering. He directed it, ran the measurements himself, and takes responsibility for the result. He has been clear that he still thinks the engineering matters and that a model cannot just do everything on its own.

How much the ground has already shifted

Go back to 2023, about a year after ChatGPT landed, and Torvalds was far more reserved. In an on stage interview with Dirk Hohndel, he described large language models as autocorrect on steroids, software that predicts the next likely word and extrapolates, not very intelligent in his view. He expected LLM written code would show up in kernel submissions, maybe already was on a small scale, and he was not especially worried, because automation had always helped people write code. His hope was modest, that AI might catch the obvious stupid bugs, the ones that do not need any higher intelligence to spot, and flag patterns that look off so a human can say that was not what I meant. Asked about hallucinations, he said he saw the bugs humans produce every day, so he was not losing sleep over the machine’s mistakes.

The distance between that 2023 answer and the October 2026 commit is the real story. In 2023 the tech produced boilerplate and images with 6 fingers, and anyone could tell at a glance what was machine made. It did not plateau. By late 2026 the top level maintainer of the Linux kernel is shipping AI assisted performance work and defending the right to use the tools in public.

The kernel is already an AI heavy project

If you are anti AI and you run Linux, the numbers are hard to get around. By the kernel’s own rough count, more than 1 in 10 recent commits carried an AI tag, and the honest reading is that the true share is higher and climbing every month. That is not 10% of code accepted into the kernel, it is a floor on the new commits being sent in with AI somewhere in the process. Even if every maintainer stopped using these tools today, the AI assisted code already merged is not coming back out.

AI is also already doing review work, not just writing code. A tool called Sashiko, built by Google engineers for agentic review of kernel changes and running on Gemini and other models, gave its status update at the Linux Plumbers Conference in late 2026. In under a year it had run more than 191,000 patch reviews across 99 mailing lists, made over 19 million autonomous Git lookups, and drawn more than 7,600 replies from over 1,100 kernel developers. This year alone, 1,277 commits merged into the mainline kernel cite Sashiko, and 463 Linux kernel CVEs, security vulnerabilities, cite it as well. A machine is reading kernel patches at a scale no human team could match and catching real security bugs in the process.

Figure 3. Sashiko, an AI code review tool built by Google engineers, in under 1 year on the kernel mailing lists. More than 191,000 patch reviews, over 19 million automated lookups, and 463 kernel CVEs this year that cite it.

Figure 3. Sashiko, an AI code review tool built by Google engineers, in under 1 year on the kernel mailing lists. More than 191,000 patch reviews, over 19 million automated lookups, and 463 kernel CVEs this year that cite it. Source: Author chart based on Linux Plumbers Conference metrics, 2026

Some subsystems will say no AI, we do not want it near our code, and the leadership has made clear that is fine, a maintainer can set that rule for their own corner. The project as a whole is going the other way. Torvalds controls the top of the tree, his position is not ambiguous, and as long as he runs the kernel you will see AI used in it. The leadership has effectively decided the benefits outweigh the costs, and that the slop a model produces is no worse than the slop people produce on their own.

What this actually changes

Dropping the Assisted-by tag does not make the kernel more or less AI driven than it already is. It removes a signal that was never reliable and replaces it, for now, with an informal convention of explaining AI use in the cover letter of a patch series, outside the permanent commit record. That is less visible and less countable, which is exactly what Pinchart was unhappy about. Responsibility for the code still sits with the human who submits it, and an AI agent still cannot sign off on a patch in its own name.

The real thing to watch is whether the kernel keeps any durable way to measure how much of itself is being written with AI, because the one experiment it ran, voluntary tagging, just got called a failure by the person who proposed it. If you contribute to the kernel, read the subsystem’s own stance before you send anything a model helped you write, because the top of the tree and an individual maintainer can want very different things.

Sources and further reading

Sources

No sources have been filed for this piece yet.

Search