The AI Plan Before Code

The Common Failure: Starting in the Middle

AI coding tools are designed to move quickly from request to patch. That is useful when the task is tiny and obvious. It is dangerous when the task hides product judgment, cross-file contracts, missing tests, security assumptions, or old code the model has only partly seen.

The tempting prompt is direct: "Fix the checkout bug." "Refactor this service." "Add OAuth." "Make the dashboard faster." The assistant responds with code, and now you are reviewing a solution before you have agreed on the problem. That reverses the order of good engineering.

A plan-before-code workflow inserts one deliberate pause. You ask the model to describe the intended change before it edits. That pause gives you a chance to correct scope, reject a risky path, add missing context, or shrink the task while the cost is still nearly zero.

What a Useful AI Plan Contains

The plan does not need to be long. In fact, long plans can become another way to hide uncertainty. A useful plan is short, concrete, and easy to challenge.

This structure turns a vague request into a reviewable contract. If the model cannot produce a specific validation step, it probably does not understand the change yet. If it cannot name a non-goal, it may edit too broadly. If the rollback story is hand-wavy, you should reduce the change size before any code is written.

A Prompt You Can Reuse

Use this before implementation, especially in unfamiliar code or anything that touches users, data, auth, billing, deployment, or shared state.

The last sentence matters. Good planning is not forcing AI to pretend it knows everything. Good planning gives it permission to stop and request the missing file, error message, test output, database schema, product rule, or deployment constraint.

What to Look For Before You Approve

1. Does the Plan Name One Outcome?

"Improve the login flow" is not one outcome. "Show the password reset error without clearing the email field" is. If the plan describes a general improvement, ask the model to restate the smallest behavior that will change.

2. Does It Separate Refactor From Behavior?

AI often combines cleanup with functional work because both feel useful. That is where review gets muddy. If the plan includes both, split them. First change the behavior, then refactor after the focused check passes.

3. Does It Mention a Concrete Check?

"Run tests" is weaker than "run npm test -- auth-reset" or "manually submit the reset form with an unknown email and confirm the message persists." Specific checks reveal whether the model understands the system boundary.

4. Does It Respect the Codebase?

A plan that invents new libraries, new abstractions, or new folders without explaining why is a warning sign. The assistant should first adapt to the existing system. New structure needs a reason stronger than "cleaner."

5. Does It Admit Risk?

A plan with no risks is usually not safer. It is less honest. Even small changes can affect cache behavior, empty states, permissions, accessibility, or old callers. You want the model to surface the likely weak spots before it touches the code.

The Plan Is a Review Artifact

The plan should stay visible during implementation. It becomes the diff's promise: this is what we intended, this is what we refused to change, this is how we will know whether it worked.

After the model edits, compare the diff to the plan. Did it touch the expected files? Did it add behavior outside the stated scope? Did it skip the validation anchor? Did it introduce a new abstraction that was not part of the approved path?

When Planning Can Be Tiny

Not every AI task needs a ceremony. If you are renaming a typo in one string, adding a missing import, or formatting a small block, a one-line plan is enough. The point is proportionality: the plan should be smaller than the risk it removes.

Use a full plan when the task crosses boundaries, changes behavior, touches production data, involves security, lacks tests, or requires product interpretation. Use a tiny plan when the task is local, mechanical, and easy to verify by inspection.

A Worked Example

The Risky Prompt

"Fix the settings page so users can change their email."

That sounds simple, but it may involve form state, validation, API contracts, auth sessions, email verification, conflict handling, audit logging, and UI copy. Letting AI jump straight to code invites accidental scope expansion.

The Plan-First Version

"Before changing code, plan the smallest safe change for allowing users to update their email from the settings page. Include intent, likely files, non-goals, risks, validation, and rollback. Do not edit yet."

What a Good Plan Might Say

• Intent: allow a signed-in user to submit a new email and see a confirmation state.
• Likely files: settings form component, account API client, one account route test.
• Non-goals: do not change password reset, session refresh, or email verification rules.
• Risks: duplicate emails, stale session display, validation mismatch between client and server.
• Validation: run the account route test and manually submit valid, invalid, and duplicate emails.
• Rollback: revert the form and API client changes; no migration or data rewrite involved.

Now you have something worth reviewing before code exists. You might decide that email verification is actually required before the feature ships. You might notice that duplicate email behavior belongs on the server first. You might split the work into API validation, then UI. All of those corrections are cheaper before implementation.

Planning Makes AI More Useful

Some developers avoid AI planning because they expect it to slow the loop down. In practice, it usually does the opposite. A short plan reduces rework, narrows the diff, improves prompts, and gives the reviewer a clear standard.

It also changes the human role from passive approver to active editor of intent. You are no longer waiting to see what the model did. You are deciding what kind of change is allowed to exist.