Use a Reasoning Model to Produce the Plan, Not Just the Answer

A division of labour: use the reasoning model once to decompose a hard problem into an explicit, ordered plan, then execute the individual steps with the cheaper fast model.

The expensive skill in hard work is the decomposition — seeing the right sequence, the dependencies, and the traps. Once that plan exists, each step is usually simple. Spending one reasoning-model pass on the plan and fast-model passes on execution gets you the depth where it matters and speed everywhere else.

Multi-step projects: migrations, research designs, feature builds, launch plans — anything where getting the order and structure right is most of the battle.

Small tasks that don't decompose, or problems where each step is itself hard enough to need reasoning (then keep the deep model throughout).

Goal: <the outcome>.
Constraints: <hard limits, resources, deadlines>.

Produce an ordered plan to reach this: number the steps, note dependencies, and flag the two steps most likely to go wrong. Don't execute yet — just the plan.

For migrating a monolith to services, the reasoning model returns a 9-step plan with 'extract the shared auth module first' flagged as the highest-risk step; you then run each step with the fast model.

Ask the plan to include a checkpoint after the riskiest step — an explicit 'verify X before continuing' — so execution can't blow past the point where things quietly break.

• Asking a reasoning model to plan and execute in one giant turn, so the plan is never reviewable.
• Executing every trivial step with the slow model out of habit.
• Skipping the human review of the plan, then discovering a bad assumption three steps in.