2.2 Plan Mode: Thinking Before Doing

Lesson 1.4 introduced plan mode as a safety habit. This lesson is about using it as a speed habit too, which is the part people underestimate.

Here's the failure mode plan mode prevents: you describe a feature, Codex picks a reasonable-sounding but wrong approach — maybe it adds a new dependency when you already have one that does the same thing, maybe it restructures a file more aggressively than the task actually called for — and you don't catch it until you're three files deep into a diff that's now annoying to partially unwind. Fixing a wrong plan costs one message. Fixing a wrong implementation costs a much longer conversation and a chunk of trust in the next thing it builds.

The habit that actually works: for anything that touches more than one or two files, or anything you don't already have a clear mental picture of the solution for, start with /plan instead of jumping straight to execution. Read the plan the way you'd read a colleague's proposal in a Slack thread before they start building — is the approach sound, does it account for the edge case you're already worried about, is it touching anything it has no business touching. Push back in plain language if something's off; you're not stuck accepting the first draft. Once it looks right, approve it and let Codex execute against a plan you've already vetted, which tends to go a lot straighter than execution against an unvetted first instinct.

Plan mode isn't free — it's an extra round trip before any code gets written, and for genuinely small, obvious changes that overhead isn't worth it. "Fix this typo in the error message" doesn't need a plan. "Migrate this module to the new auth pattern" does. The judgment call is the actual skill: reach for plan mode based on how much you'd regret finding out the approach was wrong after the fact, not based on a fixed rule about task size.