Is plan mode dead? What changes in your AI agent workflow

You turn on plan mode. The agent reads 40 files and hands back a plan two screens long. You approve it without really reading it. It runs and does something a little different from what was written. If that sounds familiar, Ayman Nadeem's post Plan mode is dead will make sense to you. The argument is simple. Plan mode is the mode where the agent only plans and touches nothing. It may have become more ritual than tool.

I agree with most of it. I disagree with the death certificate. Here's why.

What plan mode is and why it existed

Almost every AI coding tool has some version of it. Claude Code, Cursor, Copilot, Codex. The agent goes read-only. It explores the repository, asks questions and proposes a step-by-step plan. It only starts editing files after you approve.

The logic was sound. Early agents were expensive, slow and a bit clumsy. A bad run could cost 10 minutes and a pile of tokens. It could also leave the repository in a state you had to undo by hand. Planning first was a seatbelt. It was cheaper to get it wrong in text than in code.

The problem is that the math has changed.

Why people say plan mode is dead

Here's the thesis in my own words. Executing is now cheaper than planning. And when executing is cheap, a written plan loses value.

Think about what changed in a short time:

• Models got much faster and more accurate on medium-scope tasks.
• Tools gained checkpoints and rewind. If it goes wrong, you roll back.
• Git worktrees became the standard way to run an agent in isolation without messing up your branch.
• Cloud sandboxes stopped being a luxury.

With all that, the "plan, approve, execute" flow starts to feel like bureaucracy. A markdown plan is a promise. The agent says "I'll change useAuth, create a middleware and adjust three tests." You read it, it sounds reasonable, you approve. But you can't know if the plan is right until you see the code running. A plan doesn't compile.

A plan is a hypothesis. A diff is an experiment.

There's also a side effect few people admit. Long plans lead to lazy approvals. Nobody carefully reads the fifth bullet of a 30-line plan. You approve out of fatigue. In practice, plan mode turned into an "ok, go ahead" button with extra steps.

What changes in your workflow in practice

If you take plan mode out of the center, what replaces it? In my day to day, three things: isolation, acceptance criteria and ruthless discarding.

First, isolation. Instead of asking for a plan, I state the goal and let the agent run somewhere mistakes cost nothing.

git worktree add ../app-attempt-1 -b agent/refresh-token
cd ../app-attempt-1
# run the agent here, free to edit

If it turns out bad, I delete the folder and that's it. If it turns out good, I open a PR. Two attempts in parallel cost less than half an hour arguing over a plan.

Second, acceptance criteria. The plan that really matters is the one that says when the task is done. And that fits in a test. Before asking for the feature, I write the contract (or ask for it to be written):

import { test, expect } from 'bun:test'
import { refreshSession } from './session'

test('refreshes the token when less than 5 minutes remain', async () => {
  const session = { expiresAt: Date.now() + 4 * 60_000, refreshToken: 'abc' }
  const next = await refreshSession(session)
  expect(next.expiresAt).toBeGreaterThan(session.expiresAt)
})

test('does not refresh a token that is still valid', async () => {
  const session = { expiresAt: Date.now() + 30 * 60_000, refreshToken: 'abc' }
  const next = await refreshSession(session)
  expect(next).toBe(session)
})

This test is a better plan than any markdown list. It's verifiable. The agent can iterate until it passes, and I don't have to take its word for it.

Third, ruthless discarding. This is the hardest one if you come from the old workflow. When the agent gets it badly wrong, the urge is to fix it in the chat: "no, go back, do it this way." Often it's faster to throw it away and start over with a better prompt. The polluted context of a bad attempt gets in the way of the next one.

Put it all together and the workflow looks roughly like this:

1. Write the goal in two or three sentences.
2. Define the acceptance criteria, ideally as a test.
3. Run the agent in isolation, in a worktree or sandbox.
4. Review the diff, not the plan.
5. If it's no good, discard it and tweak the prompt.

Notice that human review didn't go away. It just moved. You stop reviewing intent and start reviewing results.

Where plan mode still saves you

This is where I disagree with the title. There are situations where planning first is still the right call. Ignoring that is asking for a headache.

Irreversible operations. Database migrations are the classic example. If the agent is going to touch a PostgreSQL schema with production data, I want to see the plan first. A DROP COLUMN has no Ctrl+Z. A worktree won't protect your database.

-- this one I want to read before, not after
ALTER TABLE orders DROP COLUMN legacy_status;

A codebase you don't know. When I join a new project, plan mode works more as a reading tool than a planning one. Asking the agent to explore and explain how the auth flow works, without touching anything, is a great way to learn the terrain.

Changes that cut across a lot. Swapping the state manager of an entire React Native app. Migrating from Express to Hono. Renaming a core domain concept. Here the plan is for aligning with the team, not with the agent. It's a decision document.

High cost per run. If each agent run takes 20 minutes because of a native build or a heavy test suite, mistakes get expensive again. The math from the start of this post applies again.

So for me, plan mode isn't dead. It got demoted. It's no longer the default for every task. It became a tool for specific cases. Like the debugger: you don't open it for every bug, but when you need it, you really need it.

Is it worth changing how you use agents?

It's worth trying for a week. A simple experiment: take your small and medium tasks (a bug, a new endpoint, a component, a local refactor) and skip plan mode. Go straight to isolated execution with clear acceptance criteria. Write down how long each one took and how many times you had to throw work away.

My bet is you'll notice two things. First, a lot of your plan approvals were automatic. Second, the time you spent reading plans pays off more when spent reading diffs.

And what if the agent screws up? Great, it was in a throwaway folder. Better than screwing up after you approved a nice-looking plan. At least now it's not your fault for saying ok.

My take

The strongest point of the post isn't about one mode in one tool. It's about where control lives. For a long time we thought controlling the agent meant controlling what it intends to do. In practice, real control means having tests that tell you if it's right and an environment where mistakes are cheap.

If your project doesn't have that, no plan mode will save you. If it does, you barely need one.

That's how I've been working on my projects lately, and you can see some of the results in the projects I've published here.

Do you approve 30-line plans without reading the fifth bullet? I used to do that too.

I read "Plan mode is dead" by Ayman Nadeem, and I agree with most of it. Executing got cheaper than planning.

A plan is a hypothesis. A diff is an experiment. These days I run the agent in an isolated worktree, define the acceptance criteria as a test and review the result, not the intent.

But I won't sign the death certificate. Database migrations, unfamiliar codebases and changes that cut across the whole team still call for a plan first. A DROP COLUMN has no Ctrl+Z.

Plan mode isn't dead. It got demoted. Real control means having tests that tell you if it's right and an environment where mistakes are cheap.

I wrote on the blog about how this changed my workflow. How have you been using plan mode day to day?

#AI #AIAgents #SoftwareDevelopment #ClaudeCode #Productivity