Plan-Before-Implement Gate

A workflow pattern requiring the LLM to produce a plan before writing code. Present in ~35% of tools (~18/52). Standard 5-step process: analyze → plan → present → approve → implement.

Variants (confidence: high)

• Hard gate (Windsurf, RooCode): Execution blocked until user explicitly approves the plan. Safety-first, slower.
• Soft gate (Claude Code, Cursor): Plan is produced but no explicit approval required. Faster, less safe.
• No gate (simple chat tools): Output produced directly. Fastest, least safe.

Mechanics (confidence: high)

1. Analyze the request
2. Produce a plan (architecture, files to modify, approach)
3. Present plan to user
4. Wait for approval (hard gate) or proceed (soft gate)
5. Implement

Trade-off (confidence: high)

Correctness vs. velocity. Hard gates catch errors before code is written but add friction to the user experience. Soft gates maintain flow but risk implementing the wrong approach.

Co-occurrence (confidence: high)

The plan gate is the natural extension of chain-of-thought-pattern — CoT produces the reasoning that the gate evaluates. It also works with task-state-machine, where the gate triggers state transitions. xml-envelope-format often provides the structured container for plan output.

Implications: The plan-before-implement gate is the defining pattern that separates agents from assistants. Tools with hard gates (Windsurf, RooCode) are designed for autonomous operation on complex tasks. Tools with soft or no gates are designed for rapid iteration. The choice is a fundamental product philosophy decision.

See also: chain-of-thought-pattern, task-state-machine, xml-envelope-format, windsurf-cascade-system

Sources

• [raw/prompts/articles/taxonomy-synthesis-2026-07-16.md]