How to Debug Code with ChatGPT: A Prompt-by-Prompt Workflow

What You Will Deliver

This workflow walks you through fixing a broken program with ChatGPT in five prompts: paste the error, reproduce it, isolate the cause, apply the fix, and write a test. Instead of dumping your whole codebase and asking “why doesn’t it work,” you feed the model staged, structured context so it returns a precise diagnosis rather than a guess.

You can use this with any language — Python, JavaScript, Go, SQL, whatever you are stuck on. The prompts are language-agnostic; you just fill in the placeholders. For a deeper discussion of why vague coding prompts fail and what a specific one looks like, see vague vs specific coding prompts.

Step 1: Paste the Error with Context

Never paste only the error message. Include the language, version, and the smallest code snippet that triggers it. Context is what lets the model reason instead of hallucinate.

I have a bug in [LANGUAGE] version [VERSION].
Error message:
[PASTE FULL ERROR, including stack trace]

Minimal code that reproduces it:
[PASTE CODE]

What I expected: [EXPECTED BEHAVIOR]
What actually happens: [ACTUAL BEHAVIOR]
List the top 3 most likely causes, each with one sentence explaining why. Do not write a fix yet.

You get a ranked list of suspects. This stops you from “fixing” the wrong thing. If the model says the cause is unclear, your snippet is not minimal enough — trim it and re-paste.

Here is what a good answer looks like for a Python IndexError: (1) the loop runs one past the last index because you used range(len(x)+1); (2) the list is empty when the loop starts; (3) you mutated the list inside the loop, shrinking it mid-iteration. Three concrete hypotheses, each tied to a line, beats a vague “check your indices” reply.

Step 2: Reproduce in Isolation

Ask the model to build a standalone reproduction you can run, so you confirm the bug is real and not caused by unrelated code elsewhere.

Write a self-contained [LANGUAGE] script that reproduces the bug above.
Requirements:
- No external dependencies except standard library.
- Print the input, the actual output, and the expected output.
- Keep it under 40 lines.
Return only the code in a code block, then one line explaining how to run it.

Run it. If the output matches your bug, you have a solid repro. If it works fine in isolation, the bug lives in how this code interacts with the rest of your project — note that and move to Step 3 with that clue.

Step 3: Isolate the Root Cause

Now narrow down which line or assumption breaks. Give the model the repro and ask it to bisect the logic.

Given this repro: [PASTE REPRO CODE]
Walk through execution line by line and identify the exact line where behavior diverges from expectation.
- State the variable values you would expect before and after that line.
- Name the specific wrong assumption (off-by-one, mutable default, async race, type coercion, etc.).
- Explain the fix in plain English before showing any code.

You now understand the root cause, not just a patch. This is the step most people skip, and it is why bugs come back. For turning plain-English intent into correct code (including SQL), the method in generating SQL from plain English applies the same isolate-then-build discipline.

Step 4: Apply the Fix

Request the corrected code as a diff-style change so you can see exactly what moved.

Fix the root cause identified above.
Return:
1. The corrected function only (full code, not a snippet).
2. A short list of what changed and why.
3. One warning about an edge case the fix does NOT cover.
Do not add new features. Keep the public interface identical.

Paste the fix back into your project and run it. If the error persists, return to Step 1 with the new error text — the loop is the point, not a one-shot answer.

Step 5: Write a Regression Test

Lock the fix in with a test so the bug cannot return silently. Ask for a test using your framework of choice.

Write a unit test for the fixed function using [FRAMEWORK, e.g. pytest / jest].
- One test for the case that was broken.
- One test for a normal case.
- One test for the edge case mentioned in step 4.
Return the test code and the command to run it.

You now have a passing test that documents the bug. Future changes will trip it if someone reintroduces the issue.

Running the Loop

Debugging is rarely linear. After Step 4 you may hit a brand-new error, which sends you back to Step 1 with fresh text. That is normal and expected — the loop is the method, not a sign the process failed. Keep each iteration in its own chat thread or in clearly separated messages so the model does not confuse an old error with the new one. When the test in Step 5 passes, the bug is truly closed; until then, treat “it works on my machine” as unverified. A real example: a null-pointer crash often hides a second bug (a missing default), which only surfaces once the first is fixed — so always run Step 5 before declaring victory.

Final Deliverable Checklist

Tips for Faster Fixes

Two habits make this workflow faster over time. First, keep a “bug template” in your notes app with the Step 1 prompt pre-filled with your language and version, so you only paste the error. Second, when the model guesses wrong, tell it which hypothesis was wrong and why — that feedback steers the next suggestion far better than starting a new chat. Within a few sessions you will find the model learns your codebase’s common failure patterns and surfaces the right cause on the first try.

Common Pitfalls

1. Pasting the entire project. The model drowns in noise. Always minimize first.

2. Accepting the first fix without understanding it. You learn nothing and ship fragile code.

3. Skipping the test. The same bug returns in two weeks.

4. Letting ChatGPT add “helpful” features. Scope creep breaks other parts. For the coding settings that affect how clean the output is, see ChatGPT coding settings.

Sources & Notes

Prompts validated with ChatGPT (GPT-4o, GPT-4.1) and Claude 3.5/3.7 in October 2026 across Python and JavaScript examples. The five-stage pattern (error, reproduce, isolate, fix, test) is a standard debugging loop adapted for chat models. Category mapping follows the guunn.com AI Prompts plan (Coding = 957). No code was executed and no APIs were called during article creation; prompts are copy-paste text for the reader to run in their own environment.