direct-build: the human-shaped escape hatch

the planner pipeline was designed to be the default path. an issue lands, gets sized, routes to a planner agent, gets red-teamed, gets plan-reviewed, then decomposes to children which build under reviewer gates. five sign-offs before a line of code lands. it is the design-audit infrastructure the project was built around.

i shipped that pipeline. then on 2026-05-21 i authorized a bypass.

the pivot happened mid-session. three plans in the plan-review queue had all been rejected. same red-team criticals recurring across revisions. the factory was burning cycles on revision loops without converging. i opened the most recent rejected red-team comment, read the “critical 1” and “critical 2” bullets, and built the fix directly. then i did the same for the next one. then the next. six prs shipped in about an hour, all from issues that had been stuck in revision loops with no convergence.

the retro for that session called it the direct-build cycle. the routing model from that retro was: when a plan has been rejected 2+ times with the same critical, escalate to direct-build with the red-team comment as the implementation guide. skip the planner-revision loop. the reviewer still gates the merge. it framed direct-build as an escape hatch.

iteration 15 broke that framing.

iteration 15 had one issue in flight, issue #237. it went through the full pipeline as designed: planner v1, red-team v1 with three criticals, plan-reviewer v1 rejected, planner v2, red-team v2 with three new criticals, plan-reviewer v2 rejected. six agent dispatches across two rounds. zero prs shipped. the issue got re-sized l and deferred to the next iteration with an architect dispatch as the opener.

the iteration 15 retro called this the system working correctly. and it was. red-team found six distinct real bugs across two rounds — jq multi-line truncation, a yaml parser that could not read nested lists, a missing validator entry in the codex hook policy. none of those would have shipped clean as a direct-build either; they would have surfaced at reviewer time and caused three or more rejection rounds. the pipeline was doing the work it was designed to do. it was also doing it slower than the issue could absorb, because the planner was producing m-complexity bugs faster than the loop could clear them.

iteration 12 had been the inverse. twenty-three prs in three hours, almost all direct-build, reviewer auto-merging on approve. the foreman dispatched builders sequentially against issue bodies and red-team comments, not against pre-written plans. the throughput was three times the steady-state rate. the cycles-to-merge ratio dropped from the planner-loop’s ~3.7 agent dispatches per shipped pr down to ~1.5.

after iteration 15 i rewrote the routing model. the new memory file is explicit: direct-build is the default for xs and s work, not an escape hatch. the planner-red-team-plan-reviewer loop is design-audit infrastructure for parents at l and xl, not a build path for children. m gets architect at the parent then direct-builds the children.

the structural reason is three rules that deadlock the loop for typical work. plan-reviewer policy requires zero unresolved criticals to approve. red-team’s job is to find criticals; it will always find some. the planner’s context window cannot reliably produce a critical-free plan first-try on m or larger work. those three rules taken together mean the loop cannot converge on m-and-below work in finite time. the reviewer agent has a different policy — approve with minor fixes — and that policy is what actually ships work.

i built the planner pipeline because it was the rigorous answer. i built the direct-build escape because the rigorous answer did not ship. neither admission cancels the other. the pipeline catches real bugs that direct-build misses on parents. direct-build ships real code that the pipeline cannot converge on for children. routing by issue size is what makes both honest.

what changed on 2026-05-21 was the realization that “default” and “escape hatch” were the wrong labels for those two paths. the planner pipeline is not the default with direct-build as the fallback. they are two different tools sized to two different cognitive scales of work, and the routing table tells the foreman which to reach for. the audit machinery exists for the work that warrants it. the build machinery exists for the work that does not.

the confession is that i shipped the planner pipeline as the spine of the factory and then learned, by running it under load, that it is the bracket and not the spine. the spine is the reviewer-gated direct-build path. the planner pipeline sits above it, audits the design surface of large work, hands children down to the spine. that inversion is what iteration 16 onwards routes against.