Planning
/executeA plan you don't check is just a wish.
The plan is the easy half
A decision on paper is inert
A plan records intended decisions before implementation makes them expensive. It does not control the work by itself. An agent can interpret one step differently, produce something plausible and use that result as the foundation for every step that follows. The final output may look complete while no longer matching the plan.
The practical discipline is incremental execution: complete a meaningful unit, inspect evidence at its boundary, then decide whether the next unit may begin. The checkpoint is not ceremony. It is where the plan meets observable reality.
Drift compounds in the dark
The agent doesn't fall off a cliff, it veers two degrees
Drift is usually small at first. A database field is made optional although the plan required it. A service returns a convenient shape instead of the agreed interface. A policy check is placed in the screen rather than the server. Later work adapts to that choice, and a local misunderstanding becomes a dependency.
The correction cost can therefore grow with each dependent step. The chart below is conceptual, not a measured curve. It shows why early evidence has leverage: correcting one interface before its consumers exist is usually simpler than changing the interface, consumers, tests and documentation together.
Unchecked assumptions cross dependency boundaries
Drift does not follow a fixed curve, but an early misunderstanding can become more expensive after later steps depend on it.
- Complete a meaningful unit Small enough to inspect, large enough to prove something.
- Check the dependency boundary Confirm the output, assumptions and evidence needed next.
- Correct or record uncertainty Do not silently carry an unresolved mismatch.
- Begin the dependent unit Proceed only with an earned input.
- Recheck the integrated path Local correctness can still fail in combination.
A plan becomes execution when evidence controls what may start next.
Execute in checkable increments
Do this step, then show me
A useful checkpoint sits where later work depends on a result. Common seams include a data migration, an interface between components, a permission rule, a deployable slice or a decision that narrows later choices. Tightly coupled edits may belong in one batch. Stopping after every line would create noise, while running through several dependency boundaries would hide drift.
At the seam, compare expected and observed evidence. Did the migration produce the intended schema? Does the interface match its contract? Do the relevant tests fail before the change and pass after it? Can a reviewer see what changed and why? A checkpoint only helps when its proof matches the claim.
The best checkpoints sit at seams
A seam is where one artifact, assumption or owner becomes input to another.
- Specification to implementation Does the mini-spec define observable behaviour?
- Component to integration Does the interface still mean the same thing?
- Implementation to release Do permissions, data and failure behaviour hold live?
- Release to ownership Who watches, responds and decides whether to roll back?
Check where errors propagate, not merely where a checklist happens to have space.
The value lives in the seams
A dependency seam is often your cheapest chance to verify
Suppose the plan adds team invitations in four stages: schema, invitation service, email, then user interface. After the schema stage, inspect the migration, its constraints and preserved user data. After the service stage, run cases for valid, expired and repeated invitations, plus an unauthorised inviter and a token presented to the wrong team. If the service accepts an expired token, stop there. Fix the rule and rerun the evidence before email or interface code begins.
Once the service gate passes, continue through the email and interface seams with their own evidence. Finally, exercise the whole path: an authorised owner invites a member, the recipient follows the issued link, joins the right team once and cannot reuse or redirect the token. Seam checks contain drift; they do not replace final integration proof.
That sequence is harness engineering applied to execution. The plan defines the intended order. The seam defines when evidence is collected. The gate defines what must be true before the work continues. It pairs with a readable plan and with matching each claim to relevant proof.
A plan you blow straight through is just a wish with bullet points.
Finished and correct are different words
The work is in the stopping
Incremental execution does not guarantee correctness. The plan may be wrong, the test may encode the wrong requirement and a tightly coupled change may need a larger batch. The method gives you a learning loop: each checkpoint updates your understanding before more work depends on it.
The professional benefit is smaller, more reviewable corrections and a clearer record of why the work advanced. The human benefit is containment. A mistaken step is less likely to expand invisibly into the rest of the day. Choose seams by dependency and risk, demand evidence that fits the claim, and let the next step begin only when the current one has earned it.