On 13/10/2026, Linus Torvalds sent the Linux kernel mailing list a 10-patch series written with Claude Code, under his direction, that fixes a page cache scalability bottleneck open since 2024. About four hours later, developer Kiryl Shutsemau replied with a race condition in the code. One side says AI solved in weeks what humans could not solve in two and a half years. The other points out the patch is not ready yet. Both are right, and what matters for anyone coding with an agent is the process that caught the bug.
What did Torvalds do with Claude Code in the Linux kernel?
He rewrote page cache reads so the most common read() path no longer touches the page reference count. The announcement is the "Improve page refcount scalability" email from 13/10/2026, and the code is in the rcu-free-v3 branch of his public tree.
- The problem: with many threads reading the same file, every read writes to the same counter, and that cache line bounces from core to core. Matthew Wilcox reported it in 2024, from a real customer workload.
- Earlier attempts: a draft by Torvalds himself, which he ran "broken" on his own machine for a year and a half; a version by Shutsemau a year ago that "too had problems"; and Ilya Gladyshev's series, now at version 6, with "outstanding known fundamental issues" (Torvalds' words in the email).
- What Claude Code did: according to the cover letter of the first version, summarized by Hardware Busters, the agent wrote the implementation, the test programs, the review behind the list of open problems and the first draft of the letter itself. The benchmarks ran on Torvalds' machine.
- The branch name: the first version was published as
noref-filemap-read-with-llm. The AI use was in the name.
What is the case for the patch?
It works, it is small, and it landed after two and a half years of attempts that did not. Torvalds answered an objection from Wilcox with this line: "I have a patch series. It's clean. It's ten patches, each of them cleanly separated, half of them *tiny*, and none of them more than 150 lines of code. It works."
The numbers are his, measured on his own hardware:
| Machine | Before | After |
|---|---|---|
| Ryzen Threadripper, 64 threads | 13.3 million reads/s, about 19,900 cycles per read | 304 million reads/s, 735 cycles per read |
| Core i7-8565U laptop, 8 threads (1st version) | about 10 million reads/s, 2,950 cycles | up to 33 million reads/s, 725 cycles |
Torvalds added the caveat himself: it is "a very artificial case", reading the same small part of a page in a loop on every CPU, and "any real life impact will be much much less". The number shows the bottleneck is gone, not that your server will get 23 times faster.
What did the reviewers find?
A real race condition, design objections and a basic doubt about whether the change is worth the risk. All in less than 24 hours, on the public list.
- The race: Shutsemau showed that if the page is replaced in the cache and the file grows during the read, the reader can copy from the old page "data that never got written there". The proposed fix is two lines: check again, with
xas_reload(), that the page is still the same after reading the file size. - The design: Wilcox said he does not like the new
PG_rcu_freeflag and proposed another route. Harry Yoo asked for a limit on memory waiting to be freed. - Cost versus benefit: Pedro Falcato wrote that until there is a real case where performance changes substantially, "not a microbenchmark", the patches "look to be more trouble than they're worth".
- There is a known regression: in the first version, a 16-byte read into a user page not yet mapped went from about 4,150 to 6,550 cycles (Hardware Busters). It is unclear whether it remains in v3.
Torvalds accepted the race fix and handed the series to Shutsemau: he is going on vacation and running the merge window. None of it has been merged into the kernel yet.
Where do the two sides agree and where not?
| Point | Torvalds | Reviewers |
|---|---|---|
| The bottleneck exists | Yes, since 2024 | Yes, nobody disputes it |
| Code correctness | "It works" | Race found and fixed within hours |
The PG_rcu_free flag | Required, must exist before unmap | Wilcox prefers another mechanism; Shutsemau and Hildenbrand suggest 64-bit only |
| Real-world gain | Admits it is far less than 23x | Falcato wants a real workload, not a microbenchmark |
| Role of AI | Wrote code, tests and review under his direction | The debate is about the design, not the tool |
The last row is the one that matters most. No reviewer rejected the patch for being written with AI. The objections are the same a human patch would get, and the bug is the kind Torvalds' own manual draft also had.
How do you repeat Torvalds' method in your own project?
Isolate the agent's work, ask for the list of problems, measure it yourself, run a race detector and let someone else review before merging. As commands:
1. A branch that says what it is.
git switch -c filemap-read-with-llm2. Ask the agent for the list of what could be wrong, not just the code. That is what Torvalds did. A sample prompt to paste into the session:
List the open problems in this change: possible race conditions,
read and write ordering between threads, cases where the resource is freed
while someone is still reading it. For each one, say whether a test covers it.3. Run a race detector. Review by eye, human or agent, lets races through. Tooling catches some of them at runtime:
# Go
go test -race ./...
# C and C++ with ThreadSanitizer
clang -fsanitize=thread -g -O1 app.c -o app && ./app
# Linux kernel (KCSAN), in .config
CONFIG_KCSAN=y4. Measure on your machine and say what the number does not prove. Torvalds published the benchmark together with "any real life impact will be much much less". Do the same.
5. Declare AI use in the commit. The kernel has a written rule for this in Documentation/process/coding-assistants.rst: the agent never adds Signed-off-by, only the human does, and the contribution carries a line in the format Assisted-by: LLM [TOOL1] [TOOL2]. In Verboo Code, the text that /commit appends at the end of the message is configurable:
/commit-message set "Assisted-by: LLM"
/commit-message statusTo review a PR with the agent before calling a human, the /review command runs gh pr diff and returns the analysis. Treat it as a first pass: in the kernel case, the series went through the agent's review and still reached the list with the race.
What is Verboo Code's position?
This episode is the best argument so far for coding agents in serious code, and not for the reason the headline suggests. The number that matters is not 23x. It is that the race showed up in about four hours because the code went to public review by people who know the subsystem. The code had been through the agent and through Torvalds and reached the list with it.
The rule we take from it: do not merge code that only you and the agent have read. The agent speeds up writing, testing and listing risks; review by a specialist is still what separates "works on my benchmark" from "works".
The cheap part of this math is asking the agent for one more round: the list of problems, the missing test, a second pass over the diff. With Verboo Code usage comes with unlimited tokens, so the third review costs the same as the first and leaves more time for the human review that caught the bug.
