DEV Community

Cover image for Linus Torvalds Calls Rules That Police AI Tools 'Utterly Stupid'. Here's Linux's Rule Instead
Alan West
Alan West

Posted on Originally published at blog.authon.dev

Linus Torvalds Calls Rules That Police AI Tools 'Utterly Stupid'. Here's Linux's Rule Instead

#linux #ai #opensource #discuss

The Linux kernel is about to drop the Assisted-by tag it asks contributors to put on AI-assisted commits. Linus Torvalds backs the change, and when a developer pushed back on LKML he called rules that police your tools "UTTERLY STUPID". By his logic, banning AI-written code outright is the same mistake. Days earlier, QGIS went the other way and banned AI-assisted code from its main repository.

Two serious open source projects looked at the same flood of LLM patches and wrote opposite rules. I think the kernel's rule is better, and I'd copy it into any project's CONTRIBUTING.md. But most projects that copy it will skip the part that makes it work, so there's a paste-ready version further down.

What Linus Torvalds actually said about AI code

Some background first, because the headlines blurred it.

Since Linux 7.0 the kernel's AI coding assistants guide has asked developers to add an Assisted-by tag to commits made with LLM help. At the Maintainers Summit in Prague on October 8, 2026, a majority of the roughly 30 invited developers backed dropping that tag. On October 9 Sasha Levin (stable/LTS co-maintainer, Nvidia) posted a patch to remove the requirement. His revised version on October 13 came with a number: only about 10% of the 18,533 non-merge commits in Linux 7.3 through -rc7 carried the tag, and heise says actual AI use is much higher. People either didn't know the rule or ignored it, and maintainers rarely asked. (heise)

Laurent Pinchart objected to dropping the tag. Torvalds replied on LKML on October 13:

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.

Then he said what he does expect:

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 also threw in "you had better not use an editor to write that commit message either", which is pure Linus. Jonathan Corbet has merged Levin's patch into docs-next; at the time of writing it hasn't hit mainline. Under the new text, developers describe how they used AI tools in the patch cover letter instead of tagging each commit, so maintainers still get some transparency, just not a label on every commit. (heise, TNW)

The sign-off rule stays, and that's the one I care about. The kernel guide spells it out: "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)." The human who signs off is responsible for reviewing all AI-generated code, checking licensing, and "taking full responsibility for the contribution."

So the kernel ends up with no ban and no per-commit tag. A human signs every patch and owns it.

Torvalds wrote kernel patches with Claude Code

Torvalds isn't arguing from the sidelines, which makes this harder to dismiss. Around the summit he posted a short patch series that speeds up page cache reads by marking hot folios, so reads can skip taking a folio reference. The commit message credits Claude Code, working under his direction, with the code, the test programs, the review and a first draft of the commit message, and the branch is literally named noref-filemap-read-with-llm (It's FOSS). With eight threads reading the same cached file, throughput went from about 10 million reads per second to 30 to 33 million on his laptop, with some security mitigations disabled (Linuxiac).

Review then found a race condition in it (LWN), and I'd call that the policy working. The patch went out under a human's name and other humans read it and caught the bug in review. Nobody needed a tag to know where to look; they reviewed the code like any other patch from Linus.

Why QGIS banned AI code instead

QGIS's QEP 408, "AI tool use policy" started in January 2026 as a disclosure-based policy by Even Rouault. Version 2.0, dated September 24, says:

No LLM, AI or agent assisted code contributions are allowed in the https://github.com/qgis/qgis repository.

Break it and "you will be subject to code reversion and contributor rights sanctioning." It was approved on October 7.

Before you laugh at that, look at why. Under the old disclose-and-label rule, a reviewer in the discussion estimated about 50 PRs got the AI label and roughly 40 of them were closed unmerged (remio; that's an estimate from the thread, not an audit). That's 40 rejections someone had to read first. "The submitter owns it" means nothing to a volunteer maintainer when the submitter is a drive-by account that will never come back to own anything.

Torvalds conceded as much at Open Source Summit Europe in Prague, saying AI is improving the code base but "is also stressing maintainers out to the point that it's a problem." (TNW)

Ban vs sign-off: the two policies side by side

Linux kernel QGIS (QEP 408 v2.0)
AI-written code allowed Yes No, in qgis/qgis
Disclosure required Assisted-by tag dropped in docs-next; AI use goes in the cover letter Moot
Who is accountable Human who adds Signed-off-by Contributor, via sanctions
Enforcement Normal review, DCO Reversion, rights sanctions
Can it be detected? Doesn't need to be Not reliably

That last row is where the ban falls apart. You can't 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 it are the careful contributors you wanted to keep.

But the kernel has something QGIS doesn't: a deep subsystem maintainer hierarchy and a sign-off culture that's been enforced since the SCO days. "You own it" works there because owning it has consequences. Get a reputation for unreviewed garbage on LKML and your patches stop getting read.

An AI policy for your CONTRIBUTING.md (the part most projects skip)

If you copy the kernel's rule into a five-maintainer repo and stop there, you get the QGIS problem. You need the accountability and you need a cheap way to say no. So here's what I'd paste into CONTRIBUTING.md:

## Tools, including AI

Use whatever tools you like: compilers, linters, IDE completion, LLMs, agents.
We don't ban tools and we don't require you to label them. If saying how
you used one would help the reviewer, put it in the PR description.

What we require:

1. A human signs off. Every commit needs `Signed-off-by:` from a real
   person (`git commit -s`), certifying the DCO (https://developercertificate.org/).
   Tools and agents must never add a sign-off.
2. You understand every line. If a reviewer asks why a line exists, "the
   model wrote it" is not an answer. You must be able to explain, test and
   fix it yourself.
3. You checked the licence. You are certifying the code can be submitted
   under this project's licence, whatever generated it.
4. You stick around. Respond to review. Unattended PRs are closed after
   14 days.
5. We can say no without a debate. Maintainers may close any PR that looks
   unreviewed by its author (huge unexplained diffs, invented APIs, tests that
   don't test anything) without a line-by-line review. Repeat offenders get
   blocked.
Enter fullscreen mode Exit fullscreen mode

Point 5 does most of the work. It moves the review cost back onto the submitter, which is what QGIS was really after with the ban. You get to the same outcome without pretending you can detect which tool someone used.

Enforcing point 1 is cheap. A CI step like this fails any PR with an unsigned commit:

for c in $(git rev-list origin/main..HEAD --no-merges); do
  git log -1 --format=%B "$c" | grep -q '^Signed-off-by: ' \
    || { echo "missing Signed-off-by: $c"; exit 1; }
done
Enter fullscreen mode Exit fullscreen mode

On GitHub Actions, check out with fetch-depth: 0 so origin/main and the full PR history are there. Or install the DCO GitHub app and skip the script.

Is "you own every line" enough?

On its own, no. The Lobsters thread argued about this for two days. One commenter said verifying LLM output "is more or less as time consuming as writing the code myself." Another described colleagues who say "well Claude says..." and push huge diffs they don't understand. Both complaints are real, and a Signed-off-by line doesn't fix either of them.

Still, I think banning the tool aims at the wrong thing. People were sending code they didn't understand long before LLMs, copying it from Stack Overflow, and Linus's rule goes after that directly. Small projects just need to bolt on the right to close PRs quickly.

So what would you actually enforce on your repo: a QGIS-style ban, or make the submitter own every line? And if you maintain something, has the "you own it" approach survived your first week of agent-generated PRs?

Sources

Top comments (0)