One Claude Code Tip a Day: Critique the Plan First

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The real failure: coding from a confident but untested plan

The fastest way to waste a Claude Code session is to ask for implementation before the model understands the repo. It will often produce a plausible plan, touch the obvious files, and still miss the thing that breaks the feature: a hidden validation rule, a stale test fixture, a CSS class that overrides the new state, or a deployment-only environment variable. Today’s habit is simple: before Claude Code writes code, make it attack its own plan.

Start with read-only context

Open Claude Code in the correct repository, then begin with a read-only instruction. The important phrase is not “please implement”; it is “do not edit anything yet.” For example: “Read the project structure and the files related to this checkout error. Do not edit anything yet. First summarize how the current implementation works. Then identify risks, missing assumptions, and likely failure points. Only after that, propose a minimal implementation plan.” This changes Claude from a code generator into a reviewer. You are buying ten minutes of risk discovery before the expensive part begins.

Ask for plan critique as a separate step

Once Claude proposes a plan, do not accept it immediately. Use a second prompt: “Before editing, challenge your own plan. What could be wrong? Which files or tests would prove the plan is correct? Which behavior should we verify manually in the browser or logs?” This is where useful mistakes surface. In a frontend bug, Claude may notice that the data is present but invisible because of CSS. In an API bug, it may realize the failing path only happens when a webhook retries. In a migration, it may catch that local SQLite behavior differs from production Postgres.

A realistic session pattern

Imagine you are fixing a cart page where discount text sometimes disappears after applying a coupon. A shallow prompt would be: “Fix the coupon display bug.” A stronger Claude Code workflow is: “Inspect the cart page, coupon component, styling, and tests. Do not edit. Explain the render path for the discount label and list three likely causes.” After Claude answers, ask: “Now critique your hypothesis. What evidence would disprove it? What exact command or browser check should we run before editing?” Only then let it make the smallest change. This creates a loop: read, hypothesize, challenge, edit, verify.

Verification should be part of the plan, not an afterthought

A plan without verification is just a guess with bullet points. Before editing, ask Claude to name the proof it expects. Good proof is concrete: “run npm test -- cart,” “open the checkout story in Storybook,” “grep the server logs for coupon_applied,” “compare git diff before committing,” or “use the browser to confirm the label remains visible in light and dark themes.” If Claude cannot say how the fix will be verified, the plan is not ready. Push it to define a success signal before it touches files.

Watch for common failure modes

Plan critique is not magic. Claude can over-index on the files it has already read, ignore race conditions, or propose a broad refactor when a small patch is safer. When that happens, narrow the scope: “Assume we can change only one component and one test. What is the minimal safe patch?” If the first implementation fails, do not restart from zero. Feed back the exact failure: test output, browser screenshot description, deployment log, or git diff. Then ask for a second-pass correction: “Given this failure, revise the diagnosis before editing again.”

The command habit behind the tip

This workflow pairs well with Claude Code’s normal terminal loop. Use shell commands for evidence, not decoration: “Run the focused test and summarize only the failing assertion,” or “Show me the git diff and point out any unrelated changes.” If you use @file or @folder references, attach the smallest relevant context instead of the whole repo. The goal is to make Claude’s working set match the bug, then force it to reason about uncertainty before it writes.

Rule of thumb

If the task could break production, require two answers before code: first, “how does the current system work?” and second, “why might your plan be wrong?” Claude Code becomes dramatically more useful when you treat planning as a reviewable artifact. The best sessions are not one-shot miracles; they are tight loops where Claude reads, critiques, edits, verifies, and corrects itself with evidence.