Is plan mode dead? What changes in your workflow with agents

You hit Shift+Tab, the agent enters plan mode and spits out a 14-step plan. You read all of it and approve. By step 3 it finds out the file it was going to edit doesn't even exist anymore. That scene is the starting point of a post that got shared a lot in the last few weeks: Plan mode is dead, by Ayman Nadeem. The title is a provocation, but the question is serious: is plan mode still worth the time you spend on it?

I use coding agents every day, on React, React Native and Bun backend projects. So here's my take, with what works and what doesn't in my workflow.

What plan mode is, and why it exists

Plan mode is the mode where the agent reads the code, thinks and proposes a plan, but doesn't change any files. Claude Code, Cursor and the rest all have some version of it. You review it, tweak it and only then let it run.

It came from a real problem. In 2024 and early 2025, models would go off and edit ten files based on a wrong assumption. You only noticed the damage in git diff. Plan mode was a brake: "before you touch anything, tell me what you're going to do".

It made total sense when:

• the model got the architecture wrong a lot;
• undoing changes was tedious and manual;
• every run was slow and expensive.

All three have changed a lot.

Why people say plan mode is dead

The thesis, as I read it: a plan written before the code goes stale too fast. The agent plans based on what it thinks it will find. When it starts executing, it finds something else. The plan turns into an outdated document that you carefully approved and nobody follows.

And current models plan while they execute. They read a file, run a test, adjust course. The "think, act, observe" loop got short enough that splitting "think" into its own phase feels like bureaucracy.

Add checkpoints, rewind and cheap Git to that, and mistakes got cheap too. If the agent went the wrong way, you're back in two seconds.

A good plan is one that survives first contact with the code. Most don't.

Here's an example of mine from last week. I asked an agent to migrate an endpoint from Express to Hono in a Bun service. In plan mode, it proposed creating a middleware adapter, rewriting the validation and updating the tests. I approved. During execution, it found out the validation already used Zod and that Hono had a validator ready to go. Half the plan went in the trash. I would have saved about 4 minutes of reading just by letting it start.

Where plan mode still saves you

This is where I disagree with the funeral. Plan mode lost its value as a default ritual. It didn't lose its value as a tool.

There are three situations where I keep using it:

1. Changes that touch data. A PostgreSQL migration, a script that updates records in production, anything without a real rewind. The agent's checkpoint undoes the file. It doesn't undo the UPDATE that already ran on the database.

-- there is no Ctrl+Z for this
ALTER TABLE orders DROP COLUMN legacy_status;

Before anything like that, I want to see the plan. And I want to see it again afterwards.

2. When I don't know what I want. Sometimes the plan isn't for the agent, it's for me. Asking for a plan is a quick way to see the architecture options without writing any code. It works like a rough draft of an RFC.

3. A large codebase the agent doesn't know. In a monorepo with several apps and shared libs, a short plan keeps it from changing a lib used by five projects while assuming only one consumes it.

Outside of that, I agree: plan mode became a habit, and a habit without a reason is a cost.

What changes in your workflow in practice

If you're going to drop plan mode as the default, you need to put something in its place. Without that, you're just letting the agent run loose. Here's what has worked for me:

Smaller tasks. Instead of "refactor the payments module", I ask for "extract the shipping calculation into a pure function with a test". A small task doesn't need a plan. The diff is the plan.

Tests as a contract. I write the test first, or ask for it. The test says what needs to be true at the end. The agent can take whatever path it wants, as long as the test passes.

import { expect, test } from 'bun:test'
import { calcShipping } from './shipping'

test('free shipping above 200', () => {
  expect(calcShipping({ subtotal: 250, uf: 'SP' })).toBe(0)
})

This communicates intent better than any 14-step plan written in prose.

Small, frequent commits. Every step that works becomes a commit. If the agent gets lost, git reset and you're done. The history becomes the plan, only written afterwards, when it's already true.

Rules in the project's instructions file. What I used to check in the plan (don't touch this folder, use this component pattern, never run a migration on your own) now lives in CLAUDE.md or its equivalent. I write it once and it applies to every task.

Notice that none of this is new. It's good engineering practice that existed before AI. The agent just made it more expensive to ignore.

To plan or not: a simple rule

If you want a rule of thumb, I use this question: how much does it cost to undo?

• Undoing costs a git checkout: let the agent run directly.
• Undoing means touching a database, infra, a public API contract or someone's money: plan mode, and read the plan carefully.
• You don't even know what you want yet: plan mode as a brainstorm, with no commitment to follow it.

In practice, about 80% of my tasks fall into the first case. In other words, I spent most of my time reviewing plans for changes that cost nothing to revert. Looking back, that was a lot of wasted time.

The risks of killing plan mode too early

The honest objection deserves a hearing. Skipping the plan has two real risks.

The first is lazy review. If you didn't read the plan, you'll have to read the diff. And a big diff generated by an agent is tiring to review. The temptation to merge without looking closely is huge. Small tasks fix most of this, but it takes discipline.

The second is cost. An agent that runs, fails and redoes the work burns tokens. On a pay-per-use plan, three wrong attempts can cost more than one well-made plan. It's not a decisive argument, but it counts if you're the one paying the bill.

And there's a third one, more subtle: plan mode was also a moment for you to think. Without it, it's easy to outsource all of the reasoning. I've seen people (me included, I admit) accept a solution just because the test passed, without understanding why it worked. That's when 3 a.m. sends the bill.

My take

Plan mode isn't dead. What died is plan mode as a required step before every task. It becomes a tool for exceptions: for when mistakes are expensive, or when you're still deciding what to do.

For everything else, the best plan is small tasks, tests first and frequent commits. It looks less sophisticated. In practice, it works better, because the plan becomes something you verify by running it, not a promise you read and approved.

If you want to see how this workflow shows up in real projects, take a look at the projects I've been working on.

I reviewed 14-step plans for months. 80% of them were for changes a git checkout could undo.

Plan mode isn't dead, but it's no longer a required step. A plan written before the code goes stale at the first file the agent opens.

These days I ask a single question: how much does it cost to undo?

If it's a migration, a database or someone's money, I want to see the plan. And I read it twice.

For everything else, I use small tasks, tests first and frequent commits. A test communicates intent better than any plan written in prose.

I wrote on the blog about how this workflow plays out in my day to day. Do you still approve a plan before everything?

#ClaudeCode #AIAgents #SoftwareEngineering #DevProductivity #Bun