Plan like you mean it · Clief Notes

Plan like you mean it

Most people drive AI like a slot machine. Type a vague wish, pull the lever, hope. Wrong output, pull again. Three hours later: forty messages, half right code, no idea which version was good.

That is not building. That is gambling with extra steps.

The fix is not a cleverer prompt. It is a plan. Here is the exact habit, start to finish.

The one idea

Stop prompting. Start defining outcomes.

A prompt is a wish. An outcome is a result you can check. AI accelerates, it does not generate. Point it at a clear target and it closes the gap fast. Point it at a vague one and it just gets lost faster.

————————————————————————

The chain (this is the whole method)

1. Brainstorm first.

Do not open a chat and start barking instructions. Open a conversation whose only job is to decide what you are building. What does done look like. What must be true. What is out of scope. I use `/brainstorm` and answer one question at a time until the fog clears.

2. Freeze it in a spec.

A spec is the brainstorm written down and made hard to argue with.

Three parts:

- Objective, in one sentence you could prove true or false.

- Constraints, the rules that bound the solution.

- Definition of done, where every item can be checked with a single action.

If you cannot write the objective sentence, you are not ready to build. Better to learn that now, for free.

3. Break it into a phased plan.

Turn the spec into ordered, bite sized phases. The rule that matters most: each phase must be small enough 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. Read the next section.

————————————————————————

Think in PRDs

A typed brief is a product requirements document, scaled to whatever you are making. It is the difference between "build me a settings page" and a short doc with a goal, constraints, acceptance criteria, and 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.

Filling in the fields drags every fuzzy assumption into the light while it is still cheap to fix. The model does not get smarter when you hand it a brief. The brief was smarter than the prompt.

————————————————————————

One phase, one session

A plan is only good if each phase actually fits inside one session.

A model has a finite working memory. Cram a whole project into one session and quality falls off a cliff: dropped detail, contradicted decisions, lost plot. Slice the same project into phases that each fit comfortably in one session, and every phase ships clean.

Same work. Different packaging. The packaging is everything.

————————————————————————

Why it really works

The obvious win is that the output is drastically better. The quiet win is bigger: writing the brief makes you understand your own design.

By the time you have a spec and briefed phases, you have already found the contradictions and the missing decisions. You found them at the desk, in plain English, where they cost minutes. Not three hours into a build, where they cost the build.

The plan is not the thing you do before the work. The plan is the work.

————————————————————————

Try it this week

Pick one thing you would normally one shot. Before you touch it:

1. Brainstorm it until you can say what done looks like in one sentence.

2. Write a five line spec: objective, three constraints, a definition of done.

3. Cut it into phases that each fit one session.

4. Brief the first phase like a PRD, then build only that.

Notice how little re prompting you have to do.

Full deep dive at: https://www.aris-space.com/documents/discipline-and-process/plan-like-you-mean-it

//A<3

19 comments