Linus Torvalds Used Claude Code on the Linux Kernel: What He Built, What It Proves, and the Rules for Everyone Else

What happened

In the second week of October 2026, Linus Torvalds, who created Linux and still decides what goes into it, pushed a branch to his own kernel tree with a name that says what it is: noref-filemap-read-with-llm. It holds eight patches. In the description that goes with them, he is plain about who did the typing: "The code, the test programs, the review behind the list above and the first draft of this text were done with an LLM coding assistant (Claude Code) under my direction."

That is new. Torvalds has spent years being sceptical of AI hype, and the Linux kernel is some of the most carefully reviewed code in the world. ZDNet reported his own summary of how his view moved, from Open Source Summit Europe: "I used to think it was just not very good — but now I'm at the point where I actually really like using AI."

What the patch does, in plain words

When a program reads a file that is already in memory, Linux reads it from the page cache, its in-memory copy of recently used files. Each time, the kernel marks the piece of memory as "in use" by bumping a counter, so it cannot be thrown away mid-read, then lowers the counter afterwards.

That is cheap once. It is not cheap when many threads read the same small file at once: they all fight over the same counter, and the processor spends its time passing that counter between cores instead of reading. Torvalds' branch removes the counter from this path. Memory that leaves the cache is not handed back straight away, only after a short waiting period (an RCU grace period, in kernel terms), so a reader that is still copying from it is safe without marking it.

The catch is that memory waiting to be handed back is memory nobody can use. Two of the eight patches add a safety valve for that, and Torvalds calls deferred freeing "the part of this series that is least solved."

How much faster, and on what

The test is deliberately narrow: eight threads, each reading 16 bytes again and again from one file that is already cached. Hardware Busters, working from the cover letter, reports these numbers from his laptop, an Intel Core i7-8565U with four cores and eight threads:

Read those numbers for what they are. This is one laptop, with some security mitigations switched off, running a test built to cause exactly the contention the patch removes. Most programs do not hammer one tiny file from eight threads, and they will see little or nothing. Torvalds expects bigger, many-core servers to gain more, but nothing larger has been tested yet.

Is it in Linux yet?

No. The branch sits on top of the 7.3 release candidates and has not been merged. Torvalds lists the open problems himself: the memory held back by deferred freeing, costs outside the read path that nobody has measured, and many configurations still untested. Whether it goes in is up to the kernel's memory-management maintainers, and very likely to someone re-running the numbers on a large server. The Claude Code credit does not change any of that. It gets the same review as any other patch.

The other one: bugs hiding since 2013

The same weekend, a separate piece of work showed a different use. A developer, Nils Ollrogge, reported a bug in assoc_array, a kernel library for storing lookups, and sent a fix. Phoronix reports that Torvalds found the code too obscure to follow, so he used LLM tools to make sense of it, splitting its large functions into smaller, readable ones. A user-space test harness then confirmed the reported bug and turned up three more. All three date back to the library's first commit in 2013. In the tag message for the fixes he wrote that he "did what I preach."

This is arguably the more useful lesson. Nobody asked the AI to find bugs. It was used to make old code readable, and readable code is where the bugs became visible. The fixes are expected in the Linux 7.4 merge window.

The kernel's rules for code written with AI

Linux already has written rules for this, in two short documents: AI Coding Assistants and Tool-Generated Content. They come down to four things:

• A human signs off. An AI must never add the Signed-off-by line. Only a person can certify where the code came from, and that person takes full responsibility for it.
• Say what helped. Contributions carry an Assisted-by: tag naming the tools, and the cover letter should say which parts a tool wrote and how it was tested. Torvalds did exactly this, down to the branch name.
• Understand all of it. In the documents' words, "You are expected to understand and to be able to defend everything you submit." If you cannot, do not send it.
• Expect more scrutiny. Maintainers may review AI-heavy patches more carefully, more slowly, or reject them without detailed review.

The rules exist because of the downside Torvalds also talks about. ZDNet reports his warning that questionable AI-made bug reports and superficial fixes cost maintainers time they do not have. His own advice: "you need to be very careful using AI when you're doing something real and important."

What to take from it

For using the same tool well, see getting more out of a coding agent, scope control for AI coding agents and CLAUDE.md and Claude Code in practice. The tool is listed at Claude Code, and the rest are in every coding tool in the directory. The story is in the October 13 Daily Ten.