Blog post
Planning Is Where AI Work Becomes Reviewable
Why planning is less about agent autonomy and more about making AI-assisted work inspectable before it becomes expensive.
Planning Is Where AI Work Becomes Reviewable
The most expensive moment in AI-assisted development is often not a bad line of code. It is the moment a plausible implementation makes an architectural decision before anyone has agreed that the decision is right.
A direct request—“implement this feature”—can produce a route, a data model, a migration, tests, and a set of UI changes in one pass. The result may even look coherent. But coherence after the fact is a poor substitute for agreement before the work spreads.
That is why I treat planning as an operating boundary. Planning is where the work becomes reviewable while changing direction is still cheap.
Start by classifying the work
Not every task deserves a meeting disguised as a document. A one-line copy change can execute directly. A change involving tenant scope, authorization, a migration, a new persistence boundary, or several agents needs a checkpoint first.
The useful question is not “can the agent do this without me?” It is “what would be expensive to discover after it has done it?”
That gives the workflow a simple risk rule:
- reversible and local work can proceed;
- cross-layer work needs an inspectable plan;
- work that changes trust, public state, or durable data needs an explicit human decision before execution.
This is not a demand for ceremony. It is a way to spend attention where the cost of being wrong rises faster than the cost of waiting.
A checkpoint should expose the decision surface
A planning checkpoint earns its place when another person can inspect it without reconstructing the whole conversation. I want it to answer:
- What outcome are we trying to produce?
- Which files, modules, or boundaries are likely to change?
- Which layer owns the behavior?
- What assumptions are being made about data, permissions, or product intent?
- What could go wrong, and how would we know?
- In what order will the work happen?
- What will be verified independently?
- Which questions still belong to a human?
The point is not exhaustive prediction. It is to make the proposed direction visible enough to reject.
If a plan puts business rules in a route, I can stop it. If it treats a client-selected tenant as authority, I can stop it. If it introduces a broad abstraction for a narrow feature, I can ask why before the abstraction acquires dependants.
The checkpoint changes review from “does this diff look reasonable?” to “did the implementation follow a direction we actually accepted?”
Delegation needs boundaries, not optimism
Delegating work to several agents does not reduce ambiguity. It distributes it. A vague task becomes several partial interpretations, each moving quickly and interacting with the others.
The operating model therefore has two distinct loops. The inner loop investigates, implements, and checks a bounded piece of work. The outer loop owns the goal, constraints, evidence, and decision to proceed. Agents can run inside the first loop without owning the second.
That boundary also makes automation more useful. An agent can prepare a plan, inspect a repository, run a test, or produce a patch. None of those capabilities, by themselves, authorize a migration, a publication, or a change to a trust boundary.
The more parallel the work becomes, the more important it is that each unit has a clear input, output, owner, and verification condition.
The plan survives the run
Planning is also a memory mechanism. The final code tells me what changed. The plan tells me what was intended. When the two diverge, the difference is evidence: perhaps the implementation found a constraint, perhaps the original assumption was wrong, or perhaps the agent drifted.
That record matters across sessions. Without it, a future agent sees the accumulated diff and infers a rationale from whatever code is nearby. With it, the project retains at least one explicit statement of the decision that shaped the diff.
This is a small form of intent preservation. It does not replace tests, architecture notes, or review. It gives them a reference point.
The limit
Planning does not make an agent wise. It does not make a weak product decision strong, and it cannot turn an unreviewed verification result into proof.
Its value is narrower and more practical: it moves judgment to the point where judgment still has leverage. The human cost remains choosing the goal, accepting the trade-off, and deciding whether the evidence is sufficient.
Planning is where AI work becomes reviewable—not because a document makes execution safe, but because an inspectable decision arrives before execution makes the decision expensive to change.
Continue exploring
Follow the same line of thought through themes, tags, or a broader local search across the archive.
Keep following the thread.
The Problem Is Not Prompting. It Is Context Decay.
Why AI-assisted development breaks down when useful reasoning disappears between sessions, and why durable project context matters more than clever prompts.
A Working Agent Is Not a Working Factory
How to test whether a layered agentic workflow preserves context, responsibility, verification, and recovery for a solo developer.
An Agentic Factory Is an Architecture, Not a Tool Stack
Why an agentic factory is an architecture of responsibility, evidence, and boundaries—not a stack of tools or a more powerful coding agent.