ChatGPT for Debugging: How I Use It as a Rubber Duck That Talks Back

I've been writing code for about eleven years and I still get stuck on bugs. Not the "this took me five minutes" kind — the "I've been staring at this for four hours and I cannot see it anymore" kind.

The classic solution is rubber duck debugging. You explain the problem out loud to an inanimate object, and the act of explaining it forces you to organize your thinking, and somewhere in the middle of that explanation you realize what's wrong. It works surprisingly well.

ChatGPT is a rubber duck that pushes back. And the difference matters more than I expected.

Why Most Developers Use It Wrong

The most common debugging prompt I see developers use is something like: "I'm getting this error: [paste error message]. What's wrong?"

That prompt produces generic answers. Stack Overflow answers. "Check that your environment variables are set correctly" and "make sure your dependencies are installed." You've already done those things. The answer isn't useful.

The problem isn't ChatGPT. The problem is that you've given it almost no information. An error message is the last thing that happened — it's not the context you need to diagnose why it happened. Without context, ChatGPT gives you generic advice because generic advice is the only thing that fits.

The fix is giving it more. A lot more.

The Context Dump Pattern

This is the core technique. Before I paste anything into ChatGPT, I answer four questions:

1. What is this function/code supposed to do?
2. What inputs am I passing it?
3. What did I expect to happen?
4. What actually happened?
5. What have I already tried?

Then I write all of that in the prompt. This sounds like more work, but it usually takes two minutes, and it almost always produces a useful answer on the first try.

Prompt: "I'm debugging a Node.js function that processes webhook events from Stripe. The function receives a raw request body, validates the Stripe signature, then inserts an event record into Postgres. Input: POST request with a valid Stripe-Signature header and a JSON body. Expected: the signature validates and the record inserts. Actual: the signature validation always fails, throwing 'No signatures found matching the expected signature for payload.' I've already checked: the webhook secret is correct (copy-pasted from dashboard), the raw body is being preserved (using express.raw() middleware), and the error happens on every request, not intermittently. Here's the relevant code: [paste code]"

That prompt gets a diagnosis, not a suggestion to check the docs. In this specific case, ChatGPT caught that I was parsing the body as JSON before the signature check, which was mutating the raw bytes the HMAC validation needs. Two minutes to write the prompt, thirty seconds to read the answer.

Log Analysis: Pattern Recognition at Scale

Reading logs is tedious, and the signal you need is usually buried in volume. Fifty lines of logs contains maybe three relevant ones. ChatGPT is fast at this kind of pattern matching.

Prompt: "Here are 60 lines of application logs from a crash that happened in production. The service is a Python FastAPI app that processes image uploads. I need to understand: what sequence of events led to the crash, which log line is the actual root cause vs. downstream effects, and whether there are any patterns suggesting this could recur. [paste logs]"

The key framing here is "root cause vs. downstream effects." Most error chains have one source and three symptoms. Reviewers (human or AI) will fixate on the last visible error, which is often a symptom. Asking explicitly for root cause forces a different kind of analysis.

Intermittent Failures: Systematic Hypothesis Generation

Intermittent failures are the worst bugs to debug because you can't reproduce them reliably. You can't print-debug your way through them. What you need is a list of plausible hypotheses you can systematically rule out.

Prompt: "I have an intermittent bug in a TypeScript service that calls an external API. The failure rate is roughly 2%, always returning a timeout, but only during business hours and only under load. It does not fail in staging. I've already ruled out: rate limiting (we're well under the limit), DNS resolution issues (no errors in that layer), and the external API's status page (clean). Generate a prioritized list of hypotheses for what could cause this pattern — timeout, load-dependent, time-of-day, works in staging — and suggest how to test or instrument each one."

"Prioritized list of hypotheses" is the key phrase. You want something testable, not a general description of timeout debugging.

Stack Traces for Unfamiliar Libraries

Nothing makes you feel like a junior developer faster than hitting a cryptic stack trace in a library you've never debugged before. The error is somewhere in 12 layers of framework internals and you don't know which layer is actually wrong.

Prompt: "Here's a stack trace from a Python Django application. I'm relatively unfamiliar with Django's request lifecycle. Walk me through what each layer of this stack trace is doing, identify where in the stack the actual error likely originated vs. where it surfaced, and explain what I should look at first in my own code. Stack trace: [paste trace]"

This prompt has saved me enormous amounts of time when I'm working in a framework I don't know well. It's also genuinely educational — reading the explanation a few times and you start to internalize the framework's internals.

The "Explain It Like I'm New to This" Prompt

Sometimes the problem isn't that you can't find the bug — it's that you don't understand what the error actually means. Especially with distributed systems errors, cryptic database messages, or framework-specific exceptions.

Prompt: "Explain this error message like I'm a junior developer who's never worked with this framework before: [paste error]. Then tell me: what state does this error indicate the system is in, what likely caused it, and what's the simplest thing to check first."

The "what state does this error indicate" framing is powerful. Errors are symptoms of state. Understanding the state is more useful than Googling the error string.

The Underlying Technique

Every prompt above follows the same logic: give ChatGPT enough context to reason about your specific problem, not the general class of problem. The more specific the input, the more specific and useful the output.

Rubber duck debugging works because explaining your problem forces you to organize your thinking. ChatGPT gives you the same benefit and then responds with hypotheses you hadn't considered. That's the combination that actually shortens debugging sessions.

If you want a complete set of prompts structured this way — covering code review, system design, documentation, and more — I've compiled 200 of them tuned for daily developer work.

Get 200 ChatGPT Prompts for Developers — $19 instant download