Plan drift: why the model that planned it isn't the model that builds it

The cheapest way to make a coding agent smarter is to plan with your best model and build with a faster one. It also introduces a bug most teams haven't named yet.

There's a workflow quietly becoming standard. You plan with the strongest model you have — Opus, say — because planning is where reasoning pays off most. Then you hand the plan to a cheaper, faster model — Sonnet, Haiku, whatever's economical at volume — to actually write the code. On paper it's the best of both: expensive thinking, cheap typing.

Then the build comes back subtly wrong. Not broken — wrong. It made a different choice at the fork the planner had already reasoned through. It picked the other library. It handled the edge case the planner explicitly wanted handled the other way. You re-read the plan and the intent was there — but the builder didn't act on it.

That's plan drift: the plan that lived in the planner's head — its context window, its chain of reasoning — never fully made it into the plan the builder received. The handoff dropped the part that mattered.

Why it happens

A model doesn't just emit a spec when it plans — it holds a hundred small resolutions it never wrote down, because to itself they were obvious. The tradeoffs it weighed, the option it silently rejected, the reason for this order and not that one. When the same model executes, all of that is still in context, so the code inherits it for free. When a different model executes, it inherits only what's on the page — and it fills every unwritten gap with its own defaults, which are not the planner's defaults.

Every handoff between models is a lossy compression of intent. The more of the reasoning that stayed implicit, the more the builder invents to fill it — and invention is where drift lives.

The fix isn't a better model. It's a better plan.

You can't keep the two models in sync by hoping. You close the gap by making the plan carry everything the handoff would otherwise drop — the decisions and the reasons, written down, before the build starts. A plan explicit enough that any model executing it makes the same choices the planner would have, because there's nothing left to guess.

That's exactly what a good planning document is for. In inplan, the plan is co-authored: the agent drafts it and flags its open decisions as inline questions, the human resolves them, and the resolutions live in the document — not in one model's transient context. When the plan moves to the next model (or the next session, or the next teammate), the why moves with it. The plan becomes the invariant across the handoff.

We've written before that a detailed plan makes a non-deterministic model reproducible — the plan is the seed. Multi-model workflows are the same problem wearing a different hat: you're not re-rolling the same model, you're rolling a different one, and only an explicit plan collapses the space enough that both land in the same place.

The takeaway

Splitting planning and execution across models is a good idea — it's just an underspecified one until the plan is strong enough to survive the trip. Don't ask the builder to reconstruct what the planner was thinking. Write the thinking down, resolve it with a human in the loop, and hand over a plan with no gaps left to fill.