Linus Torvalds has spent years reviewing the most consequential codebase on Earth without reading much of the code. He said so himself in a 2020 interview with Tag1 Consulting: “While I still look at patches, I actually tend to look more at the explanations, and the history of how the patch came to me.”

That habit was never laziness. It was the sharpest quality filter in software, and it rested on an economic fact: a coherent explanation of why a change belongs in the kernel was expensive to produce. You had to understand the subsystem, the failure mode, and the design decisions that shaped the current code. Faking the explanation cost more than having the understanding. So the explanation worked as proof of understanding, and the man at the top of the review pyramid could read intent instead of implementation.

At Open Source Summit India 2026 in Mumbai this month, Torvalds described the thing that broke that filter. He never framed it as broken. The quotes do it for him.

The Explanation Was Proof of Work

Tests can be gamed. Diffs can be pattern-matched from similar fixes without understanding either one. But for decades, a paragraph that correctly situated a change in the design history of a kernel subsystem could not be written by someone who lacked the mental model. Reviewers up and down the kernel hierarchy leaned on that correlation. Torvalds built his entire post-programming job on it.

The correlation was always a proxy, though. Nobody cares about the explanation itself. They care about the understanding it demonstrates, and Goodhart’s law says any proxy works right up until it becomes a target. A proxy survives on the cost of faking it. This one survived for thirty years because the fake was more work than the real thing.

LLMs Made the Proxy Free

Large language models generate code that is sometimes wrong. They generate prose about code that is nearly always fluent. The explanation, the one artifact that used to be hardest to fake, is now the cheapest part of the submission.

Torvalds described what that looks like from the receiving end: bug reports that read as entirely valid and turn out to be fabricated. “It can actually be a huge drain on resources when it takes humans a lot of effort to figure out that, hey, this machine-generated report was not true,” he said. Note the asymmetry: the report costs nothing to generate and real investigative work to disprove. That is a filter running backwards, taxing the reviewers it used to protect.

The patches carry the same signature. He called many of them “mindless band-aid kind of patches… they may fix the immediate problem, but the kind of bug remains, and it just is waiting in the hallway to hit you in another place.” A band-aid patch in 2019 usually arrived with a thin, awkward description, and the description gave it away. The same patch in 2026 arrives wrapped in a confident, well-structured explanation of a root cause the author never found. The tell is gone. Prose quality no longer predicts anything about the understanding behind it.

The Fix He Announced Is a Provenance Requirement

Buried in the Mumbai remarks is the actual news, and it got almost no coverage: “If you find a bug with an LLM, it’s not enough to just ask the LLM to make a bug report and then throw it over the fence to us. We want to see a suggested patch; we want to see the human who ran the LLM act as a kind of back-and-forth.”

Read that as a submission requirement, not a complaint. He is no longer asking the explanation to prove anything. He is asking for evidence of the process: show me the dialogue, show me where you pushed back, show me what the model got wrong before you fixed it. The unit of review is shifting from the artifact to its provenance. For decades the kernel asked whether the description demonstrated understanding. The new question is whether the human can show their working relationship with the tool that produced it.

That is a bigger change than it sounds. The transcript of the back-and-forth, not the polished description sitting on top of it, is becoming the thing a maintainer actually wants to see.

Nobody’s Tooling Captures This Yet

PR templates ask what changed and why. CI gates check tests, coverage, lint. None of them ask the question Torvalds is now asking: how do you know? The description field is where the fluent fake lives. The evidence of a genuine back-and-forth lives in session logs most teams throw away.

Closing that gap does not need a platform. A template section does most of it:

## Provenance
- Generated with: <tool/model, or "by hand">
- First-pass mistake I caught: <what you pushed back on>
- What I checked myself: <command you ran, output you read>

The middle field is the tell. A developer who worked the problem with a model fills it in ten seconds, because every real session has one. A developer who piped output over the fence has nothing to put there, and an empty field is a louder signal than a beautiful description.

I started keeping this kind of evidence before I had a name for it. When I published a self-improving agent demo earlier this month, the repo shipped with the actual run logs, a 13-of-15 test pass climbing to 15-of-15 across iterations, because without the logs the claim is indistinguishable from every other AI demo on the internet. The logs are the proof the loop ran. The README is just the description.

Where This Breaks

The obvious objection: transcripts can be faked too. Ask the model that wrote your patch to also write a plausible back-and-forth and it will produce one, complete with staged pushback. If teams start grading transcripts, Goodhart eats the transcript next. Grading them with an LLM judge inherits the same problem one level up.

The kernel’s answer is already visible, and it is not paperwork. Torvalds has been blunt that the AI slop problem will not be solved with documentation, and kernel maintainers already deprioritize drive-by reports whose submitters won’t answer questions. The gate is not the artifact. The gate is whether you can continue the conversation. A fabricated transcript buys exactly one round; the first follow-up question a maintainer asks lands on the human, in real time, with no model in the loop to sound fluent for them.

So Torvalds’ test did not die in Mumbai. It moved. Reading the explanation stopped working, so he replaced it with watching you respond.

The next time a pull request lands in your queue with a suspiciously fluent description, run the kernel’s version of the test. Ask one follow-up question the description does not answer, and watch the clock. The answer that comes back in five minutes was always the author’s. The one that takes a day was written by whatever wrote the description.