AI Keeps Reworking Your Code? Plan First, Code Later to Slash Rework

Why Does AI Code Always Need Rework?

You ask AI to "add a category statistics feature," and it immediately changes seven or eight places—even the layout—but that's not what you wanted, and you don't even know where to start rolling back. This is the reality for many people using AI for coding: AI misunderstanding plus direct code output leads to large-scale rework. The problem isn't that AI isn't powerful enough—it's that the step of aligning on a plan is skipped.

According to Bilibili creator "AI Evolution - Peanut," one simple principle can significantly reduce rework: for any sizable change, have AI produce a plan first, then let it write the code.

Plan Mode: Have AI Look at the Blueprint Before Starting Work

Before renovating, the contractor shows you the blueprints. Changing a line on the blueprint costs almost nothing; changing it after the walls are up means tearing everything down. Same with AI coding—tearing down and redoing written code costs far more than adjusting at the planning stage.

Mainstream AI coding tools have built-in "plan mode":

• Claude Code: Press Shift+Tab to switch to plan mode, or add /plan before your instruction. It reads files, understands the current state, and produces a plan—but does not modify your code. Once the plan is written, it asks whether to proceed—you can approve or ask it to revise further.
• Codex: Type /plan, and it likewise presents an execution plan first; you review it and give the go-ahead if it looks right.

Don't want to switch modes? One sentence does the trick:

Don't write code yet—first tell me how you plan to do it.

Plan Mode is an interaction paradigm introduced by AI coding tools in recent years: the model traverses project files in a read-only state, understands the existing code structure and dependencies, and outputs a structured execution plan (typically including change goals, affected files, execution steps, and verification methods), producing no write operations during this period. Only after the user reviews, revises, and approves the plan does the model enter the execution phase. Its technical significance lies in decoupling "intent alignment" from "code generation"—the cost of generating a plan is far lower than generating code, so front-loading error correction can significantly reduce wasted token consumption and rollback costs. For multi-file, cross-module changes, plan mode also lets the model build a global view first, avoiding local optima and style drift caused by editing while writing.

Got the Plan? Focus on Three Things

AI's plans are often very "full," but you need to lock onto three things:

1. Which files will be changed, and in how many steps—Does the scope exceed your expectations? AI often wants to change far more places than you'd think.
2. How each step will be checked—Is there a verification step, so you're not left not knowing whether it's right or wrong after the change?
3. Where it's unsure and needs to ask you—AI asking questions proactively is a good thing; it means it's aligning on requirements.

See a term in the plan you don't understand? Don't be shy—just ask. Think the scope is too big? Ask "why" first.

Verification Step refers to the executable checks paired with each change in the plan—for example, running unit tests, executing lint and type checks, starting a local service to manually verify the page, or comparing output differences before and after the change. AI-generated code often "looks right," but may introduce unused dependencies, break existing interfaces, or miss edge cases; without explicit verification points, errors accumulate all the way to the final run stage, at which point debugging costs multiply. When reviewing the plan, confirming each step has a corresponding check essentially provides the basis for subsequent "step-by-step reporting"—you know right away whether each step is correct, rather than discovering the direction was wrong only after everything is done.

Scope Creep is a frequent cause of AI coding rework: to "do a good job," the model often refactors adjacent modules, swaps out libraries, adjusts layouts, or unifies code style along the way, causing actual changes to far exceed user expectations. Because these changes are often coupled, users find it hard to cleanly revert just one part—they can only discard everything or hand-pick. The first thing to check when reviewing a plan is "which files will be changed and in how many steps," and explicitly write the change boundaries into the plan; once you find the scope exceeds expectations, ask for justification at the planning stage and demand it be narrowed, rather than trimming after the code is in place.

How to Revise the Plan at Minimal Cost

The earlier you revise the plan, the lower the cost. The right way to revise:

• Edit directly: Don't be embarrassed—e.g., "add the color in step two first, don't touch anything else, don't introduce new libraries."
• Ask about anything uncertain: Resolve every ambiguous point in the plan here, not after the code is written.
• Small changes don't need a plan: For little things like changing text or a color, just say it directly—avoid over-processing.

After Approval, How to Proceed Without Drifting

When approving the plan, it's recommended to add:

Do it according to this plan, and stop after each step to tell me the result.

This way AI executes step by step and reports after each one. If you find the direction is off midway, go back and re-align on the plan, rather than forcing changes in the code.

Two sentences you can copy directly:

When requesting the plan: Don't write code yet—read the current project and tell me which files you plan to change, in how many steps, how you'll check each step, and ask me first if anything is unclear.

When approving: Do it according to this plan, and stop after each step to tell me the result.

One-Sentence Summary

For any sizable change, look at the blueprint before starting work. Changing one sentence in the plan saves far more than reworking the code.

Next episode preview: Tired of re-explaining the same rules every time? You can write a "manual" for the project—codify the conventions so AI reads them before starting work each time.