The Five-Phase Workflow
A human-in-the-loop pipeline for planning and implementing complex work using multiple AI models in structured, role-aware stages.
A human-in-the-loop pipeline for complex work
Most teams use AI models as individual productivity tools — one model, one conversation, one output. That approach works well for simple tasks.
For complex work — where stakes are high, scope is uncertain, and errors compound — a more structured approach produces better results.
The five-phase workflow assigns different AI models to different roles across the lifecycle of a task: scaffolding, ideation, planning, critique, and governed execution. Each phase produces a specific output that feeds the next.
The human remains in the loop between every phase — reviewing outputs, deciding whether to advance, and carrying judgment that no model should own.
The five phases
Phase 1 — Scaffold
Goal: Create a structured mission or task definition from a template.
Role: A model with strong context awareness and repo familiarity (ideally working directly inside the codebase or project environment).
Input: Project context, templates, prior work.
Output: A structured task definition that captures intent, scope, impacted areas, and explicit constraints. No implementation details — just the bounded problem.
Why this phase matters: Skipping it means later phases anchor on vague or implicitly scoped work. The scaffold forces scope clarity before any planning begins.
Phase 2 — Ideate
Goal: Generate implementation approaches freely, before any model has anchored on patterns.
Role: A model optimized for open-ended reasoning and creative challenge — one that has not been primed with the codebase or existing patterns.
Input: The structured task definition from Phase 1.
Output: A range of implementation approaches, risks, open questions, and considerations that the scaffold may have missed.
Key constraint: Do not write code or implementation plans. Focus on system design, component boundaries, data flow, and user-facing behavior.
Why this phase matters: Fresh perspective before grounding. A model that has not seen the existing solution space is more likely to surface alternatives and challenge assumptions.
Phase 3 — Plan
Goal: Produce a concrete, grounded implementation plan.
Role: A model with strong codebase awareness that can ground the Phase 2 ideas against real constraints.
Input: The scaffold from Phase 1 and the ideas from Phase 2.
Output: A structured implementation plan: intent, files to change, approach per story or task, and open questions.
Key constraints:
- Flag any schema, auth, or security changes as requiring architect review
- Mark any database queries, import paths, or infrastructure config as deferred implementation details
- Do not write code
Why this phase matters: Translates free ideation into something executable, while surfacing what still needs human decision.
Phase 4 — Critique
Goal: Adversarially review the plan for mistakes, gaps, and over-engineering.
Role: The same model used in Phase 2 (or another fresh perspective), reading the plan cold.
Input: The implementation plan from Phase 3.
Output: The plan with issues annotated inline — or a revised plan with a summary of what changed and why.
The prompt posture: Act as a critical senior engineer. Find what is missing, over-engineered, ordered incorrectly, or likely to fail in practice. Be direct.
Why this phase matters: Every plan has something wrong with it that the planner cannot see. A dedicated critique phase finds it before implementation begins, not after.
Phase 5 — Execute
Goal: Governance review against invariants, then implementation.
Role: A model with strong code execution, test integration, and governance enforcement capabilities.
Input: The refined plan from Phase 4.
Output: Shipped work that passes verification.
Protocol:
- Review the plan against the project's invariants and stop conditions before writing any code
- Execute the approved plan
- Run verification (lint, type-check, tests, schema checks) before declaring done
Why this phase matters: Governance without execution is bureaucracy. Execution without governance is risk. Phase 5 does both — but in the right order.
Quick reference
| Phase | Role | Model posture | Output |
|---|---|---|---|
| 1. Scaffold | Structured task definition | Context-aware, repo-grounded | Scoped task with explicit constraints |
| 2. Ideate | Creative challenge | Fresh perspective, no anchoring | Implementation ideas + risks |
| 3. Plan | Grounded planning | Codebase-aware | Structured implementation plan |
| 4. Critique | Adversarial review | Critical, no attachment to the plan | Annotated/refined plan |
| 5. Execute | Governed implementation | Disciplined, verification-oriented | Shipped, verified feature |
Why this works
The key insight is that different tasks require different cognitive postures, and no single model (or single human) excels at all of them simultaneously.
The model best suited for open-ended ideation (Phase 2) is not the model best suited for grounded implementation planning (Phase 3). The model that planned the work is the worst person to critique it (Phase 4). Governance and execution require a different discipline than creative challenge.
The workflow creates structured handoffs between these postures — with a human reviewing and approving at each boundary.
The most commonly skipped phase is Phase 4. A planning model will always find something a critique model misses. Running both is not redundant — it is the difference between a plan that looks right and a plan that holds up.
Adapting the workflow
The five phases are a pattern, not a rigid prescription.
For smaller tasks, phases can be compressed: 1 + 2 can combine into a single session if scope is clear. For larger or higher-stakes work, each phase deserves a full independent session.
The non-negotiables:
- Scope must be explicit before planning begins (Phase 1 is never optional)
- Planning and critique must be separated (the planner should not review their own plan)
- Execution should only begin after human review of the final plan