Skip to content
BSWEN
Blog

How I Learned to Stop Getting Safe Suggestions from Claude AI

Cowrie
Cowrie
Dev @ Bswen

I asked Claude to help me architect a new feature, and it gave me a basic three-step plan that would take maybe two hours to implement. The problem? I had a week, a team of three, and wanted something that would scale for years.

Every time I asked for “the best solution,” Claude kept recommending the simplest approach. It was like asking a Michelin chef for dinner recommendations and getting “toast is quick and easy.”

The Hidden Assumption Problem

After multiple frustrating conversations, I realized Claude wasn’t being lazy—it was being helpful for the wrong user profile.

Claude operates with implicit assumptions about who you are:

  • A solo developer juggling multiple responsibilities
  • Limited time and bandwidth
  • No existing infrastructure or team support
  • Preference for quick wins over long-term architecture

These assumptions are invisible, but they shape every plan Claude generates. The result is suggestions that solve your immediate problem but miss transformative opportunities.

What I asked: "Help me design a caching system"
What Claude assumed: "Help me design a caching system for one person with no time"


What I actually wanted: "Help me design a caching system for a team of 5,
                          with proper monitoring, invalidation strategies,
                          and multi-region support"

My First Failed Attempts

I tried being more specific:

“Give me the best caching solution.”

Still got the simple answer.

“I want something more robust.”

Claude added one extra feature and called it robust.

“What would you recommend if this was a critical system?”

Claude finally gave me a decent answer—but it took four iterations, and I still felt like I was pulling teeth.

The Breakthrough: Strip Assumptions First

The key insight came from a Reddit thread where someone pointed out that Claude’s “ideal” is already compromised before you type a word. You have to explicitly remove those constraints.

Here’s the prompt pattern that changed everything:

"If time and labor were not a consideration, what would the optimal
version of [PROJECT] look like? Don't plan, just describe."

This single line transforms the conversation. Claude stops optimizing for ease of implementation and starts optimizing for quality.

The Three-Phase Approach

Phase 1: Strip Assumptions

I start every planning conversation with this:

"Before you respond, assume:
- Time is not a constraint
- I have access to any tools or infrastructure needed
- I have a team available if beneficial
- I want the best long-term architecture, not the fastest to ship


[PROJECT DESCRIPTION]


What would you recommend?"

The difference is immediate. Instead of “use Redis, it’s simple to set up,” I get “implement a multi-tier caching strategy with Redis for hot data, CDN for static assets, and consider read replicas for your database layer.”

Phase 2: Iterate Until Alignment

One prompt isn’t enough. I’ve learned to push back when Claude slides back into safe mode:

Me: "That's the safe answer. What would you recommend if I had
     a team of 5?"


Claude: "With a team of 5, I'd suggest breaking the caching layer
         into separate concerns: a cache orchestrator, invalidation
         service, and monitoring dashboard..."


Me: "You're still optimizing for speed. Optimize for long-term
     architecture instead."


Claude: "For long-term architecture, consider: event-driven invalidation
         using message queues, cache warming strategies for cold starts,
         and a custom LRU implementation tuned to your access patterns..."

Phase 3: Mirror Validation

The process is complete when Claude can describe my vision back to me without correction:

"Based on our discussion, describe back to me what you understand
my ideal outcome to be. Don't suggest anything, just reflect my
vision. If anything doesn't match my expectations, I'll correct you."

This catches misalignments early and ensures Claude and I are on the same page.

Common Traps I Fell Into

Trap 1: Accepting the first response

The first plan is almost always the constrained version. I’ve learned to never accept it without pushing back at least twice.

Trap 2: Not being specific about constraints

Saying “I want the best solution” isn’t enough. I have to explicitly remove assumptions about time, resources, and team size.

Trap 3: Skipping iteration

One prompt refinement isn’t enough. I expect 3-5 rounds of pushback now. It feels verbose, but it saves me from implementing suboptimal solutions.

Trap 4: Accepting Claude’s default recommendations

When Claude offers multiple options, it almost always recommends the easiest one. I now explicitly override this:

"When I ask you to choose between options, don't recommend based on
ease of implementation. Recommend based on:
1. Long-term maintainability
2. Alignment with industry best practices
3. Scalability and extensibility


If a more complex solution is genuinely better, advocate for it."

Why Claude Does This (And Why It’s Actually Good)

Claude’s conservative defaults aren’t a bug—they’re a feature that protects most users from overwhelming suggestions. For a solo developer with limited time, a quick fix is genuinely better than a robust architecture that takes weeks to implement.

The problem is when you’re not that user. Claude can’t read your context, so it defaults to the safest assumptions. Your job is to explicitly provide that context.

Think of it like hiring a contractor:

Option A: "I need a bookshelf"
Contractor: "Here's an IKEA one, takes 20 minutes"


Option B: "I need a bookshelf. I have a full workshop, I'm experienced
          with furniture building, and I want something that'll last
          50 years."
Contractor: "Let's talk about hardwood options, joinery techniques,
            and custom dimensions..."

Same request, different context. Claude is the contractor who defaults to Option A unless you explicitly request Option B.

The Prompt Templates I Use Now

For initial planning:

"If time and labor were not a consideration, what would the optimal
version of [PROJECT/FEATURE] look like? Don't plan, just describe.
I want to understand the ceiling before I decide where to land."

For pushing back:

"You're still optimizing for implementation speed. Let me be clearer:
describe the architecture that would make a senior engineer say 'this
is how I would build it if I had full autonomy and resources.'"

For validation:

"Based on our discussion, describe back to me what you understand
my ideal outcome to be. Don't suggest anything, just reflect my
vision. If anything doesn't match my expectations, I'll correct you."

What Changed in My Workflow

Before discovering this approach, I’d get a plan from Claude, implement it, and realize a week later that it was missing critical features. Now I spend 15-30 minutes upfront stripping assumptions and iterating, and the plans I get are genuinely transformative.

The key insight: Claude’s “S-tier” results are available, but you have to ask for them explicitly. The default is “B-tier” because that’s what helps the most people. If you want more, you have to remove the training wheels yourself.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: