Not Every Session Needs a Plan
Plan mode is a tool, not a default
Most coding agents ship with a plan mode. Some have already removed it — Amp dropped theirs, deciding it added ceremony without adding value. Others still treat it as the recommended starting point: outline the approach, list the files, describe the changes, get approval, then execute. It sounds disciplined. It also sounds familiar. It is waterfall with a different font.
The instinct comes from a reasonable place. You want the session to go well. You want to avoid wasted work. So you front-load specification. But the problem is the same one that sank waterfall in teams: you cannot specify what you do not yet understand. A plan written before you have touched the code is a guess dressed as a decision. It feels productive. It is often wrong.
Planning is not the problem
Planning itself is fine. Boris Cherny, one of the creators of Claude Code, starts most sessions in plan mode:
and iterates on the plan until he likes it. That works because he treats the plan as a conversation, not a contract. His tasks are pull-request-sized features with known scope. The plan aligns direction. Then he moves.
The problem starts when planning becomes a default for every session. When you reach for plan mode before a bug fix, before a spike, before an exploration — before you even know what the task demands. That is not discipline. That is comfort. You are writing a PRD because it feels productive, not because the task needs one.
Match the workflow to the task
Not every task needs the same starting point.
If you are building a feature with clear scope — a new API endpoint, a settings page, a migration — plan mode earns its keep. You know roughly what the result looks like. A brief plan aligns direction before the work begins.
If you are fixing a bug where the behavior is already clear, a plan is overhead. A failing test is a better starting point. Pin the contract, confirm the failure, then fix it. I wrote about this approach recently: make the test fail first, then make the narrowest change that turns it green.
If you are exploring — spiking an idea, trying a library, feeling out an architecture — you do not know enough to plan. Start coding. Let the shape emerge. Planning an exploration is a contradiction.
The session is a conversation
The deeper issue is how you think about the session itself.
Plan mode tempts you into a handoff mentality: specify, then execute. But the best sessions are not handoffs. They are conversations. You start with a direction, the model makes something, you react, it adjusts, you push further. The work improves because both sides contribute judgment along the way.
That is the agile insight applied to a different scale. You do not need a two-week sprint to benefit from iteration. A thirty-minute session works the same way. Start with enough direction to move. Adjust as you learn. Trust that course correction is cheaper than perfect specification.
Pick the right tool
Plan mode is a tool. Red-green TDD is a tool. Freeform exploration is a tool. The mistake is picking one and applying it everywhere.
Plan when the scope is known. Test-first when the contract is clear. Explore when it is not. And in every case, stay in the loop. The session is not a spec you hand off. It is a conversation you steer.