Plan, loop, review pipeline
Imagine it this way: A film director: first the script (plan), then the shoot (loop), then editing and approval (review). Three phases, each with its own role.
The gold-standard pipeline for complex tasks: (1) enable plan mode and ask for a detailed plan, (2) refine the plan 2-3 times, (3) approve it and switch to loop mode to execute, (4) when the loop finishes, review the result with git diff before committing. Three phases, each with its own purpose.
The review phase is crucial, and many people skip it. After the loop finishes, run git diff and read the changes. Ask Claude: “review the diff and confirm that everything matches the plan.” This catches errors the loop didn't detect (e.g., semantic changes that pass the tests but change behavior).
In one sentence: plan, loop, review. Three phases, none skippable. Review catches what the loop misses.
Handoff between modes
Imagine it this way: The baton in a relay race: if you drop it, the next runner stumbles. The handoff between plan and loop needs to be clean so you don't lose context.
The critical moment is the transition from planning to execution. When you approve the plan, include an explicit instruction: "now execute the plan above, step by step, validating between each step". This ensures Claude follows the plan instead of improvising.
If the plan is long, break the execution into phases: "run steps 1-3 now" and then "run steps 4-6." This keeps Claude from losing context in the middle of a long run and lets you validate intermediate progress.
In one sentence: clean handoff = explicit instruction to "execute the plan above." Break it into phases if needed.
Scaling complexity
Imagine it this way: Building a doghouse is one project. Building a 20-story building is another. The technique is the same (brick by brick), but the orchestration is completely different.
For projects with dozens of files, a single plan isn't enough. The strategy: break the project into modules, create a plan for each module, and execute them in sequence. The master plan defines the order of the modules; the subplans define the steps within each module.
Use commits as checkpoints between modules. If module 3 breaks something, you can return to the commit for module 2 without losing the work from modules 1 and 2. This turns a large, risky project into a series of small, safe projects.
In one sentence: large projects = master plan + subplans by module + commits as checkpoints.
The three-phase pipeline: plan, loop, review. None is optional.
Handoff plan checklist for the loop
- - Plan reviewed and approved (2-3 refinement rounds)
- - Checkpoint commit created before starting
- - Active worktree or separate branch
- - Explicit instruction: "execute the plan above, step by step"
- - Stop criterion defined in the prompt
Multi-file orchestration
Imagine it this way: An orchestra: each instrument plays its part, but everyone needs to stay in sync. Editing multiple files is like conducting: each change needs to be consistent with the others.
When a feature touches 10 files, the order of edits matters. The plan should specify: types/interfaces first, implementation next, and tests last. This avoids intermediate compilation errors that confuse the loop.
Ask Claude to maintain a "consistency map": which interfaces changed, which implementers need updates, and which tests need to reflect the new interfaces. The map is part of the plan and guides execution.
In one sentence: types first, implementation next, tests last. Consistency map in the plan.
Rollback strategies
Imagine it this way: A climber always has a safety rope. You don't climb without being able to get back down. Rollback is the rope: the better it is, the higher you can go.
Three levels of rollback: (1) git reset revert everything to the latest commit, (2) worktree discard throws away the entire branch without affecting main, (3) incremental commits let you return to any intermediate checkpoint.
The golden rule: make a commit before starting the loop, and another commit after each completed phase. That way, you always have a clean rollback point. If something goes badly wrong, run git reset --hard to the last checkpoint and try a different approach.
In one sentence: commit before you start, commit between phases. Always have a clean recovery point.
Real-world case studies
Imagine it this way: Theory is nice, but real examples are convincing. Let’s look at two plan+loop pipelines in production projects.
Case 1: Migrating from Lodash to native ES in a project with 200 files. Plan: map all Lodash imports, categorize by function (map, filter, debounce), and prioritize by frequency. Loop: migrate file by file, running tsc after each one. Result: 200 files in 45 minutes, zero regressions.
Case 2: Adding i18n to an existing SaaS. Plan: extract all hardcoded strings, create a translation file, and replace them with i18n keys. Loop: work file by file, validating that no strings remain hardcoded. Review: manually review the translation file diff. Result: 3 hours instead of the estimated 3 days.
In one sentence: plan+loop on real projects: migrations in 45min, i18n in 3h instead of 3 days.
Module Summary
Next module:
2-6 — Agentic Coding — The New Normal: the philosophy and the mindset shift.