The Rubber Duck Debugger: Fix Your Code by Explaining It Out Loud

<p>Rubber duck debugging is one of the oldest tricks in software development: explain your code line-by-line to an inanimate object — a rubber duck — and the act of narrating it forces you to spot the bug yourself. The technique works because most bugs live in the gap between what you think the code does and what it actually does. Narrating forces that gap into view.</p> <p>This prompt turns Claude or GPT-4o into a patient, Socratic rubber duck. Feed it your broken code and a description of the problem. Instead of handing you a fix, it walks you through the debugging method systematically — making you think through each step until you find the error yourself.</p> <h2>Why This Works Better Than Just Asking for the Fix</h2> <p>When an AI hands you a corrected version of your code, two things happen: the immediate problem is solved, and you learn nothing. The next time you write a similar bug — and you will — you're just as likely to miss it again.</p> <p>The Socratic approach forces you to build a mental model of the execution. You have to articulate what you expected at each step, then compare it to what actually happened. That articulation is where the learning happens. In most cases, developers find their own bug before the AI even needs to intervene — the mere act of explaining the code out loud is enough.</p> <p>It's also faster than you might expect. For logic errors and off-by-one bugs, structured questioning usually reaches the root cause in 3-5 exchanges rather than the 10-20 rounds of "I tried that and it still doesn't work" that AI-assisted debugging often devolves into.</p> <h2>The Prompt</h2> <p>Copy this prompt, replace the placeholders, and paste it into Claude or GPT-4o:</p> <pre><code>You are a rubber duck debugging coach. I'm going to show you code that isn't working. Do NOT fix the bug for me. Guide me to find it myself using questions.

Follow this coaching sequence: 1. Ask me to explain what the code is SUPPOSED to do, in plain English — line by line if needed. 2. Ask me to trace through what it ACTUALLY does, step by step. 3. Identify the first point where my description and the actual behavior diverge. 4. At that point, ask: "What did you EXPECT here?" and "What ACTUALLY happened?" 5. If I'm stuck after two attempts, give me ONE focused hint — not the answer. 6. Only reveal the fix after I've identified the bug myself, or after I explicitly give up and ask for it.

My broken code: [PASTE YOUR CODE HERE]

Language/framework: [e.g. Python 3.11, React 18, Go 1.21]

Error message or unexpected behavior: [DESCRIBE WHAT'S WRONG — include the exact error if there is one]</code></pre> <h2>Tips for Getting the Most Out of It</h2> <p><strong>Be precise about the error.</strong> "It doesn't work" gives the AI nothing to anchor on. Paste the exact error message, stack trace, or describe the exact wrong output (e.g., "returns 5, expected 7").</p> <p><strong>Don't skip the language/framework line.</strong> A null pointer behavior in Go is different from a None comparison bug in Python. The framework context changes which questions the AI will ask.</p> <p><strong>Resist the urge to ask for the fix.</strong> The prompt instructs the AI not to give it to you, and the AI will comply. If you feel impatient, that impatience is the point — debugging discomfort builds the pattern recognition that prevents future bugs.</p> <p><strong>Works best for:</strong> logic errors, off-by-one bugs, async/await timing issues, state mutation bugs, wrong return values. Less useful for environment-level issues (dependency conflicts, auth configuration) where the problem isn't in your code logic at all.</p>