How to plan and scope a build with an LLM

This is a five-step method for scoping a build with an LLM - measurable goals, risk-first order, and task size capped by what you can review in one sitting - plus one checkpoint that catches the sunk cost fallacy before it burns a session on a plan that should already be scrapped.

Here’s why that checkpoint matters. In 1985, researchers Hal Arkes and Catherine Blumer offered people a choice between two ski trips they’d already paid for, non-refundably: a “great” $50 weekend or a “good” $100 weekend. More than half picked the worse, costlier trip - because more money was sunk into it. That bias is why so many AI-assisted builds limp along past the point where the smart move is to scrap the plan.

LLM-assisted planning fails in two distinct ways. First, a vague goal lets the model improvise past what you meant - it was always a problem, but implementation used to be slow enough to catch it early; now a model can build the wrong thing to completion before you’ve finished your coffee. Second, once a plan exists - written, discussed, partially built - abandoning it triggers the same loss-aversion pull, protecting what’s already invested over what’s actually best, that kept people on the worse ski trip, even when the plan is visibly wrong. The five steps below fix the first failure; the checkpoint at the end fixes the second.

Step 1: State the goal as a number, not an adjective

“Make the search faster” is an invitation for the model to improvise. “Cap p99 latency at 200ms and support 20,000 queries per second” is a target it can act on and you can verify. That’s the core move behind Edmond Lau’s engineering-scoping method for software teams, as summarized on freeCodeCamp: replace adjectives with numbers before anyone - human or model - starts building.

Write the anti-goals alongside the goal. “This does not need to support bulk export” saves you from reviewing a diff that quietly added it, or from an agent that decided bulk export was implied.

Step 2: Order by risk, not by ease

Do the part most likely to fail or change your mind about the plan first, and prototype it with throwaway data before committing the rest of the build to that direction. This is cheap insurance now in a way it never used to be: since a model can produce a rough version of the risky part in one turn, you can falsify a bad plan before you’ve spent five sessions building around it.

Step 3: Size tasks by what you can review, not by the calendar

The original heuristic here caps a task at two days of human dev time. Port that literally into an LLM workflow and you’ll wildly underuse the model - two days of human coding is minutes of generation. The unit that still matters isn’t time, it’s verification: one change small enough that you can read the whole diff, understand every line, and accept or reject it in a single sitting.

That’s the same discipline a verifiable completion condition demands of any autonomous loop - a measurable end state you can check, not a mood like “looks done.” Give every unit of work its own check before you prompt for it: a test that passes, a build that succeeds, an output you can inspect. If you can’t state the check, the unit is still too big or too vague to hand to a model.

Step 4: Estimate as a range, then re-scope on real data

Estimate each unit as a probability spread instead of a single number - “likely done in one turn, 90% chance within three” carries more information than “one session” and is honest about the tail risk. Track estimate against actual for every unit as you go; that record is what makes your next estimate better, and it’s also the evidence you need at the next step.

Two people, or two parallel agent runs pointed at the same task, doesn’t halve the time it takes on its own - the gain depends on who or what absorbs the coordination cost. Point agents at overlapping work and reconcile the diffs by hand, and coordination overhead eats the gain the same way it does on a human team. Automate that reconciliation instead - a critic agent checking the generator’s output, an orchestrator that merges only verified subtasks - and the arithmetic improves, but the constraint doesn’t disappear, it just moves: something still has to verify the output, it’s just code doing the checking instead of a person. Parallelizing more of the work is not a substitute for cutting the work down to a size that something, human or automated, can actually verify.

Step 5: Put a sunk cost checkpoint on the calendar - not just an estimate check

At every re-scope point, ask the fresh-start question: if I were starting right now, knowing nothing about what’s already been built, would I still choose this plan? Ask it that way and the ski-trip bias has nothing left to grab onto. A related experiment, from research on loss aversion by Daniel Kahneman and Amos Tversky, shows the same mechanism at work: subjects who lost a $10 bill before buying a movie ticket still bought it 88% of the time, but subjects who lost the ticket itself refused to replace it 54% of the time - identical financial loss, wildly different willingness to continue, because one felt like an investment already made toward the movie. Don’t let a half-built plan get the “replace the ticket” treatment when the honest move is to walk away.

At every checkpoint, dropping the project has to be a choice you’re actually willing to make - not a box you check on the way to continuing anyway.

Where each failure mode comes from

This is the planning half of the loop covered in the vibe-coding field manual - once the plan is scoped, that piece covers the per-feature session loop, the diff review checklist, and recovery commands for when a session goes wrong anyway. Implementation is the fast part of the lifecycle now; verification stays slow and human-paced. Skip the scoping discipline above and vibe coding inherits agentic engineering’s costs without its guardrails.

The copy-paste planning prompt

Paste this into any LLM chat or agent session before writing a line of code. Fill in the bracketed context; the numbered steps are the method above, compressed into instructions the model can execute with you.

I want to plan [PROJECT/FEATURE] before writing any code. Act as a technical
lead scoping this work with me, not as a coder. Work through these steps in
order and don't skip ahead to implementation:

1. Ask me for the single measurable outcome (a number, or a pass/fail check)
   - not an adjective. Push back if I give you one.
2. List explicit anti-goals: what this plan will NOT do.
3. Break the work into units, each one a single reviewable change I could
   fully read and accept in one sitting. Order them by risk - the part most
   likely to fail or change the plan goes first.
4. For each unit, give a probability-range estimate ("likely 1 turn, 90%
   chance within 3") instead of a single number, and a concrete check that
   proves the unit is done (a test, a build, an inspectable output).
5. Set one re-scope checkpoint, right after the riskiest unit ships: compare
   estimate against actual, and tell me honestly whether the plan should
   continue as-is, change, or be dropped.
6. At that checkpoint, ask me the fresh-start question directly: "if you were
   starting right now, knowing nothing about what's already built, would you
   still choose this plan?" If my answer hedges on how much we've already
   invested rather than what's best from here, call that out by name.

Context: [describe the project or feature, the current codebase or starting
point, and any hard constraints]

Run it once at the start of a build, and again at every checkpoint Step 5 sets up. The second run is the one that actually catches sunk cost - the first only sets the trap that would otherwise spring later.