Module 7 · Systems

Plan Before You Build

An agent is fast, literal, and non-deterministic: a combination that will happily build the wrong thing beautifully. A short plan first is the cheapest insurance you can buy.

7 min read

Lesson 7.1

Speed magnifies a wrong assumption

Back in Module 1 we saw two things about agents: they act on their own reading of your intent, and they're non-deterministic. Put those together with raw speed and you get a specific failure mode: the agent takes one plausible interpretation of a vague request and builds it all the way out before you can say "wait, not like that."

The problem isn't that it's wrong more often than a person. It's that it's wrong faster and more completely. A human developer pauses when a task feels ambiguous. An agent, by default, resolves the ambiguity silently: picks a lane, and floors it.

Why Plans Matter

Make the agent state its plan before it touches code. A plan is written in prose, the cheapest medium there is to change. Catching a wrong assumption in a three-line plan costs a sentence. Catching it after the code is written costs you time and tokens to rerun the agent interaction.

Lesson 7.2

Same request, two approaches

One deliberately under-specified request, the kind you actually type when you're busy. Watch how it plays out when the agent charges straight in, versus when it plans first and lets you steer. Press the button.

User “Add a way to export the reports page to CSV.”
Straight to building
  1. Request arrives. Ambiguous, but the agent picks an interpretation and starts immediately.
  2. Assumes silently. Decides it means all reports, exported client-side, with every column included.
  3. Writes the code. New button, a client-side CSV builder, wired across four files.
  4. Wrong target. You wanted only the filtered rows, and the dataset is too big to build in the browser. Most of it gets thrown away.
Fast to a result, slow to the right result. The assumptions surfaced only after the work was done, so the fix is a rebuild.
Plan first, then build
  1. Request arrives. Same vague ask, but the agent holds off on code.
  2. Proposes a plan. "I'll export the currently filtered rows, server-side, selected columns only. Sound right?" The assumptions are now visible.
  3. You steer, cheaply. "Filtered rows: yes. Let the user pick columns." One sentence redirects the whole approach.
  4. Builds it once. Now aligned, it writes the export the way you actually meant, no discarded work.
A beat slower to start, far faster to done. The disagreement happened in prose, where it cost a sentence instead of a rewrite.

The plan didn't make the agent smarter. It made its assumptions visible while they were still cheap to change, and handed you the wheel at the one moment steering costs almost nothing.

Lesson 7.3

What a good plan actually buys you

A plan is not bureaucracy. For a non-deterministic, fast-moving agent it does three concrete jobs:

  • It moves the argument to the cheap medium. Every project has a moment where you and the agent disagree about what "done" means. A plan forces that moment to happen in text, before a single file changes, instead of after.
  • It exposes missing context. Writing the plan is where the agent reveals what it doesn't know: which file, which convention, which edge case. That's your cue to supply the fact (exactly the "right information at the right time" from Module 2) before it guesses.
  • It narrows the non-determinism. Once you've approved a specific approach, the range of paths the agent can take collapses to the ones you signed off on. You've turned an open-ended task into a bounded one.

Rule of thumb: the more expensive or irreversible the work, the more a plan pays off. A one-line typo fix needs no plan. A migration touching thirty files, a schema change, or anything that hits production absolutely does. Match the ceremony to the blast radius.

Lesson 7.4

Getting an agent to plan

You don't need a special tool for this; you need a habit. Three ways to invoke it, roughly in order of formality:

  1. Just ask. "Before you write any code, outline your approach and list your assumptions." One sentence flips the default from act to propose.
  2. Use plan mode if your agent has one. Many agents ship a dedicated planning mode that can't edit files: it can only read and propose. The guarantee is structural: it's incapable of building until you approve. (That's a hook-like guarantee, in the language of Module 6.)
  3. Then review, correct, and release. Read the plan the way you'd read a pull request description. Fix the wrong assumption, add the missing fact, and only then say "go."

For which task is planning-first most worth the extra step?

Pick one. You'll get instant feedback.

Takeaways

1. Agents build the wrong thing fast and completely: a plan catches the mistake while it's still just words.
2. A plan moves the disagreement to the cheap medium, exposes missing context, and narrows what the agent will do.
3. Ask for the plan, review it like a PR, correct it, then release, and scale the ceremony to the blast radius.

Finished Plan Before You Build?

Mark it done to track your progress across the course.