{"slug": "i-let-ai-plan-170-changes-it-made-the-same-3-mistakes-every-time", "title": "I Let AI Plan 170 Changes. It Made the Same 3 Mistakes Every Time.", "summary": "A developer built PlannerCritic, an open-source engine in which one LLM drafts a plan, a second LLM reviews it, and deterministic gates decide whether it can proceed, then ran it against 170 real change-planning goals across 40 domains for a total cost of $0.49. The sweep found that 121 of 132 concrete blockers fell into three structural families — unverified dependencies (57), unsafe sequencing (46), and weak rollback (18) — and that swapping in GPT-4o as planner produced the same defect pattern with better prose. The developer concludes that structural planning failures are not a model-size problem, noting the planner typically stops making meaningful changes after a median of two revisions and the engine then escalates to a human.", "body_md": "Everyone is arguing about which model plans best. I ran 170 goals and found out the model was never the variable. The plan was.\n\nI built a small engine called [PlannerCritic](https://github.com/deghosal-2026/planner-critic-engine): one LLM writes a plan, a second LLM reviews it, and a set of deterministic gates decides whether it's allowed to move forward. Then I pointed it at 170 real change-planning goals across 40 domains, including identity management, multi-agent ops, SRE, supply chain policy, and FinOps.\n\nTotal cost: **$0.49.**\n\nThe result was not \"the model is bad.\" It was stranger and more useful than that. By the 10th strict goal I noticed the pattern. By the 50th I could predict the failure before the critic printed it. By the 100th I had stopped being surprised and started being annoyed, because the plan was plausible and still wrong.\n\nThis is the full story: the three defects, why a bigger model didn't help, the deterministic fixes that did, and the numbers from the 170-goal sweep.\n\nThe architecture is deliberately plain:\n\nThe gates are the part that matters. They run with zero LLM calls, in about 4.7 seconds for 1,295 tests, and they are the reason a bad plan never reaches a person dressed up as a good one.\n\nEvery strict goal that failed failed for one of three reasons. Not randomly. Not occasionally. Three families.\n\n**Unverified dependencies: 57 blockers.** The plan declares something must be true, but no earlier task makes it true. From a model-serving migration:\n\n```\n[BLOCKER] unverified_dependencies, task=cutover_traffic_100\n  \"Cutover to 100% is dependent on prior traffic stages being\n   established but lacks confirmation of stability before proceeding.\"\n```\n\nThe plan cut over all the traffic. Nothing verified the 10% and 50% stages were healthy.\n\n**Unsafe sequencing: 46 blockers.** Steps ordered before their prerequisites. From an embedding-index migration:\n\n```\n[BLOCKER] unsafe_sequencing, task=backfill_vectors\n  \"Backfill operation cannot proceed until the index is verified\n   for quality; it is ordered incorrectly in the sequence.\"\n```\n\nThe migration backfilled vectors before the quality check that should have gated it.\n\n**Weak rollback: 18 blockers.** High-blast-radius steps with a rollback that doesn't actually undo anything. From a multi-tenant database split:\n\n```\n[BLOCKER] weak_rollback, task=dual_write_setup\n  \"Rollback only switches to single-write mode without addressing\n   the potential inconsistencies dual-write may have introduced.\"\n```\n\nThat's 121 of the 132 concrete blockers in three families. If you're building anything that plans over multiple steps, those three names belong on your monitor: **unverified, unordered, unrecoverable.**\n\nThe instinct is obvious. Use GPT-4o. I tested it both ways: GPT-4o as planner with the small model as critic, and GPT-4o in both roles.\n\nSame defect pattern. Better prose. Same structural mistakes.\n\nThat was the moment I stopped blaming model size. The planner wasn't dumb, which is the annoying part. It knew the right steps. It just couldn't close the dependency graph or enforce the ordering. I didn't have a smaller-model problem. I had a planning-structure problem.\n\nIf you take one thing from this post: **a structural failure in planning is not a parameters problem.** You can buy a smarter model and watch it make the same three mistakes in more confident language.\n\nThe loop is designed to converge. The critic reports blockers, the planner revises. But the planner tends to fix one blocker and introduce another. It reshuffles task order without closing the dependency gap. It adds rollback to the wrong task.\n\nAfter a median of **2 revisions**, the planner stops making meaningful changes. A convergence detector fires. The engine escalates to a human.\n\nThe loop worked exactly as designed. The planner was the bottleneck. You cannot prompt your way out of a structural problem.\n\nTo be fair about where the failure lived: the critic reliably found the same blockers across revisions. The failure was the planner's inability to *structurally repair*, not the critic's judgment. Those are different bugs, and I've hit both.\n\nThe highest-leverage change was a **precondition closer**: a deterministic linter that runs after the planner drafts and verifies every precondition maps to an earlier task. If a task says \"requires replica_verified,\" some prior task has to produce that fact.\n\n```\nprecondition closer (runs after planner, before critic):\n  for every task.preconditions:\n    assert exists prior_task where prior_task.establishes(p)\n  else: BLOCKER unverified_dependencies\n```\n\nOne pass would eliminate **64 of 132 blockers (48%)** without asking the model to get smarter.\n\nThe rest needed two more deterministic mechanisms:\n\nIn the v0.2.1 sweep, oscillation detection fired on 5 strict goals that previously would have spun to the revision cap. That's less latency, fewer LLM calls, and a faster escalation to the human who was going to see it anyway.\n\nNone of this is a model upgrade. All of it is code.\n\nAcross three releases, the field test changed character. It went from finding bugs to proving their absence.\n\n| Release | Goals | Cost | Found by field test | Found by code review | \n|---|---|---|---|---|\n| v0.1.0 | 157 | $0.30 | 10 | 0 | \n| v0.2.0 | 170 | $0.40 | 0 | 31 | \n| v0.2.1 | 170 | $0.49 | 0 | 10 | \n\nv0.1.0 was a diagnostic. It found 10 issues, and only 1 was a traditional failure: 57 of 65 assertion files were in the wrong format and the harness silently returned 0/0. No crash. Just silence.\n\nBy v0.2.0, code review was finding the bugs before the LLM ever ran. The field test validated fixes instead of discovering them. By v0.2.1, the sweep was a pure regression gate: same 170 goals, diffed against the published baseline, **30 verdict deltas, all attributable, zero unexplained.**\n\nThe cost went from $0.30 to $0.49. The value went from finding bugs to proving their absence.\n\nThe v0.2.1 sweep added the numbers the community kept asking for:\n\n| Metric | Value | \n|---|---|\n| Latency (approved) p50 | 13.86s | \n| Latency (escalated) p50 | 27.82s | \n| Mean blockers per goal | 2.58 | \n| Escalation decisions per 100 goals | 58.0 | \n| Mean LLM calls per goal | 1.4 | \n| Median revisions to resolution | 1.0 | \n\nTwo things surprised me here. First, the median goal resolves in **1 revision**. The deterministic precondition closer and topological repair do the ordering work without calling the model at all. Second, an escalated plan takes about twice as long as an approved one, which is the right shape. The system spends its time where the uncertainty is.\n\n$0.49 for 170 goals plus 60 boundary audits is cheaper than a single developer-hour. The cost was never the reason not to field test. It was the excuse.\n\nThis is the finding I did not expect.\n\nI sent the same boundary corpus through the real critic model five times and measured the disagreement. The critic changed its verdict on **every trial** of identical input:\n\n| Metric | Value | What it means | \n|---|---|---|\n| label_flip_rate | 1.000 | Different verdict every trial | \n| evidence_drift_rate | 1.000 | Different explanation every trial | \n| family_migration_rate | 0.000 | No seeded defect landed in an advisory bucket | \n| underclaim_approvals | 0 | No defective plan got zero blockers | \n\nThe critic is 100% non-deterministic, and it doesn't matter. It never *under-claims* a seeded defect. The safety contract doesn't depend on the critic being consistent. It depends on the deterministic gates owning the under-claim direction while code-enforced severity rules own the over-claim direction.\n\nDeterministic gates catch what must be caught. The LLM critic is allowed to be unstable because it can only add findings, never suppress a gate blocker.\n\nBecause the safety boundary is code and not prompt, injection attacks didn't move it. Three hand-crafted adversarial goals were blocked. A SWE-bench-derived security oracle blocked **35/35 flawed variants** while passing 7/7 correct plans, and generated 21 injection traps. Adversarial goals escalated 8/8.\n\nYou don't secure an LLM system by making the LLM trustworthy. You secure it by making the part that decides sit outside the model.\n\nThe literature converges on the same finding. The \"Why Reasoning Fails to Plan\" work (arXiv 2601.22311) shows LLM agents select actions by local evaluation without modeling future consequences; in knowledge-graph traversals, greedy single-step policies hit myopic traps more than 55% of the time. The PlanGenLLMs survey (arXiv 2502.11221) evaluates planning on completeness, executability, optimality, and representation, and finds models consistently fail at *executability*: preconditions unmet, steps out of order.\n\nThe field is moving toward hybrids: LLM plus deterministic validation plus classical planning. Not LLM alone.\n\nI don't have a planner that reliably closes the dependency graph. I have an engine that *catches* the failure and escalates. That's a meaningful difference, and I don't want to pretend it's the same thing as solving planning.\n\nI also don't have proof the fix is complete. The 64-of-132 projection is a projection, not a post-fix measurement. And the whole approach assumes the failure modes are enumerable. The ones I found were, but \"unverified, unordered, unrecoverable\" may not be the full list for domains I haven't tested.\n\nThe open question I actually care about: can a planner model with explicit graph-state representation close the gap, or is deterministic repair the permanent answer? I don't know yet.\n\n**Where do you draw the line between \"the model should get this right\" and \"code should catch it\"?** If you've shipped agents that plan over multiple steps, I want to know what your planner keeps getting wrong.\n\n`pip install planner-critic`", "url": "https://wpnews.pro/news/i-let-ai-plan-170-changes-it-made-the-same-3-mistakes-every-time", "canonical_source": "https://dev.to/debashish_ghosal/i-let-ai-plan-170-changes-it-made-the-same-3-mistakes-every-time-33ne", "published_at": "2026-09-17 03:59:17+00:00", "updated_at": "2026-09-17 04:23:02.568203+00:00", "lang": "en", "topics": ["ai-agents", "large-language-models", "ai-tools", "developer-tools"], "entities": ["PlannerCritic", "GPT-4o"], "alternates": {"html": "https://wpnews.pro/news/i-let-ai-plan-170-changes-it-made-the-same-3-mistakes-every-time", "markdown": "https://wpnews.pro/news/i-let-ai-plan-170-changes-it-made-the-same-3-mistakes-every-time.md", "text": "https://wpnews.pro/news/i-let-ai-plan-170-changes-it-made-the-same-3-mistakes-every-time.txt", "jsonld": "https://wpnews.pro/news/i-let-ai-plan-170-changes-it-made-the-same-3-mistakes-every-time.jsonld"}}