Flight Planning: file the plan before you take off

Here's the failure mode nobody warns you about. You hand an agent a PRD — the product requirements doc that says what to build — and you let it fly. Three hours later you have a confidently-built feature pointed at the wrong city.

At human speed, a wrong heading costs an afternoon. At agent speed it costs a whole session, and you don't find out until you read the diff.

Flight Planning is the fix. Before you build, you stop and file a plan — what you're building, how, and when you'll land — and you put it in front of other people. A pilot doesn't take off without filing one. Neither should you.

A vague plan, at agent speed, is the expensive kind

The cheapest place to catch a wrong heading is on the ground. Not at 30,000 feet, mid-session, with the fuel already burning.

That used to be a nice-to-have. When a person wrote the code, a half-formed plan self-corrected as they typed — they noticed the gap on line 40 and fixed it. An agent doesn't hesitate. Hand it an autonomous session — a build it runs end-to-end without you in the loop — and it executes the ambiguity at full speed, making every unstated decision at once, confidently, in one large diff.

So the economics flipped. The plan is no longer paperwork you produce after you know what you're doing. It's the thing that decides whether the session is worth running at all.

From crew on a boat to pilot of your own PRD

The shift underneath this is bigger than a meeting. It's a change in what you are.

The old model was a crew on a single boat. One sprint, one shared backlog, you pull a rope on a vessel someone else is steering, and your work only makes sense as part of the whole crew's effort. The new model gives you your own aircraft. One PRD, one owner, your flight path to fly. That's why a PRD should be scoped to one person and roughly a week of work — a pilot flies their own plane, they don't share a tiller.

And the moment everyone has their own aircraft, you need air traffic control. A crew on one boat coordinates by being in the same hull. A fleet of solo pilots coordinates by filing flight plans — this is where I'm going, this is what I'll build, these are the milestones, and this is when I'll land. Then everyone knows who's flying what and when they're due down. If a plane doesn't land on time, someone goes looking, instead of discovering the wreck a fortnight later.

Two things matter when you file. Be realistic — don't try to be a hero. About a week of work is a healthy range, the same fixed-appetite instinct that makes Shape Up work. And if the PRD is bigger than that, the plan isn't the first job — splitting the PRD is.

What a filed plan contains

A flight plan has five parts. Four are the work. The fifth is optional, and underrated.

• The line — the explicit scope boundary. This is what I'm going to build, and this is what I'm not. Drawing the line is the act that turns a wish into a route.
• The briefs — the Prompt Briefs, one per atomic unit of work, each carrying testable acceptance criteria. A single PRD often files as 6 or 7 of them.
• The journey — milestones, a believed landing point, and an ETA. Not a hard deadline. A filed expectation, so deviation is visible.
• The shape — how the briefs are wired to each other. Which ones are independent and could run at the same time, which are joined by an edge and have to go in order, where they come back together, and which results get a second pair of eyes before they count.
• The red line (optional) — something tangible to react to. A couple of screens mocked up, even thrown together in an hour, just to bounce off. It's the red line drawn on a map between two cities. You'll bin it, but it translates the idea faster than a paragraph ever will.

Filed, it's a one-screen summary anyone can read in a minute:

Flight plan — project landing page
  The line     in: routing, tabs, feed cards · out: mobile, video reports
  The briefs   PB-1 redirect · PB-2 sticky tabs · PB-3 feed cards  (each: goal, scope, AC)
  The journey  3 briefs · lands ~Thursday
  The shape    PB-2 + PB-3 independent · PB-1 → PB-2 (route table) · merge at the PR
  Red line     2 mocked screens (optional)

The journey says when. The shape says how the work is wired, and it's the part I added last because I'd been filing a queue and calling it a route. A pilot files a route.

It costs almost nothing to add, which is the part I like. Every brief already carries a pre-flight table listing the files it will touch, and that table is a declaration of the brief's surface — everything it mutates or contends for. The arrows are derivable from something the plan already produces. It just stopped short of drawing them. Watch for the surfaces a file list doesn't show, though: two briefs whose pre-flight tables don't overlap can still both hammer one staging database, and that's the edge that bites, because nothing declares it.

And if I can't find two briefs with no edge between them, there's no shape to draw. I say so and file four parts. Spreading work wide buys breadth. It doesn't buy judgment. (The longer version of why work has a shape at all: the shape of the work is a graph.)

One caution: the flight plan doc is a throwaway. Your PRD and its briefs stay the single source of truth. After the review, fold the decisions back into them and bin the plan. A second place that claims to be the truth is just confusion waiting to happen.

Who's in the room

This is the part the agent era quietly erodes, so I'll say it plainly: file the plan in front of people.

Working alone with a capable agent is fast and frictionless, and it's easy to never put your plan in front of another human. That's a trap. The agent is a calculator — rational, quick, and not remotely contextual. It will not think like your UX lead or your head of sales. That's the human's job, and the flight plan review is where it happens.

Stuart Leo

The agent sorts out the code. The humans bring the questions. That's the division of labour worth protecting.

Keep the room small but cross-disciplinary. The pilot, someone from software, a UX voice — and, when the work touches them, sales, finance, or whoever owns the end result. A scope problem caught by UX, or a commercial problem caught by sales, is trivial to fix in the plan and expensive to fix after the build. The review isn't a judgment. It's a bounce — several disciplines stressing the route while it's still cheap to change it.

Here's the honest cost: this asks you to stop and gather people before you've written a line, which feels slower in the moment. It is slower in the moment. It is much faster across the whole build, because the rework you didn't do never shows up on the bill.

The skill, and where it stops

I built a skill to prepare the plan — flight-plan. A skill is a packaged capability the agent runs on demand, a documented job with a fixed protocol. You invoke it in plain words: run flight-plan on this PRD. It reads the PRD, proposes the scope line, interrogates the spec for what's over- and under-specified, drafts the briefs, plots the journey, and draws the shape.

Then it stops. The skill files the plan and goes no further — it never builds, never takes off. Drawing a graph is not permission to fly it. Takeoff is a separate, human-gated step, which is the entire point of filing first.

A second agent works the other end. Where flight-plan builds the plan, a review-only verification agent stress-tests it — checking the acceptance criteria are actually testable and surfacing what the review still needs to decide. One proposes, the other challenges. It's the same pilot-directing-the-agents discipline C² runs everywhere, pointed at the plan instead of the code.

And close it when you land

A filed plan has a second end, and I missed it for months.

In aviation, filing isn't the whole ceremony. You close the plan on arrival. Land without closing it and air traffic control starts a search, because an open plan means an aircraft unaccounted for. I'd been using the metaphor for a year and only ever using half of it.

The cost showed up exactly where you'd expect. The gotcha that never got written down. The PRD still marked in-progress six weeks after it shipped. The estimate I never once checked against the actual.

Closing the Flight Plan is the gate at the other end. Four parts, one screen:

• The landing — what actually got built, against the line I drew.
• The deviation — where the route changed and why. Zero judgment. The plan exists to make drift visible, not to punish it.
• The anchor — the evidence that decides done. Tests that ran. The query that returned rows. The deploy that resolved. Not the agent says it's done.
• The learning — what the contextbase gains. The gotcha, the pattern, the honest completion rationale, estimated against actual.

It isn't a demo and it isn't a retro. It's a gate, and somebody in it has to have the authority to say not yet. With a team that's two people — whoever owns the intent and whoever owns the implementation. On my own it's me, reading the diff and asking whether the agent did what I actually wanted. Same ceremony, different weight. And if you build alone, you're the reader who most needs this one and most easily skips it.

Here's why it matters more than it sounds. Filing is where context gets spent. Closing is where context gets made. Every artefact that makes the next session cheaper — the gotcha, the pattern, the decision record — gets written at the exact moment I feel finished and least want to write anything. A ceremony is what survives that moment. Good intentions aren't.

There's more to it than fits here — the three gates and why they sit at different altitudes, how the findings need structure to survive the room, and why the next plan does the tidying. The full ceremony is here.

File the plan before you fly

Deviation in the air is fine — plans change, and you're the pilot. What's not fine is a wrong heading nobody can see.

So you file a flight plan before takeoff — the line, the briefs, the journey, the shape — reviewed out loud by the people who'll feel the result. Then you close it when you land. Do that, and the wrong heading gets caught on the ground rather than at 30,000 feet with the session already burning. And the flight you did fly leaves something behind for the next one.

Start here: read the method, run your first session, or browse the docs.