There is a well-loved debugging technique with a silly name: rubber-duck debugging, where you explain your problem, line by line, to an inanimate rubber duck. It works far more often than it has any right to, and understanding why reveals something about problem-solving — and about how AI assistants can help even when they say nothing useful.
The magic is not in the duck. It is in the explaining.
Why explaining works
To explain a problem clearly, you must slow down and articulate each step and assumption, and that act of forcing your vague mental model into explicit words frequently exposes the flaw. The moment you say "and then this should be true..." you often notice that it is not. The solution appears not because the duck responded, but because you were made to think carefully.
Confusion thrives in the gaps of a fuzzy mental model; explanation drags those gaps into the light.
The AI as a very patient duck
An AI assistant makes an excellent rubber duck, with a bonus: it can also respond. Writing out your problem to ask it forces the same clarifying articulation, and you will sometimes solve the issue in the act of describing it, before ever reading a reply. When you do read a reply, it may add a useful angle.
Either way, the discipline of stating the problem fully is doing much of the work — the assistant just gives that discipline a destination.
Making it a habit
The practical lesson is to reach for explanation whenever you are stuck: describe the problem, your expectations, and what actually happens, in plain words, to a colleague, a duck, an assistant, or even a comment you write and delete. The goal is to externalise your thinking so its flaws become visible.
It costs nothing and resolves a surprising share of bugs before help even arrives. When stuck, do not just stare — explain.
Why explaining a problem out loud works even when the listener says nothing at all
The classic rubber duck technique works because articulating a problem in complete, precise sentences forces a level of explicit, structured thinking that silent, internal reasoning tends to skip over — a mental model held loosely in one's head can gloss over an inconsistency that becomes immediately obvious the moment it has to be stated as a coherent, complete sentence out loud, which is exactly why the technique works regardless of whether the listener is a literal rubber duck, a patient colleague, or nothing at all.
Why an AI assistant is a genuinely different kind of duck, not just a more expensive one
Unlike a literal rubber duck, an AI assistant can actually respond, ask a clarifying question, or point out an inconsistency directly, which means the technique gains a genuine second half beyond simply forcing better articulation — the value here specifically comes from the act of explaining clearly, which is exactly the same value a silent duck provides, plus an additional, real chance that the listener catches something the explainer's own explanation reveals, which a literal duck can never do.
Why writing the explanation down is often more effective than speaking it aloud
Typing out a problem description to paste into an AI assistant forces an even higher level of precision than speaking aloud does, since writing tends to demand more complete, well-formed sentences than speech typically does — many developers report solving their own problem partway through typing out the explanation, before ever actually sending the message, which is the purest form of the rubber-duck effect: the mere act of formulating the explanation precisely enough to be understood is what surfaced the answer, independent of whether any response was ever actually needed.
Why this technique specifically helps with a category of bug that resists direct debugging
A bug caused by a flawed underlying assumption, rather than a simple typo or an off-by-one error a debugger would immediately reveal, is exactly the category rubber-duck explanation is most effective against, since stepping through code line by line with a debugger shows what the code does but not what the developer wrongly assumed it would do — explaining the intended behavior out loud, in full, is what surfaces the gap between the actual code and the mistaken mental model behind it, a gap a debugger's step-by-step execution view was never designed to reveal on its own.
Why the technique works even better when forced to explain to someone with no context at all
Explaining a bug to a colleague already familiar with the codebase allows shortcuts and unstated assumptions to pass unchallenged, while explaining the same bug as though to someone with zero prior context forces every single assumption to be stated explicitly — an AI assistant, having no actual memory of the specific codebase unless explicitly given it, naturally forces this zero-context framing, which is precisely why explaining a problem to one is often more revealing than explaining it to an already-familiar human colleague.
Why this technique is complementary to, not a replacement for, an actual debugger
Rubber-duck explanation surfaces a flawed mental model or assumption; a debugger reveals actual runtime state and execution flow — these are two genuinely different diagnostic tools addressing two different categories of bug, and a mature debugging practice reaches for whichever one matches the actual suspected problem, or both together, rather than treating either as a universal substitute for the other.
Why some developers keep a written debugging log as a permanent, searchable duck
Writing out debugging explanations in a persistent log rather than a disposable chat window creates a searchable record of past reasoning that can be revisited when a similar bug reappears later — extending the rubber-duck habit into a permanent artifact rather than a one-off, forgotten conversation captures value beyond the immediate moment of explaining the problem.
Why teams sometimes institutionalize this technique as a formal step before escalating for help
Some teams require an engineer to write out a clear problem explanation, in the rubber-duck style this article describes, before posting a question in a shared help channel — this simple, lightweight requirement filters out a meaningful fraction of questions that get answered by the explainer themselves partway through writing them, reducing interruption to the rest of the team while still leaving genuinely hard, unresolved questions to actually reach a human who can help.
Why this technique works even for problems that feel too embarrassing to ask about
A developer often hesitates to interrupt a colleague with a question that feels like it should have an obvious answer, and this exact hesitation is precisely the case where explaining the problem to a duck, or an AI assistant with infinite patience and no judgment, provides value with zero social cost — removing the embarrassment barrier is itself a meaningful part of why the technique works as well as it does in practice.
Why this technique scales down to solo developers just as well as it scales up to teams
A solo developer with no colleague or team to explain a problem to loses none of this technique's value, since the mechanism that makes it work — the discipline of articulating a problem precisely and completely — requires no listener capable of actually understanding at all, which is exactly why a literal inanimate rubber duck works in the first place, and why an AI assistant is simply a more capable, always-available version of the same fundamentally solo technique.
Why this technique's simplicity is exactly what makes it easy to underestimate and skip
A technique this simple — merely explaining a problem out loud or in writing — is easy to dismiss as too basic to bother with, especially under time pressure when reaching directly for a debugger or a search engine feels more like real progress; recognizing that this apparent simplicity is precisely what makes the technique so consistently effective, rather than evidence it is somehow beneath serious use, is worth remembering the next time a stubborn bug tempts skipping straight past it.
Why this remains one of the cheapest debugging techniques ever devised, cost included
No tool purchase, no configuration, and no specialized skill is required to explain a problem out loud or in writing, which is precisely why this technique has persisted essentially unchanged for decades across an industry that has otherwise transformed its tooling many times over — its cost is close to zero and its payoff, when it works, can save hours, an asymmetry that alone justifies reaching for it far more often than most developers actually do.
Why this technique's value compounds the more often it becomes an automatic first response
A developer who reaches for this technique only as a last resort, after already trying everything else, gets far less value from it than one who reaches for it immediately, as a genuine first response to feeling stuck — building the habit of explaining a problem clearly before trying anything else, rather than after exhausting other options, captures the technique's benefit at the point it is cheapest and most useful to apply.
Why naming the technique explicitly, even jokingly, helps a team actually remember to use it
Giving this technique an explicit, memorable name, whimsical as it is, does real work beyond being a fun bit of programming folklore: a team that has a shared name for the practice can invoke it directly — 'have you tried rubber-ducking this' — which lowers the friction of suggesting it compared to explaining the whole technique from scratch every single time it might actually help.
Why this technique's endurance across decades of changing tools is itself the strongest endorsement
Debuggers, IDEs, static analyzers, and now AI assistants have each transformed how developers work, and this simple, low-tech technique has remained useful and relevant through every single one of those transformations without needing to change at all — that endurance, unlike almost any other specific tool or technique from decades past, is itself the clearest evidence that it addresses something genuinely fundamental about how understanding actually gets built, not a passing fad tied to any particular generation of tooling.
Why writing the explanation as if for a formal bug report clarifies thinking fastest
Structuring an explanation the way a formal bug report would be written — expected behavior, actual behavior, steps that lead to the discrepancy — imposes a useful, disciplined structure on what might otherwise be a rambling, unfocused explanation, and that structure alone often does more to surface the actual gap in reasoning than a looser, conversational explanation would.
Why this technique deserves a place in a formal onboarding checklist for new engineers
New engineers unfamiliar with a team's debugging culture often default to interrupting a colleague at the first sign of being stuck, and explicitly introducing this technique during onboarding, rather than leaving it to be discovered informally later, gives them a genuinely useful first step to try before escalating.