You’ve got a plan in front of you. Here’s the trap: it looks thorough, it’s neatly numbered, it sounds confident — so you hit approve. Then you spend the next hour fighting the thing you just approved.
A plan is not a contract. It’s a draft. Its entire value is that it’s still cheap to argue with — and arguing is the point, not approving.
The plan is the cheapest place you will ever find a disagreement. Once the work runs, every disagreement costs a revert. Right now, it costs a sentence. So read it like you’re looking for trouble.
The four things to scan for
- Wrong assumptions. Claude guessed about something you actually know. “I’ll add a build step to compile the styles” — but your site is deliberately plain HTML and CSS with no build step. It didn’t know; now you tell it.
- Missing edge cases. The plan handles the happy path and forgets the rest. What about the empty state? The error case? The page with no posts yet?
- Scope creep. The plan is “helpfully” doing more than you asked — restyling nearby pages, renaming things, deleting files you never mentioned. Helpful-sounding, expensive in practice.
- Things it should have asked. Where should this file live? What should it be named? One page or many? If Claude picked when it should have asked, the plan is where you catch it.
What this looks like
Say you asked for a blog page added to my-site, and the plan comes back:
- Add a
blog.htmlpage with a couple of placeholder posts. - Add a “Blog” link to
index.html. - Style the posts to match
styles.css. - Clean up the old contact handler in
server/index.jswhile we’re in here.
Steps 1–3 are the blog you asked for. Step 4 is something else entirely — it rewrites your backend, which you never mentioned. That’s textbook scope creep, and it’s exactly the kind of thing a plan exists to surface before it runs. You reply: “Skip step 4 — don’t touch the server/ code, just add the blog.”
That one sentence just saved you from debugging why your contact form broke an hour from now.
How to push back
You don’t need special syntax. Plain English, specific:
- “Keep it plain HTML and CSS — no build step.”
- “Don’t touch the backend — leave
server/alone.” - “What does the page look like with no posts yet?”
- “Put the posts in one
blog.html, not a separate file each.”
Claude revises the plan and shows you again. You’re still in plan mode; still nothing has changed. You can go around as many times as you need. The going-around is the work right now.
What’s next
Once you approve a plan, Claude starts working — and for a multi-step task, it’ll often keep a running checklist you can watch. The next lesson is what that checklist is, and why it’s quietly one of your most useful tools.