*Published March 24, 2026* --- I started asking Claude why it gave me wrong output instead of reprompting. Not as a rhetorical exercise. As a direct question: "Explain step by step what you did to produce that output and what sources you consulted." Then I'd ask why it skipped the source I expected it to use. Then why it was possible to skip that source at all. Three questions. Same chain Toyota's production engineers have run since the 1950s. [The Five Whys](https://grokipedia.com/page/Five_whys), the simplest root-cause analysis technique in industrial engineering, turns out to be the most useful debugging tool for AI systems that nobody is using. Almost every developer I watch treats AI failures as prompting failures. Rephrase, retry, hope. This article is about what happens when you stop doing that. --- ## The Retry Trap The instinct when Claude produces wrong output is to retry with better instructions. This is the equivalent of replacing the blown fuse without asking why it blew. Retrying treats every failure as a prompting problem. Sometimes it is. But often the failure has nothing to do with your prompt. The model ignored a directive it had access to. It hallucinated a path instead of running another search. It improvised a format from memory instead of reading the specification that was right there in its context. Retrying with a better prompt fixes none of these. You get different wrong output, or the same wrong output with more confidence. The root cause is still there. --- ## The Chain The technique is simple. When Claude gives you sub-optimal output, you start a chain: **Why #1: "Why did you give me this output?"** Claude will explain its reasoning. You see the logic path, and often the failure point is visible on first read. Maybe it says: "I synthesized from the document's title and first paragraph." Translation: it didn't read the full document. Root cause found in one question. **Why #2: "There's a specification for this. Why didn't you follow it?"** The specification might be a skill file, a README, a style guide, a doc comment. Any documented source of truth the AI had access to. Now the model has to confront the gap between what it did and what it should have done. Common answers: - "I didn't read the skill file before generating output." → It skipped a documented step. - "I was following the format from a similar task I did earlier in this conversation." → It relied on in-context pattern matching instead of the canonical source. - "I wasn't aware that skill file existed." → It didn't search for relevant guidance before acting. **Why #3: "Why didn't you read the skill file first?"** The answer often reveals a process failure: - "The conversation didn't reference the skill, so I didn't know to look for it." → Your command or workflow doesn't link to the skill it depends on. - "I prioritized speed over thoroughness." → The model made a tradeoff you didn't authorize. - "I read a different file that seemed relevant and used that format instead." → There's ambiguity in your documentation that the model resolved wrong. By the third why, you're usually past the specific failure and into the system that allowed it. --- ## A Real Chain February 2026. I run `/morning`, which delegates to `/burnout` for a check-in assessment. Claude produces a burnout check-in with a 1-5 scale, three dimensions, and no git-based attention analysis. Every detail wrong. If I'd retried ("do the burnout check-in again, but correctly") I'd get a slightly different wrong output. Instead: **Why did you produce the wrong format?** "I generated the burnout check-in based on my understanding of burnout assessment frameworks." **The `/burnout` command has a specific skill file with the exact scale, dimensions, and methodology. Why didn't you read it?** "I didn't read the burnout skill file before generating the output. I relied on general knowledge of burnout assessment." **Why not? The command file references the skill.** "I should have read the command file first, which would have pointed me to the skill file. I jumped straight to generating output without reading the specification." Root cause: Claude skipped the read-before-execute step. The root cause was process, not prompting or model capability. The same kind of process problem a junior developer makes when they code from memory instead of reading the spec. The fix wasn't a better prompt. It was a persistent rule in the AI's configuration: "When a command delegates to another command or references a skill, READ the target file BEFORE executing." That rule prevents the entire category of failure, not just this instance. A fair objection: the model is confabulating its reasoning. It doesn't have a real execution trace. When it says "I prioritized speed," it didn't make a speed-vs-thoroughness calculation. It's rationalizing after the fact. This is true. But the rationalization points toward the structural gap even when the specific explanation is wrong. The model didn't read the file, and the system allowed that. Whether it "chose" not to or simply didn't is irrelevant to the fix. A rubber duck can't tell you which file it skipped. The model can. That signal, even filtered through confabulation, points you to the part of your system that needs a guardrail. You're debugging the system around the model, not the model itself. --- ## The Taxonomy of Root Causes After enough of these chains, three categories account for nearly every failure I've seen. **Skipped Read.** The model had access to the right information and didn't read it. This is the most common failure. The information was there: a skill file, a convention document, a referenced command. The model jumped to output without loading the spec. Stale context is a variant: the model read the right file in a previous conversation and is working from memory instead of a fresh read. Either way, the system allowed the model to skip a read step, and the fix is making that step non-optional. **Priority Conflict.** Two directives compete and the model resolved the conflict silently. Your configuration says "be concise." Your skill file says "include all five layers." The model picked concise and dropped layers without telling you. The dangerous part isn't the wrong choice. It's the silence. You don't know a conflict existed until the output is wrong. **Capability Boundary.** The model can't do what you asked. It hallucinated a file path because finding the real one required too many searches. It produced a plausible-sounding but wrong answer because the task exceeded its reasoning capacity for that context. This is the only category where retrying is useless, full stop. The fix is structural: break the task into smaller pieces, provide more scaffolding, or do that piece manually. | Root Cause | Diagnostic Signal | Fix | |---|---|---| | Skipped Read | "I used general knowledge" / "I wasn't aware of that file" | Make read steps non-optional before generation | | Priority Conflict | Output silently drops a requirement | Make priorities explicit in documentation | | Capability Boundary | Output is plausible but fabricated | Break the task smaller, or do it manually | --- ## How to Start You don't need a configuration system, skill files, or any infrastructure. Next time your AI gives you wrong output, instead of rephrasing your prompt, type: *"Before I ask you to try again, explain step by step what you did to produce that output and what sources you consulted."* Then ask why it didn't consult the thing you expected it to consult. That's it. Two questions. You'll either find the root cause or learn something about your own assumptions that's worth knowing. If you keep doing this, three things shift. Your documentation gets better, because every root cause that ends at "ambiguous docs" leads to a specific edit, and each rule has a scar behind it. Your failures get more interesting: the easy ones stop recurring, and what's left are the hard problems. And you stop retrying, because you know that most failures aren't prompting failures. [Mechanical sympathy](https://para.ngpcloud.org/2+Resources/Topics/Software+Craftsmanship/Infrastructure+Mechanical+Sympathy) in daily practice is not an abstract understanding of transformer architecture. It's a practitioner's catalog of failure modes, built one diagnosis at a time, that lets you predict what the AI will get wrong before it gets it wrong. [The Five Whys](https://grokipedia.com/page/Five_whys) didn't need modification for AI. The technique was already designed for systems you operate but don't fully understand.