Arguing with Claude

Claude's first suggestion is rarely its best. It is its most obvious. When you ask Claude to design an authentication system, the first plan will probably involve JWT tokens, bcrypt, and a middleware pattern — the standard approach it has seen in thousands of codebases. That might be exactly right. Or it might be a poor fit for your specific constraints. The only way to find out is to push back.

Productive disagreement with Claude follows a specific pattern. State your objection clearly: "I am concerned about X in your approach." Ask for alternatives: "What are three other ways to solve this?" Challenge assumptions: "You assumed we need a database for sessions — what if we used signed cookies instead?" Request tradeoff analysis: "Compare approach A and approach B on performance, complexity, and maintenance cost." Claude responds well to structured pushback because it forces deeper reasoning. The extended thinking model evaluates alternatives more thoroughly when you explicitly ask it to.

The developers who get the best results from Claude are not the ones who accept the first answer. They are the ones who treat Plan mode like a design review. They argue. They challenge. They ask "why not" as often as they ask "how." The result is a plan that has survived scrutiny before a single line of code is written — which is exactly when scrutiny is cheapest.