What Torvalds got right about AI and programmers, and what he left out
On 13 October, kernel developer Laurent Pinchart received a new rule for his patches, courtesy of Linus Torvalds: stop using compilers. Write everything in assembler, or don’t bother sending it. While you are at it, give up your text editor for the commit message too, because the backspace key is a tool that hides your mistakes, and a serious engineer should be able to show them. The rule was sarcasm, delivered in the register that made Torvalds famous, and it has been circulating ever since as the most sensible thing anyone has said about programmers and AI. I think it is a very good paragraph. I also think it is a shorter argument than the situation deserves, and the interesting part is what the email leaves out.

In brief
- Torvalds was answering a debate about the kernel’s Assisted-by tag, not proposing a test of whether contributors can code without help.
- His compiler analogy holds as a principle, because tools are a poor measure of competence, and fails on the mechanics, because compilers are deterministic and language models are not.
- What replaces a ban on tools is a duty to understand, verify and sign for what you submit, the same duty forensic analysts have always had with their own software.
- The tag was unenforceable, but the question behind it, how reviewers decide how hard to look, is still open.
A reply to a tag, not a verdict on talent
The context matters, because several retellings of the exchange compress it into “developers must prove they can code without AI”, which is a different argument from the one in the email. At the start of 2026 the kernel documentation began asking contributors to add an Assisted-by line to any patch written with the help of an AI tool. Jonathan Corbet later added a paragraph to the patch submission guide warning that skipping the tag could get in the way of acceptance. It was never enforced, and by October it looked like a failed experiment: of the 18,533 non-merge commits that went into Linux 7.3 up to its seventh release candidate, only about ten percent carried the tag, even though AI use was believed to be far more widespread.
At the Maintainers Summit in Prague on 8 October the maintainers reportedly reached consensus to deprecate it, and Sasha Levin posted a patch removing the documentation the next day. According to The Next Web, critics inside the thread argued that the tag could not be enforced and amounted to free advertising for LLM vendors. Pinchart objected that without it the project loses a way to state what it expects from contributors, and that is the sentence Torvalds jumped on in his reply.
His answer has three moves. He rejects the whole idea of rules shaped like “don’t use AI for X”. He then runs that logic through two absurd examples, the compiler and the editor, to show that nobody would accept them for any other tool. And he restates the only expectation he has of contributors, which is that they do their best and understand what they are doing, something that has very little to do with which tools produced the text. He closes with a remark about the people he respects and considers intelligent, who are not the ones who “shy away from using new and interesting tools”.
It would be easy to read that as a pose, but he practices it. Speaking at Open Source Summit Europe, also in Prague, he said he used to find AI just not very good and now “I actually really like using AI”, citing real security bugs that these tools now find in the kernel. In the same week he published a patch written with LLM help aimed at a cache contention problem. The man is not defending a principle he avoids using.
The compiler analogy deserves its applause
Every generation of programmers has been told that the previous generation’s tools were the real thing. Assembler programmers looked at compilers the way a vinyl collector looks at streaming. Compiler people looked at garbage collection, then at frameworks, then at the package manager that downloads half the internet before lunch. In each case the tool moved a layer of detail out of the programmer’s head, and the profession got better at the work that remained. Nobody sensible today asks a web developer to prove they can hand-write machine code before touching a pull request.
I started working in 1997, and ai miei tempi the debate over tools was already the wrong debate. The useful question was never whether you had used a debugger, a decompiler or a hex editor, but whether you could explain what had happened. My own field offers the cleanest version of the argument. A forensic examiner who refuses to use Volatility because a real analyst walks kernel structures by hand would not be admired for the purity, they would be excluded from the case for the speed. Competence in DFIR has always meant knowing what the tool does, what it assumes and where it lies to you.
There is a second half to the analogy that is less often quoted. Engineers who never read assembler are perfectly competent most of the time, and the good ones can still drop one level down when the abstraction leaks, for instance when a performance problem or a miscompiled corner case refuses to yield to the layer above. That is the real content of “understand what you are doing”: you may delegate, as long as you can descend. Applied to an AI assistant, it is a demanding standard rather than a permissive one.
Why the analogy stops at the compiler’s door
A compiler is a deterministic translator with a specification. Feed it the same source and the same flags and you get the same binary, which is the whole idea behind reproducible builds, and when it gets something wrong the failure is rare enough to become a conference talk. A language model has no specification, gives different answers to the same prompt, and fails in the most unhelpful way possible, by producing something that looks right. A compiler never invents a function that does not exist and then writes a confident comment about it. The trust you can extend to the two is simply not the same trust.
The economics differ as well. A compiler does not change who has to read the result, whereas an assistant makes it nearly free to produce a patch and leaves the cost of reviewing it exactly where it was. Torvalds knows this perfectly well. At the same Prague conference he said AI is improving the code base while also stressing maintainers to the point of being a problem, and that about three quarters of the talks at the Maintainers Summit dealt with making these tools less exhausting to live with. The compiler analogy says nothing about this problem, because compilers never produced it.
His own answer, in the way it has been reported, is social rather than technical. One account of the summit has him arguing that blaming the LLM is a mistake, that the real problem is contributors who do not understand how the kernel works, and that maintainers should simply give low priority to their patches. I find that convincing as far as it goes. It turns understanding into an admission ticket, which only works if reviewers can still tell, quickly and cheaply, who has it.
Understanding is something you can show
Here the DFIR habit is useful, because forensics has been dealing with “trust me, the tool said so” for decades. When I wrote a few days ago about the forensics gap in eBPF-based EDR, I pointed out that the Volatility plugins available for the job are a patchwork, that one of them describes itself as alpha and warns against using it in real investigations, and that anyone relying on them should validate them against known-good memory images first. Nobody calls that hostility to tools. It is the procedure that turns a tool’s output into something you can defend, and an examiner who can only say the software told them so tends to have an unpleasant afternoon under cross-examination.
Moving the same habit into code review gives a workable definition of understanding. The author can explain why the change is shaped the way it is. They can say what they tested, including the case that failed the first time. They can name what the assistant proposed and they threw away, and they can trace the path a bad input would take through the new code. None of this depends on whether the first draft came from a keyboard or a model, and all of it is visible to a reviewer within minutes of a conversation.
The kernel already has the right anchor for accountability, and it is not the tag. The project’s guidance on coding assistants says AI agents must never add a Signed-off-by line, because only a human can certify the Developer Certificate of Origin, the statement that you have the right to submit this code. The same write-up notes that even the Assisted-by tag was phrased as “should” and not “must”. So the real contract was always the signature: the machine may type, a person answers for it. That arrangement survives the removal of the tag unchanged, which is probably why so few maintainers lost sleep over it.
The disclosure question Torvalds left on the table
None of this makes Pinchart wrong, and the email does not actually answer him. His point was about setting expectations, and a rule such as “tell us how this was made” is a different thing from a rule such as “don’t use the tool”. Torvalds demolishes the second while never quite touching the first. A tag that one patch in ten carries is useless as a signal, but a reviewer deciding how much scrutiny to spend still benefits from knowing whether the author watched the code being written or approved it from a chat window. The summit seems to feel the same way, since a proposal that emerged there is to describe the process in the cover letter of a series, as a sentence of prose rather than a line of metadata.
There is also a respectable case for outright bans, and the analogy does not touch it. NetBSD has refused AI-generated code since 2024, and System76 has kept it out of its COSMIC desktop. NetBSD recently reported donations of around 120,000 dollars against a target of 50,000, a surge that arrived alongside its AI-free stance. Those projects are not arguing that their contributors cannot code. They are arguing about provenance, licensing and the kind of community they want, which are legitimate questions that a joke about compilers does not answer.
Security teams should recognize the pattern from their own work. Attackers do not fill in disclosure fields, and they adopted the technology faster than most of us. Check Point’s analysis of the VoidLink framework found it was largely produced through AI-assisted development, by a single developer in under a week. A ban or a tag binds only people who were already behaving, and that is why I have little patience for policies built on avoidance. When I wrote about AI models escaping a test sandbox, the part worth attention was the question of who signed off on the environment and who would answer for it, rather than the metaphysics.
So the test I would take away from Torvalds is a practical one, and it works well outside software. Can you explain the thing you are about to ship? Can you reproduce the result without the tool in the room, at least well enough to check it? Can you break it on purpose? Will your name be on it when it fails? A person who answers yes to all four can use whatever they like, and I stop caring whether the first draft came from a compiler, an assistant or a very patient intern. What I want to know is who picks up the phone at three in the morning when it breaks.
FAQ
What did Linus Torvalds actually say about AI?
In an email to Laurent Pinchart on 13 October 2026, he rejected rules of the form “don’t use AI for X”, compared them to banning compilers and editors, and said he expects contributors to understand what they submit, whatever tools they use.
What was the Assisted-by tag?
It was a line in the commit message that the kernel documentation asked contributors to add when an AI tool helped write a patch. Maintainers at the October 2026 summit agreed to deprecate it, partly because only about ten percent of recent commits carried it.
Does dropping the tag mean AI-written code is trusted by default?
No. Patches are still reviewed, AI agents still cannot add a Signed-off-by line, and the human who signs the patch remains responsible for it under the Developer Certificate of Origin.