Don't let your coding agent code first: plan, then approve

A coding agent that writes code from your first prompt can build a working solution to the wrong problem. The fix is a workflow with a stop in it. The agent investigates and writes a plan, you approve it, and only then does it implement and verify. Below are the five stages, a master prompt for any agent, and what plan or read-only modes really block in seven agents.

Understand → Investigate → Plan → Approve → Implement → Verify → Review diff → Done

This is part 2 of a series. Part 1 set up the project around the agent: instructions, docs, checks. This part is about running one task well. The tool behaviour here comes from each tool’s official docs, last verified on 4 October 2026; none of it was tested for this post.

“Just build this” skips the expensive part

Most developers use a coding agent like this:

Prompt → AI writes code → Run app → "Looks good"

It’s fast. But fast doesn’t always mean correct.

The expensive mistake happens before any code is written. The agent may misread the existing architecture or miss a component you already have. It may not know a business rule, a dependency, a constraint or a test that covers this area. Then it builds a technically valid solution to the wrong problem, and the app still runs.

Google’s Antigravity docs say the same about planning first: “Writing code before clarifying edge cases may lead to wasted effort, unnecessary diffs, or regressions.”

Your agent doesn’t need to code faster. It needs to make fewer wrong assumptions.

Five stages, with a stop after the plan

1. Investigate: no code changes yet

In the investigate stage, the agent reads before it writes. It looks at the repository, works out the stack, finds the relevant files, reads the patterns already there and checks the constraints. No code changes yet.

An agent can only find what the project gives it. Part 1’s six layers cover what to set up before this stage, and its investigation prompt is the long version of this step.

2. Plan: then stop

A plan from the agent should tell you:

• what it understood
• which files matter
• the existing patterns it will follow
• the constraints
• what could go wrong
• the change it proposes
• how it will verify the change

Then the agent stops. Don’t let it continue on its own. Whether it really stops depends on your tool as much as your prompt.

3. Approve: you still own the decision

The approve stage is yours. The agent investigated and proposed a plan; now you review it and approve, change or reject it. AI can propose the implementation. You still own the decision, which is the human control layer from Part 1.

Before you approve, read the plan against what you asked for:

• Is the task in its own words the task you meant?
• Are the files it names real, and the right ones?
• Does it reuse existing code before adding a new pattern or dependency?
• Are the risks specific to this change?
• Does it name the tests and checks it will run?

If the answer to any of these is no, send it back with what to change. Approving the plan doesn’t approve everything after it either. VS Code’s Copilot docs put it plainly: “Approving a plan and approving tool actions are separate decisions” (planning docs).

4. Implement: the smallest maintainable change

Once the plan is approved, the agent makes the smallest maintainable change. It reuses existing abstractions, follows the project’s conventions, avoids unnecessary dependencies, keeps existing behaviour and adds or updates tests where it makes sense. Part 1’s implement and verify prompt spells this out line by line.

5. Verify: evidence, not “looks right”

The verify stage doesn’t stop at “the code looks right”. The agent runs the tests, lint, type checks and the build, then reads its own diff. Then ask it one more question: what remains unverified?

Anthropic’s best practices ask for the same kind of proof. Claude should “show evidence rather than asserting success: the test output, the command it ran and what it returned, or a screenshot of the result”. Part 4 of this series goes deeper into verification.

A “STOP” in your prompt is not a plan mode

A line like “Then STOP. Do not write code until I approve” is a request. The agent may follow it, but nothing in the tool enforces it. VS Code’s planning docs say this about asking an agent to plan in your prompt: “This request guides the agent’s behavior but does not change the session’s permissions.”

Plan modes don’t all block the same things either. Claude Code is a good example. Its plan mode lets Claude read files and run shell commands to explore, and edits stay blocked until you approve the plan. The exception is an interactive terminal session with bypass permissions available. There, a file edit or shell command it attempts during planning runs without prompting. Windsurf’s Plan mode has all tools enabled, and its Ask mode is the read-only one.

So when edits really must not happen before you approve, use your tool’s plan or read-only mode, and check what that mode blocks.

Plan and read-only modes in seven coding agents

Every row comes from the linked docs, last verified on 4 October 2026. Windsurf’s docs now redirect to Devin Desktop’s.

When should you skip planning?

Not every change needs a planning ceremony. A tiny change, like renaming a variable, fixing a typo, changing a label or updating a version, you can ask for directly.

A medium change is where investigation and a plan start to pay off: a new component, an API change, a database or authentication change, a refactor.

A large change gets the full workflow: a new feature, an architecture change, a payment flow, a data migration, a security-sensitive change, or a change across services.

The vendors’ docs draw the line in a similar place. The rule in Anthropic’s best practices is “If you could describe the diff in one sentence, skip the plan”. Antigravity’s plan docs name “database migrations, authentication overhauls, or security-sensitive patches” as the changes where an upfront checklist is critical.

The master prompt: four phases in one paste

Use the master prompt for a medium or large change, in any agent. It is the short, all-in-one version of Part 1’s prompts. If your agent has a plan or read-only mode that its docs say blocks edits, start in it. Then the tool enforces the stop after Phase 2.

Master prompt: understand, plan, implement, verify

You are working inside an existing software project.

Task: <describe the task>

Do not start coding immediately.

PHASE 1: UNDERSTAND

Inspect the repository and understand:
- technology stack
- architecture
- relevant modules
- existing patterns
- project instructions
- applicable rules
- tests and verification commands
- relevant dependencies
- constraints

Verify important assumptions by inspecting the repository.
Do not invent files, patterns, APIs or architectural decisions.
Never print, expose or commit secret values.

PHASE 2: PLAN

Explain:
- what you understood
- files that need to change
- existing code that can be reused
- proposed approach
- risks and edge cases
- tests/checks required

Then STOP.

Wait for my approval.

PHASE 3: IMPLEMENT

After approval:
- make the smallest maintainable change
- follow existing conventions
- reuse existing abstractions
- avoid unnecessary dependencies
- preserve existing behaviour
- add/update appropriate tests
- do not commit, push, deploy, run destructive commands or make external
  changes unless I explicitly authorise it

PHASE 4: VERIFY

Run the relevant:
- tests
- lint
- type checks
- build

Then inspect the final diff.

Report:
- files changed
- behaviour changed
- tests/checks run
- results
- anything remaining unverified

If something fails, fix the underlying cause.
Do not hide or skip failures.
If two reasonable attempts fail, stop and report the failure rather than
repeatedly guessing.

Do not claim the task is complete without verification evidence.

Follow-up: what remains unverified?

An example follow-up, for when the agent says it’s done and the report feels thin.

Before you call this done, show me the evidence.

1. List each check you ran (tests, lint, type checks, build) and its result.
2. Show the final diff and point out any change I did not ask for.
3. What remains unverified? List what you could not check, and why.

Do not start new changes in this step. If a check failed, say so plainly.

Quick answers

What is an AI coding agent workflow?

An AI coding agent workflow is the order of steps you run a task in with a coding agent. A plan-first workflow goes investigate, plan, approve, implement and verify, so the agent understands the code and you agree on the change before it edits anything.

What is plan mode in a coding agent?

Plan mode is a setting where a coding agent researches the code and writes a plan before implementing. Claude Code, OpenAI Codex, Cursor, Gemini CLI, Google Antigravity, GitHub Copilot and Windsurf all have one, and what it blocks differs by tool.

Does telling an agent “do not write code until I approve” block edits?

A line like “do not write code until I approve” guides the agent but does not change its permissions, as VS Code’s Copilot docs say. To actually block edits before approval, use a plan or read-only mode that your tool’s docs say blocks edits, and check what it blocks.

When should you skip planning with a coding agent?

Skip the plan for tiny changes such as a typo, a renamed variable, a label or a version bump. Anthropic’s docs suggest skipping it when you could describe the diff in one sentence. Data migrations and security-sensitive changes deserve the full workflow.

How do you use AI coding agents effectively?

Using an AI coding agent effectively means a readable project, a task that stops after the plan, and proof of its work. Ask for test, lint and build results and the final diff before you accept the change.

Part 3 of the series compares skills, sub-agents, MCP and hooks. More on AI coding is in the AI category.