Break Big Tasks into Phases So Claude Doesn't Try to Do Everything at Once
The biggest mistake with Claude Code is asking for too much at once. "Build a complete user authentication system" produces worse code than building it in deliberate steps. Break it down yourself — or tell Claude to.
"Add email notifications to the order system. Do this in phases:
1. First, create the notification model and migration
2. Then build the email templates
3. Then add the trigger points in the order lifecycle
4. Then write the tests
5. Do each phase completely before moving to the next"
Claude works through each phase, finishing one before starting the next. You can review at each checkpoint — catching issues early instead of untangling a massive diff at the end.
For really large tasks, use plan mode first:
# Shift+Tab to plan mode
"I need to add a subscription billing system. Break this into phases
and tell me what each phase would include."
# Review the plan, then Shift+Tab back to act mode
"Start with phase 1"
The phase pattern works for any large task:
# Feature development
"Add search: phase 1 = backend query and index, phase 2 = API endpoint,
phase 3 = frontend UI, phase 4 = tests"
# Refactoring
"Migrate from callbacks to async/await: phase 1 = identify all callback patterns,
phase 2 = convert the utility functions, phase 3 = convert the route handlers,
phase 4 = update the tests"
# Infrastructure
"Set up monitoring: phase 1 = health check endpoints, phase 2 = metrics collection,
phase 3 = alerting rules, phase 4 = dashboard"
After each phase, Claude runs tests (if you ask), so regressions get caught immediately rather than accumulating across the entire change.
Small, verified steps beat big, hopeful leaps — tell Claude the phases and it delivers working code at every checkpoint.
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.