A few days before he told an Open Source Summit audience in Prague that he "actually really" likes using AI, Linus Torvalds pushed a new branch to his own kernel tree. It is called noref-filemap-read-with-llm, and the name is not subtle.
The branch holds an eight-patch series that changes how Linux reads from the page cache. In the commit message, Torvalds says the code, the test programs, the review that produced the list of open issues and the first draft of the cover letter were all done with Claude Code, under his direction. He ran the measurements himself, on his own laptop.
What the patch does
When many threads read small chunks from the same cached file, they all fight over a shared reference count on the page. The patch lets readers copy the data without taking that reference, using RCU instead. Matthew Wilcox flagged this contention problem back in 2024 after a customer workload ran into it.
The numbers in the write-up are striking. On an Intel Core i7-8565U laptop, eight threads doing 16-byte reads on one cached page went from roughly 10 million reads per second to 30 to 33 million. Kernel cycles per read dropped from about 2,950 to about 725.
It also made one case slower. A single-thread read of an unmapped page went from about 4,150 cycles to about 6,550. And the whole thing is a microbenchmark aimed at exactly the pattern being fixed. Nobody should read "3x faster Linux" into it.
As of this week the series is not merged. It is sitting on a branch while people look at the hard cases: files being truncated mid-read, invalidation, memory pressure. These are the places where clever lock-free code tends to hide bugs.
The part worth copying
Strip away the celebrity and this is a very ordinary story. An experienced engineer used an AI tool to do a lot of the typing, kept ownership of the design and the measurements, labelled the work clearly, and then put it in front of other experts before it went anywhere near users.
That last step is where most companies are weakest. AI tools have made it cheap to produce code and expensive to review it. Torvalds himself said in Prague that the extra load on maintainers is a real problem. Every engineering leader we talk to has some version of this complaint: pull requests are getting bigger, coming faster, and reviewers are skimming.
A few things from this episode translate straight into team policy. Say when AI wrote a meaningful part of a change, the way Torvalds did, so reviewers know where to look harder. Keep a human accountable for performance claims, with numbers they ran themselves. And for the risky parts of your system, the equivalent of the page cache, decide in advance that AI-drafted changes get a second senior reviewer. It costs time, but it is a lot cheaper than a race condition in production.
If the person who wrote Git and Linux still sends his AI-assisted patch out for review before trusting it, your payments service probably deserves the same.
