Plan Like You Mean It

The slot machine

Most people drive AI like a slot machine. They type a vague wish, pull the lever, and hope. The output comes back wrong, so they reword the wish and pull again. Then again. Three hours later there are forty messages in the thread, a tangle of half right code, and no clear memory of which version was the good one. That is not building. That is gambling with extra steps.

The reflex is to blame the prompt. Write a cleverer prompt, get a cleverer result. It is the wrong lesson. The problem was never the sentence. It was the absence of a plan.

Here is the thing nobody says out loud. AI accelerates, it does not generate. Point it at a clear target and it will close the distance frighteningly fast. Point it at a vague one and it will accelerate in a random direction, which is just a quicker way to get lost.

The fix for a bad output is almost never a better prompt. It is a better definition of done.

Stop prompting, start defining outcomes

A prompt describes a wish. An outcome describes a result you could check. The gap between those two things is the entire game.

When I start something now, I do not open a chat and start typing instructions. I open a conversation whose only job is to decide what we are actually building. What does done look like. What must be true. What is explicitly out of scope. None of that is code. All of it is the part that makes the code come out right.

This is slower for about twenty minutes and faster for the rest of the project. You trade a vague head start for a clear finish line.

The chain

The method is a short chain, and each link feeds the next.

1. Brainstorm before you build. Run a real interrogation of the idea first. Not "what should I build", but "what are we actually trying to make true, and what would break it". I use /brainstorm for this, one question at a time, until the fog clears. The output is a shared understanding, not a to do list.

2. Freeze it in a spec. A spec is the brainstorm, written down and made hard to argue with. Objective in one falsifiable sentence. Constraints that bound the solution. A definition of done where every item can be checked with a single action. If you cannot write that sentence, you are not ready to build, and now you know it cheaply.

3. Break the spec into a phased plan. A plan turns the spec into ordered, bite sized phases. The discipline that matters most here is sizing. Each phase has to be small enough to carry start to finish in one sitting, with room to spare.

4. Hand each phase over as a typed brief. This is the part that does the heavy lifting, so it gets its own section.

The typed brief is where the magic is

A typed brief is a product requirements document, scaled down to whatever you are making. It is the difference between "build me a settings page" and a short document that states the goal, the constraints, the acceptance criteria, and the phases.

It feels like bureaucracy. It is the opposite. The brief is a forcing function. You cannot write acceptance criteria for a feature you do not understand. You cannot list constraints you have not thought about. The act of filling in the fields drags every fuzzy assumption into the light while it is still free to fix.

Play with the toggles below. Watch the output sharpen as each field of the brief gets filled in. The model did not get smarter between the first state and the last. The brief did.

That climb is the whole argument in one widget. Vague in, generic out. Specific in, on spec out. The leverage was never in the prompt. It was in the definition.

One phase, one session

The other half of the method is sizing. A plan is only good if each phase actually fits.

Fits what? A single session. A model holds a working memory, a context window, and it is finite. Cram an entire project into one session and quality falls off a cliff long before you hit the wall. The model starts dropping detail, contradicting earlier decisions, losing the plot. You can feel it happen.

Slice the same project into phases that each fit comfortably inside one session, and every phase ships clean. The work is identical. The packaging is everything.

Drag the load into the gauge below and watch what happens.

This is why the plan and the brief are partners. The plan decides where the cuts go. The brief makes each slice executable on its own. Together they let you build something large without ever asking one session to hold all of it.

Why this works, the part nobody tells you

The obvious payoff is that the output is drastically better, and it is. But the real prize is quieter.

Writing the brief makes you understand your own design. By the time I have written a spec and sliced it into briefed phases, I have already found the contradictions, the missing decisions, the bit I was hand waving. I found them at the desk, in plain English, where they cost minutes. Not three hours into a build, where they cost the build.

So the plan is not the thing you do before the work. The plan is the work. The building is just the part that is easy to delegate once the thinking is done.

The boring habit

None of this is clever. It is a brainstorm, a spec, a plan, and a brief. It is the boring habit underneath everything that ships.

Stop prompting. Start defining outcomes. Then watch how little re prompting you have to do. //