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 (0)