How to Use Claude Code Plan Mode for Larger Features

Claude Code can begin editing files as soon as you give it a task. That works well for small, focused changes, but larger features benefit from more thought before implementation begins.

This is where Plan Mode becomes useful.

In Plan Mode, Claude Code inspects the relevant files, analyzes the existing architecture, and proposes an implementation plan without immediately changing the code. You can review the approach, identify problems, request revisions, and approve the plan only when it matches what you want.

In this tutorial, we’ll use Plan Mode to redesign a basic React workout logger. Instead of displaying one flat table of exercises, the application will show workouts at the top level and the exercises performed within each workout on a detail screen.

Along the way, you’ll learn how to:

• Recognize when a task is large enough for Plan Mode
• Describe a feature at the product level
• Review a proposed data model and component structure
• Choose how Claude Code applies its edits
• Test the completed feature
• Inspect a large AI-generated diff with Git
• Treat AI-assisted development as an iterative process

The Problem With the Current Workout Logger

Our initial application allows the user to log individual exercises and displays them in a table. Each row contains information such as the exercise name, sets, reps, and weight.

The basic functionality works, but the data is organized as one flat list. That is not how most people think about their training.

A more natural structure has two levels:

1. Workouts represent individual training sessions.
2. Exercises belong to a specific workout.

The home screen should display the workouts the user has performed. When the user selects a workout, the application should open a detail view showing the exercises completed during that session.

The updated experience should work like this:

Workout list
  → Select a workout
    → View its exercises
      → Add or delete an exercise

Users should create a workout from the home screen rather than logging an isolated exercise. Exercise logging should happen only inside a selected workout.

This redesign affects the data model, state, components, persistence, and user interface. Because several implementation decisions are involved, it is a good candidate for Plan Mode.

What Is Plan Mode?

By default, Claude Code can begin carrying out a task after receiving a prompt. Plan Mode separates the thinking stage from the implementation stage.

While in Plan Mode, Claude can:

• Inspect the existing project
• Identify relevant files and components
• Understand the current data flow
• Propose a new architecture
• List the files it expects to create, update, rename, or remove
• Describe how the feature should be verified

It does not implement the plan until you approve it.

This makes Claude Code more useful as a thinking partner. You can begin with a clear product goal even when you have not decided every component, state variable, or handler that will be required.

Plan Mode is especially useful when a change:

• Spans several files
• Changes the data model
• Introduces a new user flow
• Affects multiple components
• Requires architectural decisions
• Has unclear implementation details

For a small, isolated edit—such as renaming a label or refactoring one function—a concise prompt in normal mode is usually sufficient.

Understand Claude Code’s Editing Modes

Claude Code provides multiple interaction modes. Their names and shortcuts can change between versions, but the general behaviors are:

Normal mode

Claude proposes edits and asks for approval before applying them. This gives you control over each change.

Accept Edits mode

Claude can apply edits without requesting approval for every file. This is faster, but it requires careful review afterward.

Plan Mode

Claude investigates the codebase and writes a plan without changing the project. After reviewing the plan, you choose whether and how to implement it.

In the version used for this lesson, you can cycle through these modes with Shift+Tab. Check Claude Code’s current interface or built-in help if that shortcut has changed.

You can also clear the current conversation context with:

/clear

Clearing the conversation can be useful when you are beginning a distinct task and no longer need the previous discussion. Be aware that doing so removes conversational context, so your next prompt must provide all important requirements again.

Describe the Redesign Clearly

Enter Plan Mode, then give Claude Code a product-level description of the desired behavior:

The home screen currently shows a workout logger where the user logs
individual exercises and views their sets, reps, and weight in a flat
table.

Redesign the application so the home screen displays a list of workout
sessions the user has performed. From the home screen, the user should
be able to create a new workout or select an existing workout.

Selecting a workout should open a detail view containing the exercises
performed during that workout. Exercises should be added and deleted
only from the workout detail view, not from the home screen.

Use the existing project patterns and components where appropriate.
Continue using localStorage for persistence because this sample project
does not have a backend. Do not add a routing library; a simple in-app
detail view is sufficient.

Before changing any files, inspect the project and propose a detailed
implementation plan. Include the data model, state changes, component
changes, persistence strategy, affected files, and verification steps.

This prompt explains the desired user experience without prescribing every line of implementation. It also establishes two useful constraints:

• Continue using localStorage.
• Do not introduce a routing library for this small demonstration.

You could reference specific files with @ mentions, but that is not always necessary for a broad architectural change. Claude Code can inspect the project to identify the relevant files. File references become more important when you know exactly where a focused change belongs.

What a Useful Plan Should Contain

A good plan should give you enough information to evaluate the implementation before seeing the generated code.

Look for three major sections.

1. An overview

The plan should summarize the proposed approach in plain language. For this feature, it should recognize that the application is moving from a flat list of exercises to a two-level hierarchy:

Workout
  └── Exercises

The home screen will display workout sessions, while the detail view will display the exercises that belong to the selected workout.

2. Specific file and architecture changes

The plan should explain which types, components, state variables, handlers, and utilities will change.

For example, it may propose:

• Replacing the old flat WorkoutEntry type
• Defining an Exercise type
• Defining a Workout type containing an array of exercises
• Storing the workouts in application state
• Tracking the selected workout ID
• Updating the localStorage structure
• Creating a workout-list component
• Creating a workout-detail component
• Renaming the add-workout dialog to an add-exercise dialog
• Adding a date-formatting utility

A simplified data model might look like this:

type Exercise = {
  id: string;
  name: string;
  sets: number;
  reps: number;
  weight: number;
};

type Workout = {
  id: string;
  date: string;
  exercises: Exercise[];
};

The exact model may differ, but it should clearly represent the relationship between a workout and its exercises.

3. Verification steps

The plan should describe how to confirm that the implementation works. Verification should cover more than whether the application compiles.

For this feature, the expected behaviors include:

• Creating a new workout from the home screen
• Opening a workout detail view
• Adding an exercise to the selected workout
• Deleting an exercise
• Returning to the workout list
• Deleting a workout
• Retaining the data after a browser refresh
• Running lint and build checks successfully

If the plan lacks verification steps, ask Claude to add them before implementation.

Review the Proposed Data Flow

Do not approve a plan simply because it is detailed. Read it critically.

For this small project, Claude may propose storing two primary pieces of state:

const [workouts, setWorkouts] = useState<Workout[]>([]);
const [selectedWorkoutId, setSelectedWorkoutId] = useState<string | null>(null);

When selectedWorkoutId is null, the application displays the workout list. When it contains an ID, the application finds that workout and displays its detail view.

The root component can conditionally render the correct screen:

return selectedWorkout ? (
  <WorkoutDetail workout={selectedWorkout} />
) : (
  <WorkoutList workouts={workouts} />
);

This is conditional rendering with a ternary operator; it is not true URL-based navigation. That is acceptable for a small throwaway project because it avoids introducing React Router or another routing library.

For a larger production application, you might prefer actual routes so the detail screen has its own URL, browser history works naturally, and a selected workout can be linked directly. The appropriate choice depends on the scope of the project.

Review the Proposed Operations

The plan should also explain the state-changing functions that the application needs.

Create a workout

Add a new workout with a unique ID, the current date, and an empty exercise array.

Delete a workout

Remove the selected workout from the collection. The interface may also need a confirmation step in a production application.

Add an exercise

Find the workout matching the selected ID and append the new exercise to its exercises array.

Delete an exercise

Remove an exercise from the correct workout without changing other workouts.

Open and close the detail view

Set selectedWorkoutId when the user selects a workout, and reset it to null when the user returns to the home screen.

Persist the data

Serialize the workout collection to localStorage whenever it changes, then load and validate the stored data when the application initializes.

Review whether each operation updates state immutably and whether it handles missing IDs or malformed stored data safely.

Existing Code Influences the Generated Plan

Claude Code tends to mirror patterns already present in the codebase. If the project uses small reusable components, consistent naming, and clear types, the generated plan is more likely to follow those conventions.

The opposite is also true. Inconsistent or tightly coupled code can lead Claude toward more inconsistent or tightly coupled additions.

This is one reason code quality still matters when working with an agent. Your existing project is part of the prompt, even when you do not paste it into the conversation.

Choose How to Apply the Plan

After Claude generates a plan, you generally have three choices:

1. Request changes to the plan. Use this when you disagree with the architecture or notice a missing requirement.
2. Approve the plan and review edits manually. This is the safest default for meaningful project work.
3. Approve the plan with automatic edit acceptance. This is faster but transfers more responsibility to the final review.

Manual approval can feel slower because you review each file change as it occurs. However, it keeps the implementation digestible and lets you stop Claude when it moves in the wrong direction.

For this tutorial, automatically accepting edits can save time because the project is small and disposable. For production work, prefer reviewing changes as they are proposed—especially deletions, dependency installations, configuration changes, authentication logic, migrations, and data-handling code.

Even when edits are accepted automatically, Git still gives you a complete diff to inspect afterward. Automatic acceptance changes when you review the code; it does not remove the need to review it.

Model Selection for Planning

A more capable reasoning model can be useful for difficult architectural planning. However, the best model is not always necessary for every task.

A small sample application may receive a perfectly useful plan from a mid-tier model. A complex production feature involving security, concurrency, migrations, or several services may benefit from the strongest available model.

Model names, availability, pricing, and usage limits change over time. Choose based on the difficulty and risk of the task rather than assuming that every plan requires the most expensive option.

The quality of the prompt, the codebase, and your review still matters regardless of the selected model.

Test the Redesigned Workout Flow

Once Claude completes the implementation, start the development server if it is not already running:

npm run dev

Open the local URL shown in the terminal and test the complete flow.

Create a workout

From the home screen, select New Workout. Confirm that a new workout card appears and that it initially contains no exercises.

Open the workout

Select the workout card. The application should display the workout detail view instead of the home screen.

Add an exercise

Add a sample exercise such as:

• Exercise: Dumbbell Bench Press
• Sets: 4
• Reps: 8
• Weight: 35 lb

Confirm that the exercise appears in the detail table.

Return to the home screen

Use the back control and verify that the workout remains visible in the list.

Verify persistence

Refresh the browser, reopen the workout, and confirm that the exercise is still present. This verifies that localStorage is working.

Test deletion

Delete an exercise and confirm that it disappears from the correct workout. Then test deleting an entire workout from the home screen.

Run project checks

Finally, run the available quality checks:

npm run lint
npm run build

If the project includes tests, run those as well.

Review the Git Diff

Large AI-generated changes can be difficult to absorb while they are being produced. Git gives you a structured way to review the final result.

Start with:

git status
git diff --stat
git diff

You can also inspect each changed file from Visual Studio Code’s Source Control panel.

Pay particular attention to:

• Deleted or renamed files
• Changes to the core data types
• localStorage parsing and serialization
• Workout and exercise update logic
• Conditional rendering
• Component props
• Newly installed dependencies
• Unrelated changes outside the approved plan

Do not limit the review to a quick scroll. For your own application, understand every meaningful change before committing it.

If the implementation is correct, stage and commit it:

git add .
git commit -m "feat: organize exercises into workout sessions"

Coding Knowledge Still Matters

Agentic coding tools do not make software-development knowledge irrelevant. The opposite becomes clear when reviewing a detailed plan.

Understanding JavaScript, TypeScript, React, component composition, state updates, and conditional rendering allows you to answer important questions:

• Does the proposed data model fit the product?
• Is the state stored at the correct level?
• Is this true navigation or only conditional rendering?
• Are state updates immutable?
• Could persisted data become invalid?
• Is a deleted file actually obsolete?
• Would this architecture remain manageable as the application grows?

Someone who cannot evaluate the plan has to trust every assumption the model makes. Claude can generate the implementation, but the developer still provides judgment, feedback, and accountability.

Plan Mode Is Iterative

Plan Mode is not something you use once to design an entire application permanently.

The workout logger has already gone through multiple iterations:

1. Generate the initial flat exercise logger.
2. Improve a focused form implementation.
3. Redesign the application around workout sessions.

Each iteration creates new information. Once you use the feature, review the code, and understand the next problem, you can plan the next improvement.

A practical AI-assisted development loop looks like this:

Describe → Plan → Review → Implement → Test → Inspect → Commit → Repeat

For particularly large plans, break the implementation into smaller phases instead of asking Claude to generate the entire feature at once. Smaller diffs are easier to review, easier to test, and easier to reverse.

Final Takeaway

Use Claude Code’s Plan Mode when you understand the feature you want but have not resolved all of its implementation details. A useful plan should explain the architecture, affected files, data flow, component changes, and verification steps before any code is written.

For this workout logger, Plan Mode helped transform a flat list of exercises into a more realistic hierarchy of workouts and exercise details. More importantly, it made the model’s intended approach visible before implementation began.

The plan is not a substitute for engineering judgment. Read it, question it, revise it, review the resulting code, and verify the behavior yourself. The real benefit of Plan Mode is not automatic development—it is a clearer collaboration between the developer and the coding agent.