Rubber duck debugging works, and it has always been slightly embarrassing that it works. You explain the problem to an inanimate object, and somewhere in the explaining you find the answer.
The mechanism isn’t mysterious. Holding a problem in your head lets you skip steps, you gesture at the hard part and move on. Saying it out loud doesn’t allow that. Speech is linear and public, even to a duck, so the gap you were stepping over has to be spoken, and the moment you try, you notice it isn’t crossable.
That’s the whole trick: articulation is a debugger.
It is also the least discussed reason voice coding works. Everyone frames it as faster input. Very little of the value is about speed.
Now the duck answers
What’s changed is that the thing you’re explaining to can now respond.
You describe the bug the way you’d describe it to a colleague, the symptom, what you tried, the thing that doesn’t add up. Except this listener has read the codebase, can go and check, and comes back out loud with what it found. You get the clarifying effect of explaining and an answer, from the same sentence.
Anyone who has worked in a good pair knows this shape. You start explaining, you get three sentences in, the other person says “wait, which handler?”, and the question relocates the bug before you finish the thought.
Half of debugging is discovering which question you were actually asking.
Why typing kills this specifically
Here’s the part that matters, and it’s narrower than “typing is slow”.
When you type an explanation, you edit it. You start a sentence, decide it’s badly phrased, delete half, restructure. That editing is exactly where the useful mess gets tidied away, and the useful mess is where the answer was. A tidy prompt is a prompt you’ve already reasoned about, which means you’ve already done the thinking you were hoping to offload.
Speaking is worse prose and better thinking. You say the false start. You say “actually, no, it fails before that.” The correction is part of the utterance, and it’s often the most informative part of the whole thing.
What it looks like in practice
The habit that develops is narrating instead of instructing. Less “fix the auth bug”, more:
“Login works locally but 401s in staging, and I think it’s the cookie domain, except it worked last week and nobody touched that file…”
That’s a bad prompt by every prompt-engineering guideline and a very good description of a problem. It contains the symptom, the hypothesis, and the reason you doubt your own hypothesis, which is the part you’d have deleted while typing.
You wouldn’t type that sentence. You’d type “debug 401 in staging” and throw away the three most useful facts you had.
Try it on the next thing that confuses you
Next time you catch yourself staring at something that doesn’t make sense, say it out loud instead of composing a prompt about it. Include the part where you contradict yourself.
Then let it answer. That’s the half the duck was always missing, the whole loop, rather than a very patient object.
