Most “fix my code” prompts fail because they ask the model to guess instead of investigate. The prompts below force ChatGPT or Claude to reason through the actual failure, not just pattern-match a fix that looks plausible. Use them in order: reproduce, isolate, then fix.
Why Most Debugging Prompts Give You the Wrong Fix
When you paste an error and ask “why is this broken,” the model has to guess at your intent, your data shapes, and what changed recently. It answers with the statistically most common cause of that error message, which is often not your actual bug. Better prompts supply the missing context up front: the traceback, the input that triggered it, and what you expected to happen instead.
Prompt 1: Full Traceback Analysis
“Here is the full traceback and the function it points to. Walk through the call stack from the outermost frame to the innermost, explain what each frame was trying to do, and identify the exact line and condition that caused the exception. Then give the minimal code change that fixes it without altering unrelated behavior. Traceback: [paste]. Code: [paste]”
Prompt 2: Isolate a Silent (Non-Crashing) Bug
“This function runs without errors but returns the wrong result. Expected output for input [X] is [Y], but I’m getting [Z]. Trace through the logic step by step with this exact input, showing the value of each relevant variable at each step, and tell me at which step the value first diverges from what it should be. Code: [paste]”
Prompt 3: Reproduce an Intermittent Bug
“This bug only happens sometimes, not on every run. List every source of non-determinism in this code, race conditions, unordered iteration, external API timing, random seeds, mutable default arguments, and rank them by likelihood of causing this specific symptom: [describe symptom]. Code: [paste]”
Prompt 4: Verify the Fix Doesn’t Break Anything Else
“Here is the original function, the bug, and my proposed fix. Before I apply it, check whether this fix changes behavior for any input that previously worked correctly, and list any edge case my fix does not account for. Original: [paste]. Fix: [paste]”
A Real Example
Instead of “this Python function is broken, fix it,” try: “This function should return the average of a list but returns 0 for lists containing floats between -1 and 1. Expected output for [0.2, 0.4, 0.6] is 0.4, I’m getting 0. Trace the logic step by step with this input and tell me exactly where it diverges.” That level of specificity is what turns a guess into a diagnosis.
Where This Fits With Your Other Prompts
Once the bug is fixed, run it through our AI code review prompts to make sure the fix didn’t introduce a new issue, and check our complete guide to prompts for programming for the rest of the workflow, from writing tests to refactoring. For Python-specific style and exception-handling conventions these prompts assume, Python’s official documentation on errors and exceptions is the reference these techniques build on.
Prompt: Root-Causing a Flaky Test
A test that fails intermittently is one of the more frustrating debugging scenarios, because the obvious approach — reading the failing assertion — usually doesn’t explain why it only fails sometimes. The cause is almost always a hidden dependency: test ordering, shared mutable state, a race condition, or an unmocked call to real time or randomness.
Prompt: “This test fails intermittently, not on every run: [paste test code and failure]. List every source of non-determinism you can find in this test and the code it exercises: shared state between tests, reliance on real system time or randomness without a fixed seed, dependence on test execution order, or any async/concurrent code that isn’t properly awaited or synchronized. For each one found, suggest the specific fix.”
Naming the specific categories of non-determinism up front, rather than asking generically “why does this fail sometimes,” gives the model a checklist to work through instead of guessing — which produces a noticeably more useful answer on this particular class of bug.
Prompt: Explaining an Unfamiliar Traceback in Plain English
When you’re working in a library or framework you don’t know well, the hardest part of debugging is often just understanding what the traceback is telling you, before you can even start fixing it. This prompt asks for a plain-English walkthrough before jumping to a fix.
Prompt: “Here is a traceback I don’t understand: [paste full traceback]. Walk through it from the bottom line up: what the final error means in plain English, which line in my code triggered it, and what the intermediate frames above it show about how execution got there. Don’t suggest a fix yet — I want to understand what’s happening first.”
Separating the explanation step from the fix step is deliberate. Asking for both at once tends to produce a fix you don’t fully understand and might apply incorrectly next time the same error shows up in a different context.
FAQ
Do I need to paste the whole file or just the function?
Paste the function plus any function it directly calls. Pasting an entire large file dilutes the model’s attention and tends to produce vaguer answers.
What if there’s no traceback, just wrong output?
Use Prompt 2. Give one concrete input and the exact expected vs. actual output, then ask for a step-by-step trace. This is the single highest-value habit in this guide.
Can these prompts debug other languages besides Python?
Yes. The structure, traceback first, then isolate with a concrete input, then verify the fix, works the same way in JavaScript, Java, or Go. Only the traceback format changes.
