You probably read the Linus Torvalds debugging story and the first thing that came to your mind was “even Linus now uses AI.” Well, this take may be why you miss the most important detail in his Git commit message.
After a long debugging session in which an AI repeatedly determined a bug was unsolvable, the reason why he kept pushing is one of the biggest lessons in proper use of AI. It’s far more consequential than most of the AI prompt guides I’ve studied this year.
The Torvalds story everyone flattened into one sentence
24 patches, 18 reboots, one word
Linus Torvalds was only able to track down a bug in Linux’s Intel graphics driver after 24 debug patches and 18 kernel boots. On Torvalds’ Battlemage G21 system, the bug caused the display manager to repeatedly fail, leaving him with a black screen. When he found the core of the fix, it came down to changing round_up() to round_down(). It took several weeks to realize “up” should have been “down.”
Sadly, the angle “even Linux Torvalds uses AI” has been easy bait that has distracted a lot of the reporting on the story; the hero and creator of Linux also types into a chatbot like the rest of the world. It might be mildly funny, yet it’s totally not the point.
The real uncovering comes from what happened during those 24 patches. This wasn’t a case of AI grinding away and producing a fix while Torvalds relaxed and waited for the outcome. During the process, the AI repeatedly tried to convince him to stop, even describing the problem as impossible and unsolvable. In other words, it was effectively telling him to give up and file a bug report.
Torvalds ignored the AI’s recommendation to give up, and that is indeed the part that deserves focus. He chose not to let the AI’s conclusion end the investigation.
The AI tried to give up on this bug
The exact phrase that should make you pause
The actual phrase that the AI used in describing the bug was “impossible and unsolvable.” The AI reached that conclusion multiple times while Torvalds remained elbow-deep in the bug. The AI wasn’t saying it had run out of leads or that the investigation would take a lot of time; it was declaring the problem impossible and unsolvable. These words sound final, and would, in most cases, kill any resolve to try again.
If you haven’t already, at some point you’ll probably get a version of this same response from AI. Give it a difficult bit of code, a very messy spreadsheet formula, or let it untangle a WordPress conflict. Eventually, you may run into the same situation where it confidently tells you that something is simply impossible.
A problem running out of solutions is not the same as a model running out of ideas. We may be prone to treating them the same. It’s easy to treat a confident answer as evidence that the model has already considered every reasonable possibility. This reasoning is one of the costliest habits encouraged by the rise of commercial AI.
The difference was that Torvalds didn’t let the AI’s confidence outrank his own judgment. He wasn’t trying to ask it in a nicer way or out-prompt it.
One job for the AI; one job only for him
The line between “help me look” and “tell me it’s fixed”
Certain tasks were split between him and the AI. It handled much of the grinding and repetitive work. These types of tasks — adding debug output, testing changes, boot after boot after boot — typically would numb a human. Torvalds even let the AI write the final commit because it was quite good at explaining its findings. He credited it by name in the patch notes.
The part that stayed with him was deciding whether the investigation had actually reached an answer.
My entire lesson from this fits into one sentence: let the AI search, never let it decide. For this particular fix, it needed an understanding of the graphics driver role to start with. This is much different from knowing what it’s currently doing wrong. Torvalds had built this level of understanding having worked on the Linux kernel for decades, and AI models don’t have that. They may be very detailed when describing what is happening without necessarily knowing which part of that behavior is actually wrong.
A new habit worth stealing
You can run into this kind of problem without even touching kernel code. You’ll find it in an automation script that only runs halfway while your AI model insists the API doesn’t support the task you are trying to perform. It may show up as an AI telling you that a framework limitation is responsible for your broken website.
The answer you must always ask before accepting the outcome is simple: Do you possess information that the model cannot infer from the evidence it has? The reply may show up in the form of the data you already have, your intent, or just an understanding of what it does when it’s working right.
There will be times when the AI’s “impossible” actually means impossible. But there is still a point where you have to decide whether that conclusion is true. You shouldn’t outsource that to AI.