Part 1 · The Inner Loop

Agentic Workflows · ~7 min

Plan Before Code

The single highest-leverage move in agent-assisted development isn't a better prompt. It's refusing to let the agent write code until it has described the system back to you.

Why this, for you: the most expensive failure in agent coding is a wrong assumption that becomes 500 lines before anyone notices. This lesson is the loop that catches it at the cheapest possible point — a paragraph, not a revert. Pure daily-coding payoff, the foundation the whole course builds on.

"Here are the files. Build the feature." gives the agent no alignment checkpoint. The result compiles — and quietly strays from your architecture. The fix is structural: separate understanding from deciding from doing, and put a human checkpoint between each.

1 Summarize before touching

Ask the agent to read the relevant files and describe how the subsystem works — before proposing any change. This surfaces what it understood, wrong assumptions included, while they're still words on a screen.

# read-only first — no edits yet Read the auth module and summarize how session management works. Do not make any changes yet.

Then correct the summary. If the agent misidentified a component's responsibility or missed a dependency, fix it now. One correction here prevents multiple correction cycles after implementation — the difference between editing a sentence and reverting a diff.

2 Co-create the plan, then implement against it

With the understanding aligned, have the agent write a plan: which files change and why, what new state appears, how it fits existing patterns, and the success criteria. The plan is a mini design document — reviewing it answers "does the agent understand the task?" before implementation cost is incurred.

OpenAI's Sora Android team hit this exactly: implementation-first prompts produced code that was functional but architecturally inconsistent. Switching to plan-first gave them confidence in the direction — "the way a good design document gives a tech lead confidence in a project."

Now implementation is execution of a known approach, not exploratory guessing. Scope drift from the plan is a signal to stop and re-examine — and you compare the diff against the plan, not just against the original task.

For long tasks, the plan is a file

A multi-session task can't seed new agent instances from conversation history alone. The Sora team saved approved plans to version-controlled files; a fresh instance reads the plan at startup and continues without reconstructing the reasoning. The plan is both coordination artifact and lightweight decision record.

When plan-first is pure overhead

The checkpoint pays off when assumptions are uncertain — and costs you when they aren't. Skip it for trivial changes you could describe in one sentence (typo, version bump), for debugging sessions where the goal is discovery not a known change, and for tight test-fix-test loops where errors are cheap to reverse. Apply Plan Mode selectively on the step where scope uncertainty is high, not by reflex.

↪ Your win: a checkpoint before the expensive part

Retrieval practice — recall, don't peek

Question 1The first move in the plan-first loop is to have the agent…

Question 2Correcting the agent's summary early matters because one correction there prevents…

Question 3OpenAI's Sora team found implementation-first prompts produced code that was…

Question 4Saving the approved plan to a file mainly lets you…

Question 5Plan-first is pure overhead and best skipped when the task is…

Ask me anything. Want the --append-system-prompt snippet that enforces planning every session, or how to wire --permission-mode plan as a project default? Next in Part 1: Research, Plan, Implement — the three-phase shape and the reasoning sandwich that powers it.
✎ Feedback