Skip to content
code-n

Planning mode

The Agent writes a plan first and only touches the project once it is approved. When that pays off and when it is just a delay.

5 minutes Updated 2026-09-13

In planning mode the Agent does not rewrite the project. It may read and it may think; at the end it writes a plan you read and approve, or send back. It is the one moment when it makes sense to wait for the Agent — before it starts writing, not afterwards.

How it is turned on

In the Conversation, under the + button, is the “Planning mode” switch. It stays on until you turn it off, and it is visible — the button is highlighted, so you will not hand over work thinking you are planning.

The Prompt field asks differently as well: “What should the Agent plan?” instead of the usual invitation.

Switching the mode calls for a restart of the Agent on the Server. That happens by itself and is a matter of a second or two — but that is exactly why the mode is not switched for every Prompt.

What cannot happen while planning

The Agent runs with writing forbidden. It cannot write a file, it cannot run a command that changes anything. It is not a promise in the task that it could overlook — it is the setting it was started with.

The plan then does not appear as an ordinary reply. The Agent submits it as a request for approval and you see the whole plan, not its beginning — for other actions it is enough to know what will run, here that text itself is the content of the decision.

Approve, or send back

With a plan you have two options and both are fine:

Approve the plan
The Agent finishes the turn and waits. A button appears under the Conversation: Run the plan — one tap instead of writing “go ahead then”. Only that sets it to work, already in the ordinary mode.
Turn it down and write what is wrong
You write what does not fit in the plan and the Agent reworks it — still planning, still without writing. This is the cheap way to steer it somewhere: fixing a plan is an order of magnitude faster than fixing finished code.

When to use it

  • For a task you are not sure you described well. A plan is the fastest check that you understood each other.
  • In an unfamiliar project. Before the Agent rewrites anything, you want to see which files it will touch.
  • For a change across the project — a refactor, a rename, a migration. There a misunderstood task shows up in fifty places.
  • When you work without approvals. Bypass and planning are a pair that makes sense: you go through the big tasks with a plan and the rest then runs without interruptions.

When not to use it

For small tasks a plan is a delay. “Fix the typo in the README” does not need a three-point deliberation, and reading it costs more than the fix.

It also does not suit cases where the Agent has to try something first to know what to propose — debugging, say, where the cause is found by running a test. While planning it may not run anything, so it would be planning blind.

A plan the Agent asks for itself

Sometimes a plan arrives even though you did not turn planning on — the Agent decides on its own that the task calls for deliberation. It behaves the same: you read it, approve it and “Run the plan” appears.

Stuck somewhere other than what is here? Write to support@coden-app.com.