Linus Torvalds used an AI to help debug something recently. It didn’t go quite the way the marketing materials suggest it should.

“I’d like to call it my tireless helper, but the AI several times stated flat out that this was impossible and unsolvable and that we should just write a report about it,” Torvalds wrote this week. “I suspect those things have been trained by people who may not be quite as stubborn as I am.”

The detail that matters: the AI kept suggesting they give up and document the failure. Torvalds kept pushing. Eventually they solved it.

This matches what developers who actually use these tools report. Coding assistants work fine for straightforward tasks. They struggle when things get weird. And they’ve apparently learned to suggest the professional equivalent of “have you tried turning it off and on again” when a problem looks hard.

The training data probably includes a lot of reasonable engineers saying reasonable things like “let’s file a bug report” or “this needs more investigation.” Reasonable, but not always what you need when you’re five hours into a debugging session and determined to find the root cause.

The skill isn’t code review

Simon Willison, who writes extensively about AI tooling, posted something related this week. The important skill for working with coding agents isn’t reviewing every line they write. It’s knowing how to verify they did what you asked.

Sometimes that means reading the code. Often it doesn’t.

If you ask an agent to add error handling to a function, you can verify it worked by checking if the error cases are handled. You don’t need to scrutinize every line. Run the code. Throw errors at it. See what happens.

If you ask it to optimize a database query, check the query plan. Time it. You’re not doing code review, you’re doing verification.

This is how experienced developers already work with junior engineers. You don’t micromanage every keystroke. You give clear instructions, verify the outcome, and provide feedback when something’s wrong.

The difference with AI is that it’s simultaneously more capable and more likely to confidently do the wrong thing. A junior dev will ask questions when they’re confused. An AI will generate plausible-looking code that subtly misses the point.

What this means for daily work

Torvalds credited the AI with doing “much of the grunt-work” despite its periodic attempts to surrender. That’s probably the right mental model. These tools can generate debug code, try variations, and handle repetitive tasks. They can’t replace the judgment about what’s worth trying next.

The workflow looks like: you decide what to investigate, the AI writes the instrumentation, you analyze the output, you decide what to try next. Repeat until you either solve it or decide it really is time to write that report.

This isn’t the “AI pair programmer” narrative where the assistant understands your intent and elegantly implements solutions. It’s more like having an intern who can type very fast, doesn’t get tired, but also doesn’t really understand what you’re doing and might try to talk you out of difficult work.

That’s still useful. Fast typing and infinite patience with repetitive tasks actually solve real problems. You just can’t treat it like it’s thinking.

The other thing Torvalds noted: “when I pushed” it kept going. The tools respond to persistence. They’ll give up if you let them. They’ll keep trying if you insist.

Which means the bottleneck isn’t the AI’s capabilities. It’s whether you know enough to recognize when it’s wrong, and whether you’re stubborn enough to keep pushing when it suggests you stop.

Turns out debugging with AI requires the same skill as debugging without it: knowing what you’re looking for and refusing to quit until you find it. The AI just handles more of the typing.