Ask Claude to Evaluate Two Approaches Before You Commit to One
You've got a feature to build and two ways to do it. Instead of picking one and hoping for the best, ask Claude to lay out the trade-offs before you write a single line of code.
I need to add real-time notifications. Compare these two approaches:
1. WebSockets with Laravel Reverb
2. Server-Sent Events with a simple controller
Evaluate: complexity, scalability, browser support, and time to implement.
Claude will break down each option with concrete pros and cons tailored to your stack. This works because Claude can reason about architecture without the sunk-cost bias you get after already building something.
You can use this pattern for all kinds of decisions:
Should I use a database queue or Redis for this job pipeline?
Compare performance, reliability, and operational complexity
for our current scale (~500 jobs/hour).
I'm torn between a service class and a pipeline for this checkout flow.
Show me what each would look like in code, then tell me which
you'd pick and why.
A few situations where this saves real time:
- Choosing between packages — ask Claude to compare two libraries against your specific requirements.
- Database design — polymorphic vs. separate tables, JSON columns vs. normalised data.
- Refactoring strategy — incremental changes vs. a clean rewrite of a module.
- Testing approach — mocking external services vs. using Testcontainers.
The key is to ask before you start building. Five minutes of comparison beats five hours of rewriting.
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.