Why rubber ducking matters more than ever in the AI era

most of the code I shipped this year started life as a prompt. I would guess yours did too?



I read about this and , in February 2025 Andrej Karpathy gave this a name. He called it vibe coding, where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He wrote "I 'Accept All' always, I don't read the diffs anymore," and admitted the code "grows beyond my usual comprehension."

"vibe" in Flash tv series

People tend to skip the next part. He said it was "not too bad for throwaway weekend projects." The person who coined the term told us where it belongs, and most of us aren't building throwaway weekend projects.

In the 2025 Stack Overflow Developer Survey, 66% of developers said their biggest frustration was "AI solutions that are almost right, but not quite." "Almost right" is the phrase that sticks with me. Code that's obviously wrong gets caught. Code that's almost right gets merged.

I agree that newer models, and the ones still coming, will write much better code. Maybe even perfect code. But you still have to own it. An AI agent can't be responsible for the code, but you can. And an agent will only write the code you need if you ask for it properly. Garbage in, garbage out.

There are two moments where this matters. The first is before the agent writes anything. Do you actually know what you're asking for? If you can't describe the constraints, the edge cases and what "done" looks like, the agent fills those gaps with plausible guesses. Veracode's CTO said developers "do not need to specify security constraints to get the code they want." So they don't, and the model picks for them.

The second is after the agent finishes. Do you understand what you got? Could you debug it? Could you defend it in review without saying "the AI wrote it"?

remember the duck?

The idea comes from The Pragmatic Programmer by Andrew Hunt and David Thomas, published in 1999. They tell the story of a programmer who carried a rubber duck around and explained his code to it, line by line. Kernighan and Pike described the same trick in The Practice of Programming, only with a teddy bear. A plant or a mug works too.

The method is simple. Tell the duck what your code is supposed to do, then walk through it line by line.

why explaining out loud works

The duck has real cognitive science behind it.

In 2002, Leon Rozenblit and Frank Keil at Yale described the illusion of explanatory depth. People believe they understand how things work far better than they do. Ask them to explain a zip or a flush toilet step by step and their confidence collapses. The illusion is strongest when the mechanism is visible and looks easy to follow.

A clean AI diff fits that description perfectly. You read it, it looks reasonable, and you feel like you understand it. That feeling isn't evidence.

duck before you prompt

Before I open the agent, I try to explain the task to the duck:

  • what problem I'm solving and who it's for
  • the constraints, like security, performance and the patterns this codebase already uses
  • the edge cases and how it should fail
  • how I'll know it's correct

if I can't say it clearly to a duck, I can't say it clearly to an agent. Most of my bad AI output traces back to a prompt I hadn't thought through.

Do this before the AI generates any code. Once you've seen its first suggestion, that suggestion anchors your thinking. AI doesn't always get the code wrong. The trouble is that its code can look right before anyone understands it.

duck after it builds

This is the half people skip.

Brian Kernighan and P.J. Plauger wrote in The Elements of Programming Style that "everyone knows that debugging is twice as hard as writing a program in the first place." If you didn't write it and you don't understand it, I'm not sure who's debugging it at 2am.

why my duck doesn't talk back

I'm against using AI as the rubber duck. I get the temptation. The agent is right there, and it will happily explain its own code. I think that defeats the point, and there's evidence for it.

AI assistants tend to agree with you. Anthropic's 2023 sycophancy research found five leading assistants consistently leaned towards what the user believed over what was true. A reviewer that wants to agree with you is the last thing you need when you're testing your own understanding.

The learning happens when you produce the explanation yourself. Michelene Chi's 1989 research on self-explanation found this with students. Anthropic's 2026 study on AI and coding skills found it with developers. The ones who kept asking why understood far more than the ones who handed the work over. When the AI explains the code, you're back to reading, and the illusion of understanding returns.

A silent duck makes you trip over your own gaps. A talking one fills them in before you notice they were there.

Someone will point out that AI code review catches real bugs. It does, and I use it. But code review checks the code. Rubber ducking checks you, and you're the one accountable when it breaks.

So use a duck, or a colleague who'll sit and listen without chipping in. Anything that won't finish your sentences for you.

A study involving 101 participants compared an inanimate rubber duck with robots that displayed attentive listening behaviour. Neither robot improved problem-solving performance over the silent duck.

The study doesn't prove that silence always produces better results. It does show that a responsive listener wasn't the part doing the work.

the developer was. (you or me)

Slowing down feels hardest when everyone around you is shipping faster. :( 

my checklist to keep next to the duck

Before you prompt, say out loud:

  • what you're building and why
  • the constraints and the existing patterns it should follow
  • the edge cases and failure modes
  • how you'll know it works

After the agent finishes, say out loud:

  • why each file changed
  • what happens when something fails, like a null, a timeout or a retry
  • whether it duplicated something that already exists
  • whether you could defend it in review
  • whether you could debug it in production

While you talk, listen for "somehow", "it just", "I think it" and "magic". Each one marks a spot where you don't understand the code yet.

get a duck

buy/pick a small cute toy. put one next to your keyboard. Next time the agent says it's done, turn to the duck before you hit merge and explain what just happened.

if you can't, you're not done!

Comments

Post a Comment

Popular posts from this blog

MDK Hospital opened in Horana

Image
Horana is getting a brand new private hospital! The M.D.K Healthcare Center & Hospital has just opened its doors on Anguruwathota Road, right next to the HNB bank branch. For years, many had to travel to Colombo for certain medical treatments, but hopes with new private hospital this will change. This new hospital, built by local businessman Mr. M.D. Piyananda Kularathna, comes with all the modern medical equipment we've been hoping for. It's wonderful to see such a major investment in Horana community's health. To makes this even better, I hope they have brought in highly skilled doctors and medical staff. No more long trips to Colombo for routine treatments! The hospital looks quite impressive too - modern and clean, just what you'd expect from a proper healthcare centre. The location is perfect as well. Being on Anguruwathota Road means it's easy to find and get to, whether you're coming from the town centre or surrounding areas. I've already notice...
Read more

Flyway in Spring Boot and Gradle: flyway-core vs Flyway Gradle Plugin

 Have you ever wondered about the best way to integrate Flyway into your Gradle project? Let me break it down into two main approaches: using Flyway as a dependency and applying the Flyway plugin . The Dependency Approach: implementation 'org.flywaydb:flyway-core' Adding Flyway as a dependency essentially embeds it within your application. Think of it as equipping your application with a built-in toolbox to handle database changes during runtime. This approach is ideal when you want your application to take charge of migrations. When to Use It Your application needs to manage database changes while it’s running. You’re working with a Spring Boot application that integrates seamlessly with Flyway. Key Features Spring Boot Auto-Configuration: Spring Boot automatically detects the Flyway dependency and configures it. You can custo...
Read more

"BACKABLE" - book by Suneel Gupta

Image
  "Backable" by Suneel Gupta explores how to inspire belief in your ideas, combining storytelling, resilience, and practical strategies to succeed. While I recommend you to read it here are some Concepts from Backable I found interesting: The Backable Mindset : The book highlights the importance of adopting a mindset that attracts support. Gupta discusses how successful people who are often seen as "backable" tend to approach challenges, communicate their vision, and create momentum. Below is an extract from first chapter he talks about how we should convince ourselves first with an idea before even sharing it with others: " When an idea first enters your mind, it's not fully formed, and certainly not prepared to interact with the real world. But because we're excited about the possibility, we make the mistake of inviting people in when the idea isn't ready. Every time I'm fired up about a new idea, I feel an impulse to share it immediately. But...
Read more