Plan first: reviewing and steering the agent's plan

A wrong direction costs a sentence to fix in a plan and an hour to fix in a diff. That’s the whole argument for planning first.

For any task bigger than a quick fix, I ask the agent to read the code and propose a plan before it touches a file. Then I review the plan the way I’d review a colleague’s approach at a whiteboard.

The plan-first loop

1. 📋BriefGoal and acceptance criteria
2. ↓→
3. 🔎PlanAgent reads code, proposes steps, no edits
4. ↓→
5. 🧐ReviewYou check the approach and the red flags
6. ↓→
7. 🎯SteerShort, precise corrections
8. ↓→
9. ⚙️ExecuteAgent builds against the approved plan

↺ Re-plan when reality disagrees with the plan

Some agents have a dedicated read-only planning mode. If yours doesn’t, just ask for it in plain words.

Read the brief below. Before changing any file, explore the relevant code
and reply with a plan:

1. What you found: the files and patterns that matter, in 3-6 bullets
2. Your approach, as numbered steps small enough to commit one by one
3. Files you'll create or change
4. Assumptions you're making and questions for me
5. How you'll verify each acceptance criterion

Don't write code yet. Wait for my go.

[brief]

The “assumptions and questions” part is the most valuable. It’s where the agent tells you what it had to guess.

Red flags in a plan

Flip the cards. Each front is something I regularly see in agent plans, each back is what I do about it.

🃏 Plan red flags

Tap a card to flip it

It invents a new helper when one already existsPoint to the existing one by path: “Use formatMoney in src/lib/money.ts instead.”It touches files you didn’t expectAsk why. Either it found something you missed, or it’s drifting out of scope.No mention of testsAsk how each acceptance criterion will be verified, and where the new tests go.Vague steps like “update the logic”Ask for the specific functions and the expected behavior change.Zero questions or assumptionsSuspicious on anything non-trivial. Ask: “What did you have to assume?”It adds a dependencyCheck it’s needed. Often the standard library or an existing package already does it.One giant step at the end: “implement the feature”Ask it to break that step into commits you could review one at a time.

Steer in a few lines

When the plan is 80% right, don’t rewrite it. Answer its questions and correct the specific points, then approve.

Once execution starts, the plan isn’t sacred. If the agent hits something the plan didn’t anticipate, I want it to stop and say so, not quietly improvise. I add that as a line in the brief: “If the plan stops making sense, stop and tell me.”

Before you move on

✅ Key takeaways

0 / 5 completed

• For non-trivial tasks, I get a plan before any file is edited.
• I ask for assumptions and questions, and I read them first.
• I check plans for the red flags: reinvented helpers, surprise files, no tests, vague steps.
• I steer with short, specific corrections instead of rewriting the plan.
• I tell the agent to stop and report when the plan stops making sense.

↺ Reset