← Back to Lessons
Getting Started

Plan, Build, Review: the Safe Way to Work

For anything bigger than a one-liner, have Claude plan first, then build, then check its own work. It is calmer, safer, and produces better results than firing off one big request.
⏱ About 8 minutes

The idea. When a task is more than a quick tweak, do not ask Claude to do everything in one shot. Ask it to plan first, agree on the approach, then let it build, then have it review the result. You stay in control and the work comes out better. This is the same loop experienced builders use.

1
Switch into Plan mode

Plan mode tells Claude to research and propose changes without touching any files. You switch it on right from the keyboard.

Press Shift+Tab to cycle through Claude Code's modes. Each press moves you one step:

The cycle

Normal (Claude asks before each change) → Accept edits (Claude makes changes without asking) → Plan mode (Claude only reads and plans). Press again and it loops back to Normal.

The mode you are in shows in the status bar at the bottom of the screen, so you always know where you stand. Keep pressing Shift+Tab until it reads plan mode.

In VS Code

Click the mode indicator at the bottom of the chat box and choose Plan mode. The labels there are "Ask before edits" (normal), "Edit automatically" (accept edits), and "Plan mode."

Two handy shortcuts: start a whole session in plan mode by launching with claude --permission-mode plan, or plan just one prompt by starting it with /plan.

2
Plan before anything changes

With plan mode on, ask for a plan, not a result. Claude researches and proposes an approach without touching any files yet.

Plan how you would build a one-page infographic about coffee as a single HTML file: a bold title, three sections (a short history, how coffee is made, and a few fun facts) with simple icons or stats, and a footer. Do not change any files yet, just outline the steps and what you would create.

Claude lays out the steps. Now you can catch a wrong assumption before any code is written. Tell it what to change about the plan in plain language.

Why this example stays simple

This builds one self-contained HTML file you can open in a browser, with nothing to configure. Things like a contact form that emails you need a server and setup, which is a topic for later. For now, plan changes that live entirely in a local file.

Why plan first

A two-minute plan review saves you from a big change that went the wrong direction. It is far easier to redirect a plan than to untangle finished work.

3
Build once the plan is right

When the plan looks good, you leave plan mode and start building. There are two ways:

Approve the plan (easiest)

When Claude finishes planning, it presents the plan and asks how to proceed. Pick an approve option, either review each edit or accept edits as it goes, and Claude leaves plan mode and starts building automatically.

Or toggle back yourself

Press Shift+Tab to cycle out of plan mode into Normal or Accept edits, then tell Claude to go:

That plan looks right. Go ahead and build it.

Either way, Claude works through the steps and shows you diffs as it goes. Review changes as they appear and accept or course-correct. Because you agreed on the approach, there are no big surprises, just the plan turning into real files.

4
Review the result

Do not stop at "it ran." Ask Claude to check its own work against what you wanted.

Review what you just built. Does it match the plan? Anything missing, broken, or risky? Test it if you can.

Claude re-reads the changes, runs what it can, and reports issues by importance. This catches the small misses before they become bugs you find later.

The full loop

Plan, agree, build, review. For a tiny change, skip straight to building. For anything you would be annoyed to get wrong, run the whole loop. It quickly becomes second nature.

5
Habits that keep it safe

A few practices make this loop reliable.

Work safely with bigger changes

  • Use plan mode for anything non-trivial; approve the plan before building
  • Read diffs instead of blindly accepting everything
  • Commit your work to git at good stopping points so you can always go back
  • Ask Claude to test or verify, do not assume it worked
  • When a change feels too big, ask Claude to break it into smaller steps
Git is your safety net

If your project uses git, commit before a big change. If something goes sideways, you can return to the last good state in seconds. Ask Claude to set up git if you have not.

Questions?

Made by AI Service Engine. Next: connect Claude to your tools with MCP.