title: Rubber Duck Agent slug: rubber-duck-agent category: workflow-pattern status: proven difficulty: beginner tags: [thinking, design, exploration, rubber-ducking, conversation] prerequisites: [basic-cli-usage] estimated_time: 5min to learn, immediate use cost_per_use: "$0.03-$0.20"

Rubber Duck Agent

Problem

You jump straight into coding a solution before fully understanding the problem. The agent happily helps you implement the first approach you describe, even if it is suboptimal. Hours later, you realize a simpler design existed, or you missed a constraint that invalidates your approach. Traditional rubber-duck debugging uses an inanimate object — but an agent can actually respond, challenge assumptions, and suggest alternatives.

Solution

Before writing any code, use the agent as a thinking partner. Explain the problem, explore the design space, and only implement after you have a clear, validated approach.

Step-by-Step

1. Explain the problem: Describe what you are trying to achieve, not how.
2. Explore constraints: Ask the agent to identify edge cases, risks, and tradeoffs.
3. Consider alternatives: Ask for 2-3 different approaches with pros and cons.
4. Challenge your assumptions: Tell the agent to poke holes in your preferred approach.
5. Decide: Pick an approach based on the discussion.
6. Implement: Now code with confidence.

When to Use

• Before starting any feature that will take more than an hour to build
• When you are stuck and cannot see a clear path forward
• When choosing between multiple technical approaches
• Debugging a problem you do not understand yet
• Architecture and design decisions
• When you want a second opinion before committing to an approach

When NOT to Use

• You already know exactly what to build and how
• The task is trivial and does not warrant discussion
• You need to ship immediately (but even then, 5 minutes of thinking often saves hours)

Example: Claude Code

# Design discussion before implementation
claude

# > I need to add real-time notifications to our app. Users should see
# > notifications in the browser without refreshing. We currently have a
# > REST API with Express and a React frontend. Our scale is ~5000
# > concurrent users.
# >
# > Before we write any code, help me think through this:
# > 1. What are the main approaches (polling, SSE, WebSockets)?
# > 2. What are the tradeoffs at our scale?
# > 3. What infrastructure changes does each require?
# > 4. What's the simplest approach that meets our needs?

# Debugging an issue you don't understand
claude -p "I have a bug I don't understand yet. Don't try to fix it — \
  help me think through it first.

  Symptom: Our API returns 200 OK but the response body is empty \
  about 5% of the time. It happens across all endpoints.

  What I've checked:
  - Logs show the handler completes successfully
  - Database queries return data
  - It happens on all server instances

  Questions:
  1. What could cause a 200 with empty body intermittently?
  2. What should I look at next?
  3. What's the most likely category of bug (networking, middleware, serialization)?"

# Architecture decision record
claude -p "I need to decide between these approaches for our caching layer. \
  Act as a senior engineer reviewing my options. Be critical.

  Option A: Redis cache in front of Postgres
  Option B: Postgres materialized views
  Option C: In-memory cache with LRU eviction

  Context: Read src/db/ and src/api/ to understand our current data access \
  patterns. Then give me a recommendation with reasoning."

Example: Codex CLI

# Design exploration
codex -q "Before implementing anything, help me think through adding \
  real-time notifications to this Express + React app. \
  Compare polling vs SSE vs WebSockets for ~5000 concurrent users. \
  Give pros, cons, and a recommendation."

# Problem analysis
codex -q "I have an intermittent empty response body bug. \
  Read src/middleware/ and src/routes/. \
  What could cause 200 OK with empty body 5% of the time? \
  List hypotheses ranked by likelihood."

Cost Estimate

The cheapest pattern in terms of cost, and often the highest ROI. A $0.10 thinking session can prevent a $5.00 wasted implementation.

Maturity Notes

Status: Proven. This is arguably the most underused pattern. Developers instinctively reach for "write code" mode, but the agent is often more valuable as a thinking partner than as a code generator. Key success factors: (1) resist the urge to ask for code too early, (2) explicitly tell the agent not to write code yet, (3) ask it to challenge your assumptions rather than just agree with you. Some practitioners start every session with a 2-minute rubber-duck phase regardless of task complexity.

Related

• Pattern: Plan Then Execute
• Pattern: Explore Before Change
• Pattern: Review Then Fix
• Module: Prompting for Agents