Linus Torvalds uses Claude Code for Linux patches

What this video covers

• The source is experimental branch work, with a Saturday October 10 commit and a Phoronix report published Sunday evening in EDT, already Monday in GMT+7. The selected sources do not establish a completed mainline merge or release.
• Small reads of the same cached file can contend on a shared folio reference count. The proposal permits copying under RCU read-side protection while deferring final memory reuse until a grace period.
• Linus's eight-thread, sixteen-byte shared-page test reports 2937–2975 baseline kernel cycles per read and 725–726 with the series, about a quarter of the cost. It is an author-run laptop microbenchmark with mitigations and hardened usercopy disabled, not a whole-system performance result.
• The source also reports a missing-destination-page regression and unresolved allocator accounting for memory waiting to be reused. Broader machines and several debugging/test configurations remain untested.
• Karpathy attributes different AI experiences to access, ambitious problems and verifiable tasks. His professional-user count is explicitly napkin math; no survey accompanies the post.
• Cendyne describes an unnamed employer gaining confidence to coast toward M&A with cheaper AI assistance. This is one firsthand account and its author's interpretation, not an economy-wide job count or proof of equivalent engineering skill.
• A useful tool, a safe patch and a sensible staffing decision each require their own evidence and an accountable owner.

Transcript

Would Linus trust a coding bot?

0:00 You'd expect Linus Torvalds to make a coding bot cry during review. He's using Claude Code for Linux patches, and even the first draft of the cover letter. In this video, why do tiny reads cost so much? And whose job changes? Keep an eye on what happens to the memory after the read. That's where this speedup sends the bill. It's Monday, October twelfth, and this is The Daily Diff. Claude Code is Anthropic's coding assistant.

0:23 It can read a project, edit files and run commands. Linus is directing it on Linux memory management, where reading data already in memory can still make processor cores fight over bookkeeping. Phoronix spotted the branch Sunday evening in America, already Monday here. The commit is dated Saturday. This is experimental work, with eight patches and a request for scrutiny. Your laptop hasn't secretly downloaded an artificial Linus.

Why can reading memory cause a traffic jam?

0:45 Several threads read the same cached file. Each read grabs a reference to the memory, then drops it afterwards. The reference count gets written twice, so cores doing innocent little reads compete over bookkeeping. The library has eight readers and one sign out sheet. His proposal delays recycling the memory using a read copy update grace period. Readers can copy cached data without taking that reference. When a page is removed, its memory must wait before reuse.

1:09 The speedup comes from changing lifetime rules around the data. Linus credits Claude Code for the code, test programs and review behind his list of problems. It drafted the explanatory text under his direction. The measurements ran on his machine. Even the robot has to bring receipts to this review. The headline result uses eight threads reading sixteen bytes from one page.

What does the laptop benchmark actually measure?

1:28 Think tiny repeated reads of the same file. He compares processor cycles per read because his laptop throttles when hot. A benchmark with its own weather forecast. The baseline costs roughly three thousand cycles per read. With the patches, it's around seven hundred twenty five. That's about a quarter of the processor cost in this test. Your entire Linux machine has received zero promises of becoming four times faster. His cover letter puts the awkward bits beside the exciting ones.

1:53 Security mitigations and hardened usercopy were off. He lists missing tests, including other machines and memory debugging tools. Reading the footnotes is now a competitive advantage, which feels like a bug in humanity. There's a regression when the destination user page is missing.

Which reads get slower?

2:07 The tiny read gets more expensive because the fast path fails before the old path handles the page fault. The proposal accelerates one path while adding work to another. Both belong in review. Treat this as an engineering experiment with a known bottleneck and measurements with limitations. Reviewers get something concrete to challenge. An assistant producing patches leaves somebody responsible for proving the dangerous parts safe.

Why are people seeing different AI capabilities?

2:30 Meanwhile, Andrej Karpathy says our understanding of AI capability is pulling apart. His fresh post revisits an April observation. He describes a funnel, from people barely using language models to professionals directing powerful coding agents. Same word, AI, different day at work. His napkin math puts about twenty million people in professional frontier model use for math and code. That's an estimate, with no survey supplied.

2:52 He emphasizes access, ambitious problems and verifiable tasks. A chatbot conversation and a supervised kernel experiment exercise different muscles. Someone watches a bot fumble a request while another person ships a useful patch. Population estimates are dangerously easy to repeat as research. Keep the estimate label attached before the graph starts wearing a lab coat. Ask what the system could do, how the result was checked and who owned the outcome. Those questions travel better than screenshots of miraculous answers.

How can AI change a job before replacing its skills?

3:21 Then Cendyne published a less comfortable account titled Fable took my jorb. The author says they were the last engineer at a company, and leadership believed cheaper AI assistance could let it coast toward a merger or acquisition. Management can change spending before a model matches an experienced engineer's judgment. Cendyne argues that taste and foresight remain missing, while marketing supplies confidence.

3:42 A payroll decision can arrive before the technical argument gets settled. The post describes fear after the layoff and says the author has found something else. That's a person dealing with consequences. The punchline belongs to the spreadsheet making the decision. Calling it efficiency gives accounting a generous performance review. Proving a tool useful and proving a staffing plan sensible are separate jobs. The patch has a testable workload. The employer's bet involves product ownership and future failures.

4:09 A passing microbenchmark cannot sign the support contract. We have one developer's account with an unnamed employer. It supplies a perspective, and no economy wide job count or independent assessment of that company's needs. Keep the scope attached when sharing the story. The common variable is responsibility. Linus directs the work. Karpathy describes uneven access and tasks.

4:29 Cendyne describes a management bet. Somebody owns the consequences in every version.

Where does the speedup send the bill?

4:34 And the memory bill? Removed pages wait before reuse, and the allocator can't properly see that waiting memory. Linus lists this as unresolved even with his mitigation patches. Faster reads hand another subsystem a harder accounting problem. The bookkeeping finds a new desk. That's a footnote worth keeping. If you'd rather read this than hear me say it, the diff lands in your inbox

4:53 every morning, free at the daily diff dot dev, link below.

Would I ship these patches?

4:56 So today's verdict, NEEDS REVIEW. I'd keep the assistant in the workflow and demand broader testing before shipping these lifetime changes. Responsibility stays with the engineer. And that's the diff for today. I'm Niko from Axrisi. Merge responsibly.

Sources

1. Read from the page cache without folio references — cover letter and testsLinus Torvalds / kernel.org
2. Experimental noref-filemap-read-with-llm branchLinus Torvalds / kernel.org
3. Linus Torvalds Working On A Hefty Linux Kernel Improvement With Claude CodePhoronix / Michael Larabel
4. Claude Code overviewAnthropic
5. Capability-understanding gap and napkin estimatesAndrej Karpathy / X
6. Fable took my jorbCendyne
7. Discussion of Linus's Claude Code branchHacker News
8. Discussion of Karpathy's capability-gap postHacker News
9. Discussion of Cendyne's accountHacker News