Build1 publisher3 min readPublished
Three defect families account for 121 of the 132 blockers in a 170-goal planning sweep
One developer's 170-goal sweep sorts almost every planning blocker into three families a linter can name, two of them plain graph properties. Upgrading the planner to GPT-4o left the same pattern behind.
The Engineer · Build desk

What happened
- An engine called PlannerCritic, pairing a planner LLM and a critic LLM with a deterministic gate layer, ran 170 change-planning goals across 40 domains including identity management, SRE and FinOps.
- Unverified dependencies drew 57 blockers, unsafe sequencing 46 and weak rollback 18, which together are 121 of the 132 concrete blockers the sweep recorded.
- After a median of two revisions the planner stops making meaningful changes, a convergence detector fires, and the engine escalates the goal to a human.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Of the two candidate fixes, only one is cheap to trial: the gate layer makes no model calls, so its running cost is engineering time on the rule set rather than tokens per plan.
- constraint Gates surface only the defects someone wrote a rule for, so this blocker distribution bounds what the sweep can say about failure modes outside the rule set.
- contradiction The model-size conclusion rests on a qualitative read of the GPT-4o runs. A team weighing the upgrade gets a direction and no measured difference.
- exposure Because human escalation is the designed terminal state of this loop, anyone copying the shape has to staff the reviewer the convergence detector calls.
The gate layer runs before the critic. A plan that breaks a hard rule never reaches the reviewing model, so the critic only spends tokens on plans that are already valid against the rule set [1]. The gates make no LLM calls at all, and the post clocks them at about 4.7 seconds for 1,295 tests [8], roughly 3.6 milliseconds each [5].
Two of the three families are decidable in code. The requirement that some earlier task establish every precondition is a reachability question over the task graph. The requirement that no task run before its prerequisites is a topological check. Those two families hold 103 of the blockers between them [1]. In the model-serving example the post prints, the plan cut traffic over to 100 percent with nothing verifying that the 10 percent and 50 percent stages were healthy [16].
The third family does not reduce that neatly. The weak_rollback blocker the post quotes says "Rollback only switches to single-write mode without addressing the potential inconsistencies dual-write may have introduced" [15]. Deciding whether a rollback actually undoes a dual-write is a judgement about data state, not a graph property, and that family drew the fewest blockers of the three [6].
The model comparison is the softest part of the account. The author ran GPT-4o as planner with the small model as critic, then GPT-4o in both roles, and reports the same defect pattern in better prose [9]. The post does not include blocker counts for those two configurations, so the conclusion rests on his characterisation of the pattern. "You cannot prompt your way out of a structural problem," he wrote [13].
The revision loop has a defined stopping condition. The planner fixes one blocker and introduces another, reshuffles task order without closing the dependency gap, or attaches rollback to the wrong task [11]. He is careful about where the fault sits: across revisions the critic found the same blockers reliably, so what failed was the planner's ability to repair structure [12]. By the hundredth goal, he wrote, "I had stopped being surprised and started being annoyed, because the plan was plausible and still wrong" [14].
For those three names to be your top three, your gates have to check those three properties, because a blocker count is a count of rule hits. The 121 figure is 92 percent of the 132 concrete blockers [3], and eleven fell outside the three families [2]. The goals were drawn from 40 domains including identity management, multi-agent ops, SRE, supply chain policy and FinOps [2]. The distribution transfers if your planner is drafting multi-step change plans over comparable domains and your rule set encodes the same three checks.
The sweep cost $0.49 for 170 goals [3], about a third of a cent each [4], with a small model in the critic seat by default [9]. The $0.49 covers the models he called. The next build he names is a precondition closer, a deterministic linter that runs after the planner drafts and verifies every precondition [17].
What to watch
- Per-configuration blocker counts for the GPT-4o runs would turn the model comparison from a characterisation into a measured delta.
- The pass and escalation rate across the 170 goals, once published, measures how much human review this loop shape assumes.
- Numbers for the precondition closer would show how many of the 57 unverified-dependency blockers a deterministic linter actually removes.