Plan-First AI Coding Workflow: Reviewing Before an Agent Changes State

The default failure mode of AI-assisted coding isn't bad code — it's fast, plausible code built on an assumption nobody checked. An agent asked to “add rate limiting to the login endpoint” will confidently pick a rate-limit window, a storage backend, and an error response shape, all reasonable-looking choices that might contradict an existing pattern used everywhere else in the codebase. Nobody lied; nobody checked first.

A plan-first workflow interrupts that pattern structurally. The agent reads the codebase and interrogates the change against the accepted specification before touching a single file, and that plan — files that change, order of work, named risks, and what proves it worked — becomes a reviewable artifact in its own right, separate from the code it will eventually produce.

The review question isn't “does this plan look reasonable” — that bar is too low to catch anything specific. It's sharper than that: which existing customer journeys can this change break, which step carries the highest auth, tenant, data, or migration risk, what's unexpectedly coupled to this change that isn't obvious from the ticket, and what evidence will prove real customer-visible behavior rather than just a passing API response. A plan that survives those four questions is usually implemented correctly in a single pass, because the hard thinking happened before the typing did.

Plans are drafted before all the facts are visible, and a real constraint sometimes surfaces mid- implementation that the plan didn't anticipate — a migration that turns out to need a backfill step, a dependency that behaves differently than documented. When that happens, the plan gets updated with the reason and the changed risk in the same change set, rather than the implementation silently diverging from a stale document. Review then compares the diff to the final plan, not to an outdated first draft that nobody bothered to correct.

Running several AI coding sessions at once is genuinely useful once each targets an independent surface named in the plan's work-order list — but parallelism is bounded by how fast a reviewer can actually read the output, not by how many sessions can be opened. A good starting point is two to three concurrent sessions, adding another only while review is still keeping pace. Opening ten sessions and reviewing none of them carefully isn't parallelism — it's just deferred risk. For scoped code-review and quality-gate automation once changes land, see our guide to sub-agents for review and quality gates.

Plan-first is easiest to describe against a clean, well-tested codebase, which is exactly the codebase most engineering orgs don't have everywhere. Against a legacy module with thin test coverage and undocumented coupling, the plan itself needs an extra step: naming what'sunknown, not just what's risky. “This function is called from three places we can find by search, but the codebase has dynamic dispatch we can't fully trace” is a legitimate, useful line in a plan — it tells the reviewer exactly where confidence is thin, instead of presenting a false sense of completeness.

In practice this means legacy surfaces default to a lower autonomy tier than the table above would suggest for an equivalent change in well-tested code, specifically because the plan's own risk assessment is less trustworthy there. That's not a knock against AI-assisted development — a human engineer working the same legacy module would reasonably ask for the same extra caution.

A plan for “add webhook retries for failed payment notifications” names the files that change (the webhook dispatcher, its retry-queue table, and the dead-letter handler), states the highest risk explicitly (a retry storm if the backoff logic is wrong), and states the proof: a test that simulates five consecutive failures and confirms the backoff interval doubles each time, capped, with a dead-letter entry after the final attempt. A reviewer reading that plan for two minutes can approve it with confidence — not because the code is simple, but because the risk was named and the proof was specified before a single line was written.

Approving a plan that lists tasks instead of naming risk. “Update the API, update the client, add a test” is a to-do list, not a plan — it says nothing about what could go wrong. A plan that doesn't name its highest-risk step hasn't actually been thought through, it's just been described.

Auto-accepting because the diff looked small. Line count is a poor proxy for blast radius — a two-line change to a shared auth middleware carries more risk than a three-hundred-line addition of a new, isolated component. The autonomy decision should follow the surface being touched, not the size of the patch.

Leaving the plan stale after a mid-implementation pivot. When a real constraint forces a change of approach partway through, it's tempting to just finish the code and skip updating the plan since “it's basically done anyway.” That's exactly when the plan stops being a trustworthy record of what was reviewed — the update takes two minutes and preserves the entire point of having a plan in the first place.

A plan is only as trustworthy as the specification it's built from — see the Design stage for how policy conflicts get resolved before this point. And a plan's stated proof is only meaningful once it's backed by a real, continuously-run eval suite rather than a one-time manual check — covered next in the Test stage.