Linus Torvalds's first LLM-assisted patch series
TL;DR Highlight
Linus posted an LLM-assisted 10-patch series giving an order-of-magnitude read() speedup, with a race already found.
Who Should Read
A backend or systems developer deciding whether AI coding tools hold up on a large real-world codebase
Core Mechanics
- Linus used an LLM for a patch series
- He said at the Maintainers Summit he was using an LLM on a longstanding problem.
- He then posted a ten-patch series for review.
- Hot folios get their release delayed past an RCU period
- A folio (kernel page-cache unit) that is hot is marked to be released after an RCU period.
- That lets both the lookup and the data access run inside an RCU-protected region (lock-free read sync).
- The fast path needs no refcount
- If the user copy causes no page faults, the data is read entirely under RCU.
- No refcount is taken on that path.
- A read()-heavy benchmark got an order of magnitude faster
- The article reports an order-of-magnitude speedup.
- It gives no baseline or exact figure.
- Review already found a race condition
Community Reactions
- Commenters quoted a commit message disclosing LLM use
- A comment quotes the draft branch's empty commit saying code, tests, review and first draft were done with Claude Code under Linus's direction.
- It says measurements ran on his own machine.
- An opinion that the diffs are small and readable
- One commenter looked at the diffs and found them moderately sized and readable.
- They contrasted this with the usual 2k-line LLM commits.
- Experience that Claude Code often produces code that looks right but is broken
- One commenter says this happens all the time.
- They usually find out via local debugging or Sentry alerts.
- Reactions that outcomes depend on who uses the tool
- One comment compared it to an excavator in a pro's versus a layman's hands.
- Others worried beginners will think that if Linus did it, they can too.
How to Apply
- Add a concurrency checklist to your reviews today
- When reviewing LLM-written PRs, check for race conditions first.
- Paste a diff into the prompt below for a concurrency review.
- Split LLM changes into small commits
- Tell the LLM to make one change per patch.
- Keep each one small enough for a human to review.
- Record LLM use in commit messages
- Add a PR template field for the tool used and what a human verified.
- Note the environment where you ran measurements.
Try It
# Paste into Claude or ChatGPT (simplified version of the "LLM writes, human review finds the race" idea)
You are a concurrency-bug reviewer. In the diff below, find race conditions, release-timing issues in lock-free read sections, and missing ordering guarantees.
{{diff}}
For each issue, give file/line, the scenario (thread A/B order), and a fix in a table. If none, explain why.
Next to try: ask it to split the same diff into smaller patches and compare which is easier to review.Terminology
Related Papers
The Judge Can Debias Itself: Awareness and Self-Debiasing for Reliable LLM-as-a-Judge
Warning an LLM judge about bias or letting it self-critique improved 20 of 21 model–bias combinations.
90% of US working hours are spent on tasks not covered well by AI benchmarks
Mapping 29 benchmarks to job tasks shows 90% of US working hours lack good coverage
Postgres 19 delayed after AI reviewers find more bugs than humans can fix
LLM code review surfaced so many bugs that Postgres 19 slipped to November and 8-10 features were reverted
Show HN: Gemini 4 Argon plays StarCraft
LLMs wrote StarCraft bots in one hour; GPT-6 Astra scored highest.
A Plausible Explanation Is Enough to Mislead Multimodal Judges
Adding plausible explanations to fixed answers cut MLLM judges' wrong-answer rejection by 12.7–13.8 points.
Neural networks are clean
Looking at neurons directly shows most have one main job, challenging superposition.