How to audit a coding agent's plan before it writes code

I asked an agent to add saved searches to a device catalogue in a React app. The plan had eight clean, well-ordered steps, and I approved it after a skim. Step three introduced a new global store for the whole search module, although the project already had a saved-search service and local view state that covered the feature. By the time I noticed, the store had a slice, selectors, a provider in the app shell and a dozen updated tests. The code was good. The direction was not mine.

How to use plan mode in Claude Code

In Claude Code, plan mode lets the agent read files and run commands to explore the repository, but it does not edit your source until you approve the plan. Turn it on with Shift+Tab, prefix a single prompt with /plan, or start with claude --permission-mode plan. Other agents have a similar planning or read-only step. Whichever you use, the value comes from what you do with the plan before approving it:

1. Describe the situation: current behaviour, expected behaviour, and what must not change.
2. Ask for a plan, not code, including the assumptions and open questions.
3. Read the plan with the four audit questions below.
4. Send back corrections and ask for a revised plan, still without implementation.
5. Approve only when the plan matches the task, the boundaries and the way you will verify the result.

Users should be able to save up to 5 searches in the device list
and reopen them later. Don't change the API or shared components.

Explore the device list and the existing saved-search code first.
Then propose a plan with:
- the files you will touch and the existing pattern you will follow
- assumptions and open questions
- what you will deliberately leave out
- how we will verify it (tests and manual steps)
Don't write code yet.

A plan is the cheapest version of the diff. That is exactly why it is worth fixing.

Why does a fluent plan still go wrong?

The agent writes a well-structured plan from whatever picture of the system it has, and an incomplete picture doesn't make the plan sound any less sure of itself. A tidy step list feels reviewed. It isn't. A plan can read perfectly and still:

• target the wrong area, such as the first similar component the agent found;
• add features nobody asked for;
• change a contract, a shared component or an API without need;
• skip an edge case: empty input, a page refresh, a limit;
• build a new mechanism next to an existing one;
• assume behaviour nobody confirmed.

Here is a plan close to the one I approved too quickly. The task: let users save up to five searches in the device list and reopen them later.

## Plan: saved searches

1. Extend the SavedSearch model with the active filters and sorting.
2. Add save and load handling to the existing savedSearchService.
3. Introduce a new global searchStore for the whole search module
   so saved searches, filters and results share one source of truth.
4. Add a "Save search" button to the device list toolbar.
5. Create a /saved-searches page where users can edit the criteria
   of a saved search.
6. Load a saved search in the list view and update the URL.
7. Refactor DeviceFilters to read from searchStore.
8. Add unit tests for searchStore and the new page.

Steps 1, 2, 4 and 6 serve the task. Step 3 adds an abstraction the repository does not need, step 7 exists only because of step 3, and step 5 is a feature nobody requested. Step 8 tests the new code, not the behaviour users care about. The limit of five, empty criteria and the page refresh are missing entirely.

Which four questions should you ask before approving a plan?

Each question forces a separate judgment. Together they turn “looks good” into a decision you can explain.

1. What do I accept? Name the steps that serve the task and fit the repository, so the agent knows which part of its reasoning to keep.
2. What do I reject? Cut steps that widen scope, add abstractions, touch shared code without need or duplicate an existing pattern. Give the reason in one line.
3. What is missing? Edge cases, non-goals, risks and, above all, how the result will be verified. A plan without verification has no defined end.
4. Which decision is mine? Find the product or architecture choice the agent should not make alone, and make it before implementation starts.

Plan v1, audited

What should a good coding agent plan contain?

Enough to show how the agent read the task, so you can disagree before anything is built. Polish does not matter. These do:

• Understanding: the problem in one or two sentences, in the agent’s own words.
• Area: the files it will touch and the existing pattern it will follow, e.g. savedSearchService.ts and DeviceListPage.tsx, not “the search module”.
• Order: steps small enough that a wrong one is cheap to undo.
• Risks: shared components, state, routing, contracts.
• Open questions: what it does not know and should not assume.
• Non-goals: what it will deliberately leave alone.
• Verification: the tests and manual steps that prove the task is done.

Which decisions belong to a human, not the agent?

Any decision that changes scope, a contract, a shared component or product behaviour. Settle who decides what before you approve:

• The agent can decide: local names, the order of small steps, using an existing and unambiguous pattern, technical details with no effect on a contract.
• The agent proposes, you approve: a new abstraction, an architecture change, a change to a shared component or contract, any extension of scope.
• The agent must ask: when requirements conflict, when two product behaviours are equally valid, when a discovery changes the original goal.
• The agent should not do alone: destructive operations, production changes, data migrations, anything with secrets, irreversible changes without a checkpoint.

Put the stop conditions into the approval message itself, in terms of this task:

Stop and ask me before you:
- touch files outside the device list and savedSearchService
- change the SavedSearch type used by other views
- decide a product behaviour the plan doesn't cover
- do anything the approved plan doesn't describe

Does every task need a plan first?

No. A small, local bug with a clear scope, an existing pattern and an easy check can go straight to diagnosis and a fix. Ask for a plan when the change touches several modules, state management, an API, a shared component, an important user flow, performance or a migration. Saved searches qualify: a model, a service, the list view, the URL and persistence. A typo in a button label does not.

What should happen before implementation starts?

The agent explores, clarifies and proposes. You decide. Put the steps in order.

Once the code exists, the audit moves to evidence: how to review AI-generated code in a React or Angular app.