2 months ago, Linus spoke on AI and code quality that would make a lot of people uncomfortable.
He said, he is no longer a programmer that he was. Not in the sense, that he has lost his ability, but rn he reads pull requests description now more than the code itself. He now tries to understand intent more than the implementations itself, whether the one sending patches actually understands what they have done.
He sends patches as suggestions now, and expects maintainers understanding the specific subsystem to send back a fix.
What he focused on, that nobody is mentioning correctly?
His main focus was: Hallucinations, and the junk patches that ai sends.
The mental drain on the maintainer to focus on bogus bug reports, time and efforts of theirs wasted to understand the implementations and then, confirming with the one sending patches about what they have done, to then again focusing on ensuring backward compatibility with the system.
He described ai-generated patches as Mindless band-aid fixes.
He specifically mentioned the fact, ai may fix the immediate problem or a bug visible, but another might be waiting in the hallway to hit in the other place.
Above is normal, when someone tries to fix the problem without understanding the cause will create new problems uninformed.
Torvalds put it another way when he described what he looks for in a pull request. He said he wants to understand the bigger picture. He reads the explanations more than the diffs because the explanation tells him whether the person sending the change actually understood what they were doing.
Going with rust
Everyone stated his opinion into thinking "Linus doesn't like Rust" or "Linus is coming around to Rust" but neither was the point.
His point: Rust fixes few bugs that you would make in C. It does not fix logic errors, it does not think for you. If you write incorrect code, the end result would either way drift from you what was desired.
end result, incorrect? full stop!
He went further, People assume adopting Rust makes a codebase safer in some comprehensive sense. It doesn't.
The High-profile kernal bugs introduced weren't memory-safety issues. They were logic errors, engineers writing code based on a wrong understanding of what the code was supposed to do. No language catches that. No tool catches that. No AI system currently catches that either. It's a category of error that requires a human to hold a correct mental model of intent.
This isn't Linus having an opinion. This is thirty-five years of reviewing code from subsystem experts talking. When he says the dangerous bugs are logic errors, that's an observation from the largest, most scrutinized production codebase that exists.
What the AI part actually meant, that most coverage botched
He was careful here, more careful than the press gave him credit for. He said the field is now at a point where AI hopefully creates more productivity than it destroys.
that's a modest claim. Not "AI is transformative." Just "hopefully net positive." That's it.
What he can do that nobody else can isn't write C faster than anyone alive. It's understand the full system well enough to know if a change belongs in it. It's read someone's explanation of what they did and know immediately whether they actually understood it or are bluffing. It's resolve merge conflicts half-asleep because the pattern recognition runs below conscious thought at this point.
That capability doesn't come from writing code. It comes from decades of building mental models — how systems behave, why decisions got made, what the consequences of those decisions turned out to be years later, often in ways nobody predicted at the time.
AI can write code. It cannot build that model, because the model was never in the code to begin with.
The actual takeaway for engineers
understanding intent, reading explanations over diffs, working with people instead of tools, telling whether someone actually understood what they built versus just got the tests to pass
Code generation doesn't compound the same way. It resets every time a better model ships.
He's not worried about AI replacing engineers. He's worried about AI-assisted engineers who never did the work of understanding their own systems.
Thirty-five years of watching the kernel taught him to tell the difference between someone who understands a system and someone who's learned to generate plausible-sounding output about it.
His test for that difference is simple: read the explanation, not just the diff.
Top comments (3)
Reading the description instead of the code gets framed as Linus going soft, but it is the rational move for a maintainer of a subsystem they do not own: intent is the only thing you can verify from the outside, and behaviour you can only check by running it. The cost does not disappear, it moves to whoever has to reproduce the claim.
Where AI makes it genuinely worse is that descriptions became cheap to produce while verification stayed expensive. A plausible paragraph about what a patch does is now free, and a green test run is still not. So the signal I trust is the contribution process: a patch that does not say what was actually executed, on which config, is exactly the one that costs a maintainer the most to triage.
Indeed, reading pull-requests description silo won't compound in ensuring backward compatibility for adding new things and keeping the system alive!
what was tested? what was the config? cmd? what was the output? -- all are still important questions to ask while programming.
a good sounding description is also cheap these days, considering how much AI can autogenerate that but direct communication with people helps in clarifying that much - normal verbal communication tests real deep expertise.
But I don't think I have framed him as soft anywhere, he understands the system, and accordingly he directs his energy. He leads his system in a different way now, than he used to as far as I could understand from what all legitimate source I could find.
Specific subsystem owners do have to, in fact ensure backward compatibility and own parts.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.