Using an LLM as a Rubber Duck for IdeasJump to section titled Using an LLM as a Rubber Duck for Ideas
November 18, 2025
Field notes for AI engineers on leveraging language models during early-stage project ideation.
One of their most underrated uses is in the earliest stage of engineering—when you're not yet writing code, but trying to figure out what code to write.
The Classic Rubber DuckJump to section titled The Classic Rubber Duck
The rubber duck debugging technique is famous: explain your problem to an inanimate object, and the act of articulation often reveals the solution. The duck doesn't need to understand. It just needs to be there, patient and silent, while you work through your own thoughts.
LLMs as Active DucksJump to section titled LLMs as Active Ducks
Language models offer something different. They're not silent. They respond, probe, and sometimes surprise you with connections you hadn't considered. This changes the dynamic from monologue to dialogue.
I've found this particularly useful when:
Exploring problem spaces. "Here's a messy situation. What are the different ways I could frame this problem?" The model won't give you the right answer, but it will give you options you might have missed.
Stress-testing assumptions. "I'm assuming X because Y. What might I be missing?" Sometimes the response is useless. Sometimes it surfaces a blind spot.
Generating first drafts to react against. "Write a proposal for how to approach this." The proposal is usually wrong in interesting ways. Fixing it is faster than starting from blank.
The TrapJump to section titled The Trap
The danger is mistaking fluency for insight. LLMs are excellent at sounding confident about things they've pattern-matched from training data. They'll happily generate plausible-sounding architectures that don't actually fit your constraints.
Use them to expand your thinking, not replace it. The ideas are yours to evaluate.
A PracticeJump to section titled A Practice
When starting a new project or feature, I now spend 20-30 minutes in conversation with a model before writing any code. I describe the problem, explore alternatives, and articulate constraints. By the time I'm done, I have:
- A clearer sense of what I'm actually trying to build
- Several approaches I've considered and rejected
- Notes I can share with teammates
The model did a lot of the typing. But the thinking was mine.
More notes on AI tools in the garden.