The Linux kernel just scrapped its mandatory "Assisted-by" disclosure tag for AI-written patches — and Linus Torvalds called the whole idea of policing tools "utterly stupid." Meanwhile QGIS banned AI code outright in the same week. Only one of these rules can survive contact with reality, and it's the one that puts the human on the hook.

Last week I wrote about whether LTS still makes sense in the age of the AI patch flood. This week, the kernel world moved one step further down the same road and made a decision I want to plant a flag on: at the Maintainers Summit in Prague on October 8, roughly 30 of Linux's top developers reached consensus that the Assisted-by tag — the mandatory disclosure label for AI-assisted patches — had outlived its purpose. The next day, Sasha Levin (stable/LTS co-maintainer, Nvidia) posted a patch to strip the requirement from the kernel documentation. Jonathan Corbet has merged it into docs-next.

The rule was barely a year old. It began as a labeling proposal in July 2025, landed in Documentation/process/coding-assistants.rst with kernel 7.0, and asked anyone who used "any sort of advanced coding tool" to say so in the commit message. It died the way most honesty-box rules die: almost nobody used it. Levin's revised patch came with a number — only about 10% of the 18,533 non-merge commits in Linux 7.3 through -rc7 carried the tag, while actual AI use is almost certainly far higher. People either didn't know about the rule or ignored it, and maintainers rarely asked.

Then Linus showed up with the quote of the week. When Laurent Pinchart objected to dropping the tag, Torvalds replied on LKML with what I consider the definitive statement of the entire AI-coding debate:

"Here's a new rule just for you: don't use compilers for any of your kernel submissions. Because if you can't show that you really understand what the machine is actually doing by writing your code in assembler, then I don't want to see your code contribution."

And the part that matters:

"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's right, and it's not close. The compiler analogy is devastating because it's exact: nobody in the history of computing has ever been asked to disclose which compiler they used, and the reason is that it was never the interesting question. The interesting question was always whether the code is correct, and whether the human who signed it could explain it to you at 3 a.m. when it's on fire.

There's a second, quieter reason the tag died that deserves more attention than it got. Back in July, Christian Brauner put it bluntly: "I find it very irritating that our git history has effectively started to function a bit like a free advertising platform for a bunch of AI companies and their proprietary agents and models." Every Assisted-by: Claude-whatever line was a billboard in the most important git history on earth, unpaid and unasked-for. The honest contributors labeled themselves; the slop merchants never did — as Torvalds himself noted earlier, documentation rules only bind the people who were already going to behave. The tag didn't catch dishonesty. It advertised brands.

So what's left? The two rules that actually do work, and both of them put the human on the hook. First, Signed-off-by stays: AI agents must never add a sign-off, and only the human submitter certifies the Developer Certificate of Origin — reviewing all AI-generated code, checking the license, taking full responsibility. Second, under Levin's new text, developers describe how they used AI tools in the patch cover letter, where it might actually help a reviewer, instead of stamping a label on every commit. Transparency where it's useful; accountability where it counts.

Linus isn't arguing from the sidelines here, which makes the position harder to dismiss. Around the summit he posted a patch series that speeds up page-cache reads by marking hot folios — the branch was literally named noref-filemap-read-with-llm, and the commit message credits Claude Code with the code, the tests, the review, and a first draft of the message. Reviewers then found a race condition in it. I'd call that the policy working exactly as designed: the patch went out under a human's name, other humans read it, and the bug got caught in review. Nobody needed a tag to know where to look. They reviewed the code like any other patch.

Now the plot twist. In the same week, QGIS went the opposite direction. Its AI tool-use policy, QEP 408 version 2.0, approved October 7, says plainly: "No LLM, AI or agent assisted code contributions are allowed in the qgis/qgis repository," with code reversion and contributor-rights sanctions for violations. And I understand why. Under their old disclose-and-label rule, a reviewer estimated about 50 PRs got the AI label and roughly 40 of them were closed unmerged — 40 rejections that volunteers still had to read first. "The submitter owns it" means nothing when the submitter is a drive-by account that will never come back to own anything.

Here's my honest opinion, and it's two-sided. QGIS's ban is the rational choice for a volunteer-run project drowning in drive-by slop with no review bench deep enough to absorb it. But it's unenforceable theater in the long run: you cannot reliably tell good LLM-assisted code from good human code, so a ban only catches the sloppy stuff — and sloppy stuff was already rejectable on quality grounds. The people who obey the ban are exactly the careful contributors you wanted to keep.

The kernel can afford Linus's rule for one reason: its review culture has consequences. Get a reputation for shipping unreviewed garbage on LKML and your patches stop getting read. That feedback loop is thirty years of accumulated social infrastructure, and "you own every line" works because owning it has teeth. Most projects copying the kernel's rule into their CONTRIBUTING.md will skip the part that makes it work — the cheap right to say no, quickly, to anything that looks unreviewed.

My stated position, for the record: police understanding, not tools. The tag was process theater — a label that made rule-makers feel better while doing nothing about the firehose. The only questions that have ever mattered about a contribution are: can the submitter explain it, will they stick around for review, and do they own it when it breaks? If the answer to all three is yes, I don't care whether a model, a compiler, or a magic crystal wrote the diff. And if the answer is no, no tag in the world was ever going to save you.

The firehose isn't going away. Last week I argued that stability was never about the age of the code — it was about the discipline of the people maintaining it. This week the kernel said the quiet part about tools out loud: discipline is a property of humans, not of labels. The tag is gone. The sign-off remains. As it should be.

Sources