promptdojo_

raise — failing loudly on purpose — step 8 of 8

ch 03 · read the failure8/8

Going deeper: make your AI assistant explain it three ways

This chapter gave you the reading order (bottom-up), the fingerprints (the error classes), and the discipline (catch what you can handle, raise loudly for the rest). The habit that carries all of it into your daily work is knowing how to put your AI assistant on the case without handing it the steering wheel.

The paste-able prompt

Next time a script blows up, copy the entire traceback plus the relevant code, and paste this with it:

Here is a Python traceback and the code that produced it.

1. Explain the error literally: walk the traceback bottom-up,
   frame by frame, and tell me what each line says.
2. Explain it in plain English: what was my program trying to do
   at the moment it died, and what assumption turned out false?
3. Give me the most likely fix as the smallest possible change —
   and name which line the *cause* is on, not just where it crashed.

Before I apply anything: tell me one print statement I can add to
confirm the diagnosis first.

The three-ways structure isn't decoration. Each pass catches a different failure:

  • Pass 1 (literal) forces the assistant to actually read the traceback in order instead of pattern-matching on the last line. If its frame-by-frame walk contradicts what you read yourself, you've caught a misdiagnosis before it becomes a bad fix.
  • Pass 2 (plain English) is the one you understand. If the plain-English story doesn't match what you thought the program was doing, the bug is usually in your mental model — the most valuable find of all.
  • Pass 3 (smallest fix) stops the rewrite-everything reflex. You've seen it all chapter: the model that can't find the bug will happily replace the function. Smallest-possible-change keeps the fix reviewable by you.

The verification habit

The last line of the prompt is the part most people skip and the part that makes this professional-grade: ask for a print that confirms the diagnosis, run it first, and only then apply the fix.

The editor on the right shows the move in miniature. The diagnosis says a key is missing — so before changing anything, you print the dict's keys and check. Confirmed? Apply the fix and re-run, and watch the output actually change. Not confirmed? You just saved yourself from "fixing" the wrong function, and you paste the print's output back into the conversation as evidence.

Never accept a fix whose effect you can't see change the output. That one rule is the difference between using an assistant and being used by one.

The reference that never hallucinates

Two bookmarks, both official and vendor-neutral:

  • docs.python.org/3/tutorial/errors.html — the tutorial chapter on errors and exceptions, including try/except/else/finally shapes this course didn't need yet.
  • docs.python.org/3/library/exceptions.html — every built-in exception class, in one hierarchy. When your assistant names an exception you don't recognize, check it here: thirty seconds, and you'll know exactly where it sits between Exception and the five fingerprints you already read on sight.

Run the editor, read the confirmation trace, and take the prompt with you. The next wall of red text you see is a map — and now you have both a reading order and a navigator.

read, then continue.