Use Claude Code as a Rubber Duck — Think Out Loud and Let It Push Back
Sometimes you don't need Claude to write code — you need it to help you think. Describe your problem or idea and let Claude be the colleague who asks the hard questions.
"I'm thinking about caching the user permissions in Redis with a 5-minute TTL.
Walk me through the tradeoffs and tell me what could go wrong."
Claude reads your actual code, understands the current implementation, and responds with specific concerns — not generic advice, but issues that apply to your architecture:
- "Your admin panel updates permissions instantly, but users would see stale permissions for up to 5 minutes. Is that acceptable?"
- "I see you have 3 services that check permissions. Would they all hit the same cache, or would each have its own?"
- "What happens during a Redis outage — does the app fail closed or open?"
This works for any kind of technical decision:
# Architecture decisions
"Should I use a message queue or a webhook for this integration? Here's the context..."
# Debugging strategies
"The tests pass locally but fail in CI. I think it's a timing issue but I'm not sure.
Help me think through what else it could be."
# Design reviews
"I'm about to split this monolith service into three microservices.
Read the code and tell me if the boundaries I'm choosing make sense."
# Tradeoff analysis
"We could use server-side rendering or client-side rendering for this page.
Given our stack and use case, what would you recommend and why?"
The key is to share your reasoning, not just the question. Claude responds better when it understands your thought process:
# Instead of:
"Should I use WebSockets?"
# Share your thinking:
"I'm considering WebSockets for the notification system because users need
real-time updates. But we only have 100 concurrent users and I'm worried
about the infrastructure complexity. Am I overthinking this?"
Claude might respond: "For 100 users, Server-Sent Events would give you real-time delivery with half the complexity — no WebSocket server, no connection management, and your existing HTTP infrastructure handles it."
The best debugging tool is another brain. Claude reads your code and your reasoning, then asks the questions you forgot to ask yourself.
via Claude Code
Log in to leave a comment.
Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.