Stop Letting Your AI Code Before It Plans

The most expensive thing an AI coding assistant does is start typing. Not because the code is bad - because it is confident, plausible, and built on a guess about what you wanted. I spent months in the loop of prompt, watch it code, realize it misunderstood, throw it away. Then I stopped letting it code at all until it showed me a plan. That one change cut my rewrites more than any model upgrade ever did.

The rewrite loop, named

You know the shape of it. You describe a feature in two sentences. The assistant produces 200 lines in thirty seconds. You read them and something is off - it invented an endpoint, picked the wrong table, restructured a file you never mentioned. So you correct it. It patches. The patch conflicts with an earlier guess. Three rounds later you close the chat and write it yourself.

The trap is that the failure feels like a code problem, so you respond with code feedback. It never was. The model misunderstood the task before line one, and every line after that was the misunderstanding compounding. You cannot review your way out of a wrong plan by reviewing the code it produced.

Humans figured this out long ago. No serious engineer starts a multi-file change without saying, out loud or in a doc, what they are about to do. We just forgot to ask the same of the machine, because the machine types so fast that planning feels like a delay.

Plan first, in one sentence

The fix: make the model produce its intentions in plain language, get those intentions corrected by you, and only then let it touch a file.

In Claude Code this is a built-in mode - plan mode locks the assistant out of editing anything. It can read the codebase, search, and think, but the only thing it can produce is a written plan you approve or reject. In any other tool you can fake it with one line at the top of your prompt: "Do not write any code yet. First tell me your plan - files you will touch, the approach, what could break - and wait for my go."

What comes back is short. Ten lines, maybe twenty. And those ten lines are where every expensive misunderstanding surfaces while it still costs nothing to fix.

What a plan review catches

A real example from this blog. I asked for instant navigation between posts. Left to code immediately, the assistant would have reached for the obvious hammer: client-side caching of everything, stale posts included. In the plan, that intention was a single line - "cache post pages indefinitely" - and it took me five seconds to say no, posts change after publishing, revalidate them. Caught in the plan, that was one corrected sentence. Caught in the code, it would have been a shipped bug that only shows up the next time I edit a post.

That is the pattern every time. Plans expose three things code hides:

• Wrong assumptions. "I will add this to the users table" - we do not have a users table, we have profiles. One line to correct.
• Wrong scope. The plan lists seven files for what you thought was a two-file change. Either you misjudged the task or the model did. Better to find out now.
• Wrong priorities. It plans to refactor first and fix the bug second. You wanted the opposite. Reorder before it burns twenty minutes on the refactor.

Reading a ten-line plan takes under a minute. Reading 200 lines of diff to reverse-engineer what the model thought you meant takes fifteen, and you usually miss the assumption anyway - the code looks fine, the assumption is invisible.

What went wrong when I overdid it

Honesty section. Once plan-first clicked, I started demanding a plan for everything, and it turned into ceremony:

• Planning a one-line fix is absurd. Waiting for a plan to change a button label doubles the time of a ten-second task. I did this for a week before admitting it.
• A plan is not a spec. I approved plans that were vague - "improve the caching" - and got the same misunderstandings as before, just with an extra step. If the plan does not name the files and the approach, it is not a plan, it is a vibe.
• Approval fatigue is real. Rubber-stamping plans without reading them is worse than no plans - you get the delay and none of the protection. The plan only works if the human in the loop actually reads it.

The rule I landed on: the plan step earns its cost when the task spans more than one file, touches anything with state, or contains a word the model could interpret two ways. Below that, let it type.

Task	Plan first?
Rename, typo, single-line fix	No - just let it code
One file, clear scope	Optional - a quick "state your approach" line
Multi-file feature or refactor	Always
Anything touching data, caching, auth	Always, and read it twice

Making it stick

Three habits that turned this from advice into default behavior:

1. Put the trigger in the prompt template. My standing instruction ends with "for any change spanning multiple files, present a plan and wait." I stopped relying on remembering to ask.
2. Reject vague plans like vague PRs. If a step says "update the relevant components", ask which ones. The precision you demand in the plan is the precision you get in the code.
3. Correct the plan, not the code. When something is off mid-task, do not patch the output - go back and fix the sentence in the plan that caused it. The code follows the plan; edit upstream.

If you read my post on running a team of agents, this is the same lesson at a smaller scale. There, a planner agent sat between exploration and implementation, and the one bug that mattered was caught before the code existed. You do not need five agents to get that benefit. You need one sentence: show me the plan first.

The fast part was never the typing

The model can produce code faster than you can read it. That was never the bottleneck. The bottleneck is agreement - making sure the thing it is about to build is the thing you meant. Plans are the cheapest place that agreement can happen, and the only place where being wrong costs a sentence instead of a session.

Next time you are about to hand the assistant something bigger than a bug fix, try it once: no code yet, plan first. Count how many corrections you make before a single line exists. Every one of those was a rewrite you just did not have to do.