The Plan Blocked Me. That Was the Correct Outcome.

The brief was approved. Scope defined, questions closed, acceptance criteria written. The obvious move was to start building.

I ran the Plan phase first.

Planning and the Plan phase are not the same thing.

Planning produces direction. The Plan phase produces a gate.

Every engineer plans. Sprint boards. Jira tickets. A rough sequence before a large refactor starts. It works well enough because a human engineer carries what the plan does not say. They know what they did not write down.

An agent does not. An agent fills the gaps with its best guess. That is not inefficiency. It is drift. I covered what drift costs in the last part of this series.

The Plan phase has one property that a sprint board does not: refusal conditions.

A plan that cannot refuse you is documentation. A plan with refusal conditions is a gate.

Nobody brings materials to a construction site and figures out the building as they go. There is a blueprint first. Then an estimate. The estimate is not the slow part. Finding out mid-build that a wall cannot go there is the slow part.

The brief is the blueprint. The Plan phase is the estimate.

The impact map found what the brief described in one line

The refactor target was a god class. It owned too much. The brief said split it.

Most codebases have a version of this. A module that owns too much and the team has learned to work around. The brief names it in one line and moves on. The impact map cannot.

It found that the god class held the payload formatting logic. Every notification the system sent passed through it before leaving the application boundary. Split it wrong and the notification contract breaks. Which phase owns that during the transition?

I thought the brief had answered that. It had not.

The impact map could not answer it either. That required the risk register.

The plan blocked. That was correct.

The risk register stopped me at a question I had not prepared for.

The payload format was a contract with the external notification provider. The provider expected specific field names and structure. It did not return an error when that structure changed. It silently rejected the payload. No exception. The only evidence would come downstream, weeks later, when someone noticed the silence.

That kind of failure is a time bomb.

There was no mitigation in the current plan. The plan blocked.

My first instinct was to push through. Grant myself the waiver. Flag it low risk. Sort it out during Build. That is the exact moment the Plan phase exists to intercept. Not because the risk was catastrophic. Because the question was unanswered, and an unanswered question does not disappear. It travels into Build and becomes the agent's problem.

I had always sorted things like this mid-build. This time the plan would not move until I had the answer.

That cost time I had not budgeted. It cost less than tearing down a wall mid-build.

So I answered it.

The decision was made at plan time, not build time

I made the call. Not automatically. The simpler path was to move everything in one phase. But one ordering changed the external interface before the replacement was verified. The other preserved the notification contract through the transition and required a human to confirm the payload format before the agent could proceed.

No code was written. I made a sequencing decision. The agent would follow it.

A human engineer would have caught this mid-build. Professional instinct. Write "migrate notification dispatch" as a task and the agent migrates it. It does not know the field names are a contract. It does not know silent rejection is the failure mode. It does not know to pause before continuing.

The god class was specific to this refactor. The problem it exposed was not. Something will always look safe to move. What makes it unsafe is external, invisible to a scan, and silent when it breaks.

Build owns code. Plan owns sequencing.

The plan was signed. That was not the end.

Think told me what to build. Plan told me in what order. Those are not the same document and they are not the same decision.

That is not a handoff. That is a gate.

Build started with a plan the agent could not diverge from. Whether the plan was precise enough was a question only Build could answer. That is the next part.

A key takeaway:

This is not a template I built for this article. It is the skill that I run for my plans.

The plan skill prepares an impact map, risk registers, phases and verification gates. It enforces that all risks are known and user is acknowledged before Build begins and produces the plan as a versioned artifact.

Use it in the sequence to the Think. Once the brief is generated, you prepare a plan and read how it differs from the regular plans that AI makes.

plan.md on GitHub Gist

Comments

[Luis]

I really like this perspective — especially the idea that sometimes being “blocked” by a plan isn’t failure, but a correction of direction.

It’s a powerful reminder that rigidity kills momentum, while adaptability often leads to better outcomes than the original plan ever could.

Great read and honest reflection — appreciate you sharing this 🤝

[Jeel Vankhede]

Thank you for your support! Whole workflow series in progression. I would appreciate your thoughts on the whole series. Cheers!

[Luis]

This is a strong systems-thinking piece — the most valuable idea here is the separation between “thinking” vs “planning as a gate”, especially in agent-driven workflows.

What stands out is the emphasis on refusal conditions. That’s the part most AI workflows miss entirely. In practice, agents don’t fail because they lack instructions — they fail because they proceed through ambiguous boundaries where a human would normally pause and re-evaluate assumptions.

The “silent failure via external contract” example (notification payload rejection) is especially important. That’s exactly the kind of issue that:

doesn’t surface in static analysis
doesn’t break immediately
and only shows up as downstream data loss

So the idea that the Plan phase should act as a risk-aware execution gate rather than a task checklist is actually a meaningful abstraction for agent workflows.

Where this gets interesting at scale is when:

plans become versioned artifacts
risk registers are machine-checkable constraints
and execution is forced to stay inside validated boundaries

That’s basically moving from “agent executes steps” → “agent executes within a verified contract.”

Good series direction overall — this is one of the cleaner ways of formalizing reliability in AI-assisted engineering without overcomplicating the system 🤝