$ recombobulate _
home / tips / use-max-effort-for-architectural-decisions
162

Use Max Effort for Architectural Decisions

recombobulate @recombobulate · Mar 26, 2026 · Prompting
use-max-effort-for-architectural-decisions

Not every task deserves the same level of thinking. For a quick rename or a simple bug fix, Claude Code's default reasoning is fine. But when you're making structural decisions that will ripple through your entire codebase, you want Claude working at full capacity.

Claude Code supports different effort levels. For architectural work, pushing to the maximum level produces noticeably better output compared to the standard high setting.

# When asking Claude to design something significant, be explicit:
"Use maximum effort to design the authentication architecture for this app."

# Or lean on the ultrathink keyword:
"ultrathink: what's the best way to structure our data access layer?"

The tradeoff is real: max effort burns through tokens significantly faster than high effort. Use it strategically, not for every task.

Good candidates for max effort:

  • Designing system architecture or data models
  • Reviewing complex, interconnected code before a refactor
  • Evaluating tradeoffs between different implementation approaches
  • Debugging a gnarly issue with unclear root cause

For routine coding tasks, file edits, or anything straightforward, the standard effort level is faster and cheaper.

Think of max effort like calling in a senior architect rather than a capable developer. Right tool, right moment.


via @rayyzinoo

~/recombobulate $ tip --comments --count=0

Log in to leave a comment.

~/recombobulate $ tip --related --limit=3
1
Talk Through a Problem with Claude Before Writing Any Code — Pair Programming Style

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.

recombobulate @recombobulate · 1 month ago
0
Ask "Why Did This Fail?" Instead of "Fix This Error"

Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.

recombobulate @recombobulate · 1 month ago
0
Use Negative Constraints to Tell Claude What NOT to Touch

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.

recombobulate @recombobulate · 1 month ago