The Smart Rubber Duck

A few years ago, someone on my team bought every one of us a rubber duck. A little yellow bath duck, sat on the desk next to the monitor. It was not a joke (or not only a joke) - it was a tool.

If you have not come across rubber duck debugging, the idea is daft and completely real. When you are stuck, you explain the problem out loud to the duck. Line by line, slowly, as if it were a junior who needed every step spelled out. And somewhere in the middle of explaining, more often than you would believe, you hear the answer come out of your own mouth. The duck says nothing. The duck has done its job.

The duck was never the point

The point of the duck sitting on the desk, or often stuck to the monitor as a reminder, was being forced to take a vague, tangled problem in your head and turn it into clear, ordered words. The bug was always there. You just could not see it until you had to say it.

That forcing function, putting fuzzy thinking into plain language, has often been the most underrated skill in software. What has changed is that something is now listening, and writing it all down.

The duck listens and writes

Sit in a meeting today and Copilot will happily transcribe the whole thing. You can ramble, think out loud, talk around a problem the way you would to the yellow duck, and at the end there is a complete record of every word.

Most people treat that transcript as admin. A recap to skim and forget. But if you are even a little careful about how you talk in a meeting, that transcript stops being meeting minutes and becomes a gold artefact. It is the spec, captured in passing. It is the context that takes the friction out of building the thing, because you already said what you wanted, in order, out loud.

Rubber duck debugging used to be clarity for you, in the moment. Now it is clarity for the record, because your words do not just unstick your thinking. They can become the raw material for the build. So the discipline has shifted slightly. You are not only talking to understand. You are talking to provide the context for the agent to fix.

I have watched this work. On a recent build, a forty-minute kick-off call ended the day as the first cut of the data model. Nobody wrote a spec afterwards. The transcript was the spec.

Push it a little further and the loop tightens again: someone explains what they need on a Teams call, a workflow hands the transcript to the harness, and the screens are updated ten minutes after the meeting ends. The friction between a piece of feedback and a working change is vanishing.

Give the duck a memory

This is where the humble markdown comes in useful, and where an old habit of mine has come back: the ADR. An Architectural Decision Record is a short note that captures a decision and, crucially, why you made it. I used to write them religiously but as workflows changed with Agile, the habit slid because it felt like overhead nobody read. They are back, because a good transcript distilled into a few markdown decisions is exactly the grounded context an agent needs to keep the next decision in line with the last.

Push that idea far enough and you arrive at something Andrej Karpathy has been describing as an LLM wiki. Instead of a handful of decision records, you keep a whole folder of markdown - the sources, the decisions, the context - and let the model maintain it as a living, interlinked knowledge base. You compile your understanding into it once and keep it current, rather than re-explaining the project from scratch every session. A transcript and an ADR are the small end of this. The LLM wiki is what it looks like when you take it seriously - a memory the agent reads back every time it builds.

You ramble, it gets captured, you distil the gold out of it, and you keep it where the build can reach it. The duck has a long-term memory now, and the transcript is how it fills it.

Keep the duck

So do we still need the daft yellow duck on the desk? Perhaps. There is something about saying a problem out loud, to an object that cannot judge you, that even the cleverest model has not replaced.

But the virtual duck can listen now. It remembers, and it builds. So use it like you used the yellow one, ramble and all. Just make sure that when you are done, the transcript ends up where it belongs. Not in someone’s inbox, not on a Teams or Zoom tab to be summarised and lost. Move it to where the context lives, where the harness can turn it into the thing you are about to build.

The tools have not caught up with this yet. Copilot is a firehose, and it treats the transcript as minutes - something for the organiser to download and circulate, as if it belonged in a recap email. It does not.

A transcript in an inbox is gossip. The same transcript in the harness is grounding.