Why rubber-ducking is the AI use case I trust most
The AI tool I get the most from never writes my code or drafts my docs. It is a rubber duck: an agent I told to ask questions instead of answering them. It interrogates whatever I bring it until the gaps in my thinking show, and most weeks that beats any answer it could give.
Almost everyone aims AI at output: write the function, summarize the thread, draft the message. That is the rational default. A good answer is measurable and saves real hours, and most of the work in front of you simply needs it. The use I trust most aims AI the other way, at my own reasoning. An answer machine hands you what you asked for. A good duck shows you the question you did not think to ask.
A rubber duck exposed me before a Milan meeting
I learned how sharp that gets before a trip to Milan. I had a business idea and a meeting lined up with two possible co-founders. A few days out, I opened the duck to prepare, and I wanted help getting the meeting right.
It started with the question I had skipped: what did I want to walk away with? Then it pressed on how I would adapt: what I would say if they doubted the idea, how I would steer the room if it turned. Three or four questions in, I had nothing.
The duck had already delivered the verdict. I knew what I wanted from the idea, but I had not done the thinking the business conversation would demand. The meeting went about as well as that sets you up for: we did not move forward on anything, and the idea died in that room. No tool rescues you from being unprepared. But this one did something better: it told me the truth before I boarded the flight, not across the table from the people I wanted to convince.
The practice is older than the AI
Rubber-ducking did not arrive with language models. Andy Hunt and Dave Thomas named it in The Pragmatic Programmer in 1999. Explain your code to a rubber duck on your desk, line by line, and the bug tends to announce itself before you finish. The duck contributes nothing. You do the work, and saying it out loud is what shakes the error loose.
I have run some version of this my whole career. Before I trusted my own logic, I would write a comment for every line first, spelling out what it should do, then fill in the code underneath. Often the logic collapsed right there in the comments, which was the whole point of writing them. A mistake is cheaper in English than in code.
What Harvard's CS50 duck gets right about restraint
When I built my own AI version, I took the core idea from Harvard. Their intro course, CS50, runs an AI rubber duck called the CS50 Duck that students can question around the clock. The design decision that matters is restraint: the team gave it guardrails so it nudges a student toward the solution and stops short of just handing it over. Their writeup frames the goal as a one-to-one tutor that leads you to the answer rather than spoiling it.
That restraint is the entire product. A model's default is to be helpful, and helpful means answering. To get a duck, you have to tell it, firmly and often, to do the harder thing: ask the next question and then wait.
Where it earns its keep: rehearsing a change
Before I commit to something hard to walk back, like a new process or a reorg, I rubber-duck the rollout before a single person hears it. The duck plays skeptic: what will the senior engineers push back on, and which line lands as a threat when I meant it as a plan. It finds the misunderstanding I baked in without noticing, while the wording is still cheap to change. By the time the change reaches people, I have already lost the argument once in private and rewritten it in plainer words.
The same move works before a big code change. Ahead of a refactor or a migration, I talk the plan through and let the duck poke at it. It asks what breaks if my main assumption is wrong, and what I am keeping because it is right versus because it is familiar. The duck takes whatever decision I am about to commit to and makes me argue for it before a line of it is written.
When is rubber-ducking the wrong tool?
None of this is free, and it is not always the right move. Rubber-ducking is slow by design, so when I only need an answer, a syntax detail or some boilerplate, I ask for the answer and move on.
It is also only as good as my honesty with it. I can feed it the conclusion I am hoping for and collect a reassuring nod. It tests my logic and takes my motives on trust.
It knows nothing about my situation beyond what I tell it and what it was trained on. That blind spot is the same one that lets it rewrite code it cannot see. It is a mirror that asks good questions, with no judgment of its own.
So I run two kinds of AI. One answers, which is most of what people mean by the word, and it genuinely saves me time. The other asks but answers nothing, and that is exactly why it is worth more to me. It makes me right more often, or at least stops me in time, before the people across the table get the chance.