Debugging Python with AI Assistance

'I'm getting an error when processing orders' is a genuine, honest description of the symptom — and it discards almost all of the specific, structured information that would actually let anyone (human colleague or AI assistant) diagnose the root cause efficiently. A full Python traceback is precise, structured data: the exact exception type and message (AttributeError: 'NoneType' object has no attribute 'price'), the exact file and line number where it originated, and the full call chain of how execution reached that point (process_order calling calculate_total, which is where the actual failure occurred).

Pasting this full, exact traceback — not a summary, not a paraphrase — gives an AI assistant the same specific, structured information a skilled human debugger would want first: not 'something went wrong somewhere in order processing', but 'specifically, calculate_total at pricing.py line 18 tried to access .price on something that turned out to be None.' This precision alone often narrows the diagnosis dramatically, sometimes to the point of near-certainty about the actual cause, compared to a vague symptom description that could plausibly stem from dozens of different underlying issues.

This principle directly extends what this curriculum's Exception Hierarchy and Logging Best Practices lessons established about tracebacks generally — they are the single most information-dense artifact available immediately after a failure, and discarding that information (by paraphrasing rather than pasting it exactly) throws away precisely the detail most likely to matter, whether you're debugging alone, asking a human colleague, or working with an AI assistant.

Pasting an entire 200-line order-processing pipeline when only a specific two-line interaction actually triggers the bug buries the relevant logic in a large amount of irrelevant surrounding code — both for a human reviewer and for an AI assistant, more code to read means more potential distractions and a harder task of identifying which specific part is actually relevant to the failure at hand. A minimal reproduction — the smallest possible input and code that still triggers the exact same bug — strips away everything not actually necessary to demonstrate the failure.

items = [Item(price=10, qty=2), None] followed by a direct call to calculate_total(items) reproduces the exact AttributeError in two lines, isolating precisely what triggers it (a None in the items list) without any of the surrounding order-processing pipeline's unrelated logic, database calls, or configuration cluttering the picture. This isn't just more convenient to share — it's often genuinely diagnostic in its own right: the *process* of reducing a bug to its minimal reproduction frequently reveals the actual cause directly, even before an AI assistant (or a human colleague) says anything at all, since narrowing down 'which specific input triggers this' is itself a core debugging technique.

This mirrors, directly, the same 'minimal relevant code' principle already established in this curriculum's earlier debugging-adjacent guidance for AI-assisted code generation — providing focused, relevant context rather than large, unfiltered volumes of surrounding material consistently produces more useful, more targeted results, whether the goal is generating new code or diagnosing why existing code is failing.

A traceback and a minimal reproduction together tell you (and an AI assistant) precisely *how* the code failed — but not necessarily *what it was actually supposed to do* in the situation that caused the failure. calculate_total([Item(price=10, qty=2), None]) crashing with AttributeError is the *symptom*; the *actual bug* is that the function has no logic to handle a None item in the list at all, and whether that's a genuine bug (the function should skip None items) or a legitimate expectation being violated (the caller should never pass a None item in the first place) is not something the traceback alone can tell you or an AI assistant.

Explicitly stating 'I expected calculate_total() to skip any None items in the list and sum only the valid ones — instead it crashes on the None with an AttributeError' directly surfaces the actual, specific requirement the code fails to meet, converting a vague 'why does this crash' into a precise, actionable 'this function is missing a specific piece of logic: skip None items before accessing .price.' This single sentence is frequently the exact detail that turns a plausible-but-generic suggested fix (like wrapping the whole function in a broad try/except, which the Advanced Error Handling section would rightly flag as a poor, over-broad response) into a precise, targeted fix that actually addresses the real underlying requirement.

This three-part discipline — full traceback, minimal reproduction, explicit expected-vs-actual — mirrors almost exactly what a well-written bug report to a human colleague should contain, and for the identical underlying reason: neither a human colleague nor an AI assistant has ambient, automatic access to what you were actually thinking the code should do; that context has to be stated explicitly, every time, for either to help you effectively.

"It's not working" gets a guess. A full traceback, a minimal reproduction, and a clear expected-vs-actual statement gets an actual diagnosis.

The FULL traceback -- not a paraphrase -- contains the specific line numbers and call chain that are often the actual key to the diagnosis.

Checkpoint: Why does pasting the FULL traceback (not a paraphrase like "I got an AttributeError") matter for getting a useful diagnosis?

• →The exact line numbers, file names, and call chain in a full traceback often contain the specific clue needed to pinpoint the actual failure, which a paraphrase loses
• →It's mainly just providing more text volume, without specific additional value

A MINIMAL reproduction -- the smallest input that triggers the bug -- removes irrelevant noise and lets the assistant focus on the actual failing logic.

Explicitly stating EXPECTED vs ACTUAL behavior is often the single detail that reveals the real bug, not just its visible symptom.

Checkpoint: Why can explicitly stating "expected vs actual" behavior reveal the real bug, not just its visible symptom?

• →It makes the actual intended requirement explicit (e.g. "should skip None items"), which the code visibly fails to implement -- revealing a missing piece of logic, not just where it crashes
• →There is no meaningful difference between stating this and just describing the error message alone

AI debugging finds why code is wrong; AI Documentation is next, using the same collaborative discipline to explain code that's already correct.

Extract a Real Line Number. Finish extract_line_number(): a full traceback carries the exact failing line number.