Planning
/planPlan on paper, fail on paper.
Before the concrete sets
A plan makes the hidden choices visible
You do not need to be technical to recognise a vague request: "add online booking," "automate the weekly report" or "make the website easier." Each sentence hides decisions about people, scope, data, risk and what success means. An AI agent may fill those gaps from the patterns in its context and produce something quickly. It may also choose a plausible interpretation that is not yours.
A useful plan is a blueprint before the concrete is poured. It names the intended outcome, visible assumptions, steps, affected systems and evidence for completion. The plan is often the cheapest place to discover a misunderstanding, while changing a sentence is still easier than undoing working code and migrated data.
The cheaper correction point
Move disagreement onto the blueprint
The cost of a mistake usually grows as more work depends on it. Correcting the target user in a plan may take a minute. Discovering the same error after data structures, screens and integrations have been built can require redesign, retesting and communication with affected people. The exact cost is not always a day, and some exploratory tasks are best learned by trying a small prototype. The principle is to surface expensive assumptions early.
This is one practical use of harness engineering. The workflow requires the agent to expose its interpretation before receiving authority to build. A person can challenge the assumptions, narrow the scope and decide which evidence will count. Planning does not make the model correct; it creates a review point before the consequences become harder to reverse.
Plan depth follows the cost of being wrong
A plan earns detail when uncertainty, consequence and dependency make correction expensive.
Lighter plan
- Reversible change Easy to undo without user or data consequence.
- Known pattern The team understands the implementation and checks.
- Few dependencies One owner can complete and verify the work.
calibrate the artifact
Deeper plan
- High consequence Identity, money, permissions, safety or customer rights.
- Unresolved choices Product or policy decisions remain hidden.
- Many seams Several systems or owners depend on the outcome.
The smallest adequate plan makes outcomes, assumptions, steps and proof visible.
A complete worked example
Turn “add booking” into choices you can inspect
Imagine a tutoring business asks: "Add online booking." A weak plan says "build a booking page." A reviewable plan starts with the outcome: a parent can book one 30-minute introductory call in an available slot and receive a confirmation. Payments, recurring lessons and rescheduling are out of scope for this first version.
Next it exposes assumptions: the existing calendar is the source of availability; times display in the visitor's timezone; only name, email and chosen slot are collected; and the business owner will supply cancellation wording. If that last item is unknown, the plan marks it as a question rather than inventing a policy. Brainstorming can surface alternatives before the plan records the chosen one.
The steps then become legible: inspect the current site and calendar connection, sketch the booking journey, reserve the slot atomically so two submissions cannot take it, create the calendar event, send confirmation and record failures for follow-up. A booking request ID is reused on retry so the same submission creates only one result. Evidence is planned too: concurrent and repeated submissions create one event and one confirmation; a past or already-taken slot is rejected; times are correct in two visitor timezones, including a daylight-saving boundary; and a labelled test booking succeeds through the deployed page and appears in the real calendar. With those choices approved, execution has a boundary to follow.
A plan turns ambiguity into inspectable commitments
Each planning field resolves a different kind of uncertainty before code makes it harder to contest.
- Outcome What changes for the user or operation?
- Assumptions Which beliefs must be checked or owned?
- Steps and dependencies What order matters and which interfaces must hold?
- Evidence What observation will support each completion claim?
- Authority and stopping Who decides at consequential boundaries and when should work pause?
A good plan reduces hidden choice while leaving implementation room where choice is harmless.
Know when the blueprint bends
Planning buys a cheaper question, not certainty
A plan can still encode the wrong goal, miss a stakeholder or become stale when implementation reveals new evidence. Small reversible changes may need only a few lines, while legal, financial or data-moving work deserves deeper review. The plan should scale with consequence, and execution should pause when reality breaks a load-bearing assumption.
My student instinct uses the blueprint to expose what I do not yet know. My professional instinct uses it to make ownership and evidence reviewable. Ask four questions before the pour: What outcome are we creating? Which assumptions could change the design? What evidence would show it works? What discovery would make us stop and replan? A plan does not eliminate wrong turns. It lets more of them happen while the eraser still works.