Start practising

TIPS & TRICKS · AGENTS · WORKFLOW

Plan Before You Build: Plan Mode, Then Execute

For any change bigger than a quick fix, have the coding agent read and plan first, review the plan, then let it build. Here is how, and when to skip it.

3 Nov 2026 · 5 min read

Coding agents are eager. Ask for a feature and they start editing files in the first minute. For a one-line fix, that is exactly what you want. For anything bigger, it is how you end up reviewing six hundred lines built on a wrong assumption that a two-minute conversation would have caught.

The fix is a simple habit: plan first, then build. Ask the agent to explore and propose a plan without changing anything, read the plan, correct it, and only then let it write code.

Why planning first works

A plan is cheap to change. Code is not. If the agent misunderstands where data comes from, or picks a library you are trying to remove, you want to find out while it is one line in a plan, not after it is threaded through twelve files.

Planning also changes how the agent works. When it has to write down “step 3: add a status column to orders”, it has to commit to an approach, and you can see the approach. Without a plan, the approach only exists implicitly, spread across edits.

And a written plan survives a long session. As the conversation grows, early details get summarised away. A plan saved in the conversation, or in a file, keeps the agent pointed at the same target on step twenty as on step one.

How to do it

Many coding agents have a dedicated plan mode that reads but cannot edit. If yours does, switch it on. If not, say it plainly:

Before changing anything, read the relevant code and propose a plan. Do not edit files yet. The plan should list the files you will change, what changes in each, any new dependencies, how you will test it, and open questions for me.

Then actually read what comes back. You are checking for four things:

  1. Did it understand the goal? The plan’s first line should restate what you want in its own words. If it is off, stop here.
  2. Is the approach the one you would choose? Look for the big decisions: new table or new column, new endpoint or extend an old one, new library or existing helper.
  3. Is anything missing? Migrations, tests, docs, the mobile layout, error states, the second place that uses the same function.
  4. Are the open questions real? Answer them. A good plan surfaces the questions you had not thought of yet.

Reply with corrections, short and specific: “Use the existing useStore hook instead of a new context. Skip step 5; we do not need an admin view yet.” Then tell it to proceed.

A worked example

Task: “Show a weekly streak on the dashboard.”

A plan might come back like this:

  1. Add getStreak(log) in src/lib/streak.ts: count consecutive weeks with at least one solved item.
  2. Unit tests for empty log, one week, a gap, and a year boundary.
  3. Render a small card on /app next to the progress card.
  4. Question: should a week start on Monday or Sunday? Should System Design episodes count, or only problems?

That is a good plan. It names the files, includes tests, and asks two questions you need to answer. Without planning, the agent would have silently picked Sunday and counted only problems, and you might not have noticed for weeks.

You reply: “Monday, in the user’s local time. Count everything in the log.” Now the build will match what you want.

Execute in steps you can check

For larger plans, do not approve everything in one go. Ask the agent to do steps one and two, run the tests, and stop. Review. Then continue. Each checkpoint is a moment where a small mistake stays small.

It also helps to ask the agent to tick off plan steps as it goes, and to say explicitly if it needs to change the plan. “I changed step 3: the progress card is a client component, so the streak card has to be one too.” A plan change you can see is fine. A silent one is how surprises get in.

When to skip it

Planning has a cost: a few minutes and some tokens. Skip it when:

A good rule of thumb: if you would want a teammate to tell you their approach before starting, ask the agent for a plan.

Keep good plans

When a plan turns out well, save it next to the code, in the pull request description or a docs/ note. It records why things were built the way they were, and it is a ready-made template the next time a similar task comes up.

Takeaway: for anything bigger than a quick fix, ask for a plan with files, changes, tests and open questions, correct it, then let the agent build in steps you can check. Changing a plan costs a minute; changing code built on a wrong plan costs an afternoon.