Why I Break Big Tasks into Phases — When I Realized All My Tools Look the Same
The pattern I use every time I do big work with AI — why I divide into phases and put gates at the boundaries
One day I lined up all my tools side by side and noticed something odd. The content pipeline, the build-plan, the product design pipeline… all built at different times for different reasons, yet they were all shaped exactly the same. Break the big task into phases, put a gate at each boundary. That felt like more than a coincidence. I started thinking there might be some underlying principle at work when you’re doing big things with AI.
Three Problems That Appear When You Hand Everything Over at Once
First, why this pattern is even necessary. When you throw a big chunk at AI all at once, three problems show up.
The first is context limits. Cram a long task into one session and quality starts falling apart past the halfway point. The model gradually forgets what was decided earlier.
The second is error inheritance. If the previous step is even 0.5% off, everything built on top of it inherits that error. Something I actually experienced in a build-plan session — if the contract layer (persistence, domain contracts, that kind of thing) is wrong when you flow into implementation, fixing it later can cost more than starting over from scratch.
The third is losing any point for a human to intervene. You only discover “this isn’t what I wanted” after everything is done. By then it’s too late.
Four Principles That Work Everywhere
There’s a pattern to the ways of splitting that actually work.
① Dependency order — contracts and skeleton first, flesh on top. It’s why build-plan stands up the trunk (contract layer) before fanning out branches in parallel. And why the content pipeline drafts the seed first before writing the body. Same principle.
② One phase = one context — otherwise things blow up. In build-plan, designing “one session = one item = a self-contained unit” and splitting the content pipeline into seed / draft / published are both driven by this principle.
③ A gate at every boundary — review, verification, hallucination checks go between phases. Attaching a gate (✓) to trunk items in build-plan so a human reviews the contracts, and inserting a raw-source cross-check step between draft → review → published in the content pipeline — those are the examples.
④ Auto vs. manual per phase — some phases the AI runs autonomously, others a human handles directly. In build-plan, the branch phases (B6–B11) are auto while the trunk and deployment have human gates. In content, writing the body is AI’s job, reviewing it is the human’s.
How This Pattern Shows Up Differently in Each Tool
The same principle takes different shapes depending on context.
In build-plan, the flow goes trunk (contracts) → branches → integration → verification → deployment, with a pause at the gate after trunk integration. The trunk is the contract layer, so if it goes wrong it propagates to all six branches — that’s why it gets extra care.
The content pipeline splits into seed → draft → published, with review and raw cross-check at each boundary. This video was made through that pipeline, and the step where I read and compare against the raw source is what structurally prevents the content from being made up.
product-pipeline flows through requirements → architecture decisions (ADR) → system design → API contracts → app architecture, with a human making a multiple-choice selection at each step. AI recommends, but the human decides the direction.
Even in Auto Mode, Important Things Stop — That’s the Real Safety Net
Something that actually happened in a build-plan session. During MikroORM design, I’d designed for v6 but the setup was on v7, which would completely change the scaffold. The item was in auto mode, but the agent stopped and asked.
At first I thought “why is it asking, it’s auto?” — but looking back, it makes sense. Auto means “don’t show me the plan first,” not “ask nothing at all.” Decisions contained within a phase get handled in auto. But decisions with a large blast radius, hard to undo, or genuinely belonging to a human — those surface up through the mode setting.
That’s a much more powerful safety net than static gates (per-item auto/plan labels). It catches the cases you missed in your upfront classification during actual execution.
When This Approach Doesn’t Fit
Dividing into phases isn’t the right call for every task.
For small tasks, the ceremony of setting up phases costs more than it gains. Designing trunk / branches / gates for a single simple edit is pure waste. Three or four items? A flat list is enough.
Same goes for exploratory work — tasks where the phases themselves keep getting redefined as you go. Forcing rigid division at a stage where you don’t yet know what you’re building will just trip you up.
What Was Actually Different After Using It
Developing myWiki with the build-plan approach, the thing that surprised me most was how my role changed. Before, I was typing every keystroke myself (executor). Now the agent executes and only escalations come up to me (manager). I have breathing room. Developing while shooting the breeze became genuinely possible.
The reason that breathing room isn’t slacking off — it’s evidence the system is running as designed. Phases are divided, gates are at the boundaries, escalations come up properly, so the AI handles execution. What’s left for the human is direction and judgment.
If You Take Away Just One Thing
Before handing a big task to AI, figure out just two things first.
① How will I divide this task into phases?
② What will I check at each phase boundary?
With just these two, things blow up less and tangle less than when you throw it all over at once. And when AI stops and asks you something — knowing that’s not an annoyance but a signal that the system is working — makes the whole thing a lot easier to live with.
Method: Cutting Dev Time with the Build-Plan Skill · Deep dive: Claude Code 4-Lever Method · Background: The myWiki Origin Story · See also: Agent Context Cutoff and Second Brain Integration · See also: Decide Before You Code — the product-pipeline Skill]