Torvalds used Claude Code. Judge the patch, not the tool.

On October 10, Linus Torvalds pushed an eight-patch series to a branch called noref-filemap-read-with-llm in his own kernel tree. The cover text, which sits in the tip commit of that branch, ends with a short section headed “Tools”:

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. The measurements were run on my machine.

Every patch in the series carries an Assisted-by: LLM line directly above Signed-off-by: Linus Torvalds. Tom’s Hardware and others picked it up this week. The commit above is the original.

This is a request for review, not a merged feature. It sits on its own branch, and the cover text says plainly what still needs work.

What the patch does, by its own numbers

When many threads read the same small file, each read takes and drops a reference on the cached page, and those two writes to one shared cache line become the bottleneck. The series lets reads copy straight out of the page cache without taking that reference, by making sure a page removed from the cache is not reused until an RCU grace period has passed.

Headlines have run larger multipliers than the ones below. These are the figures in the commit, from 8 threads doing 16-byte reads of one file:

The commit is careful about these numbers. They come from one laptop, the laptop throttles on temperature, and Torvalds says to “compare cost per read, not reads per second.” Nothing bigger has been measured.

The part worth copying is the disclosure

The cover text has a section titled “Known problems, and what I’d like eyes on.” It lists ten. Among them: with the first six patches, a test program ran a 2 GiB virtual machine out of memory, and the series as it stands is “a regression for CMA,” a kernel memory allocator. It lists what was not tested, from xfstests to 32-bit builds to “any machine but this one,” and closes the testing section with “Those … are all the testing there is.”

That is what a reviewer needs from any patch, whoever or whatever typed it: what the tool did, what a person measured, and what nobody has checked yet. The disclosure line about Claude Code is one sentence. The list of known problems is most of a page.

AI-assisted code gets judged harshly, and sometimes it has earned it

The suspicion is real, and it is measurable. In a study of 1,026 engineers at one company, reported in Harvard Business Review, participants rated a Python snippet. The code was identical in every condition. When reviewers believed the author had used AI, they rated that engineer’s competence 9% lower on average. The researchers called it the AI competence penalty.

Some of the hostility comes from real damage. curl’s maintainer ended the project’s bug bounty on January 31, 2026. He gave three reasons, and the first was “the mind-numbing AI slop.” In previous years, somewhere north of 15% of submissions were confirmed vulnerabilities. Starting in 2025 that fell below 5%: “Not even one in twenty was real.”

The productivity case has been contested too. METR’s 2025 randomized study found experienced open source developers took 19% longer with AI tools, while believing afterwards that AI had sped them up by 20%. METR now marks those results as out of date. Its February 2026 update reports a new problem with running the experiment at all: more developers declined to take part because they did not want to work without AI.

Where projects have actually landed

The policies split two ways. A few projects refuse AI-generated code outright. Most allow it, on conditions.

A study of 1,000 popular GitHub repositories found 118 contributor AI policies. 78% allow AI-assisted contributions. 51% require disclosure, and 74% require a human in the loop.

The kernel’s own guidance on tool-generated content says it most plainly: “You are expected to understand and to be able to defend everything you submit.”

Use the tool, and keep the standard

Read those policies side by side and the permissive ones converge on three rules: a named person is responsible, the tool is disclosed, and the work is tested. None of those is new. They are the rules good engineering had before any of this, and they are the rules Torvalds’ cover text follows.

The bans answer a real problem, which is unreviewed output arriving faster than people can read it. The curl numbers show what that costs. Refusing the tool does not fix it. Holding the standard does, and a standard can be checked: does the change come with tests, measurements, and an honest list of what is not done?

The competence penalty works against that. If labeling AI help costs an engineer 9% of their perceived competence, the rational move is to stop labeling it, and an undisclosed tool is worse than a disclosed one. Torvalds can afford the label. The way to make it affordable for everyone else is to judge the patch, not the tool that helped write it.

So: get on board. Use the tool, say that you used it, and put your name on the result the way you would for any other change.

How we do it here

We build and run our own business software this way. Of the 1,515 changes committed to its main branch this year, through today, 1,407 name Claude as a co-author in the commit itself. That line is our version of Assisted-by.

The rest of the standard is the same one the kernel asks for:

What this means if you are buying software

If you are paying someone to build software for your business, whether AI touched the code is the wrong question. Ask who is responsible for it, how it was tested, and what they know is not done yet. A builder who can answer those three, with evidence, is doing what the kernel asks of its own creator.