{"slug": "stop-using-one-frontier-model-for-everything-my-role-based-ai-coding-stack", "title": "Stop Using One Frontier Model for Everything: My Role-Based AI Coding Stack", "summary": "A developer proposes replacing the single-frontier-model approach to AI coding with a role-based stack that assigns different models to planning, implementation, review, and orchestration. The workflow uses the cheapest model that can reliably complete a task, escalates on failure, and treats failure as a routing signal, citing research on agent routing and execution feedback.", "body_md": "The current AI coding discussion spends too much time asking which model is “best.”\n\nI think that framing is already becoming obsolete.\n\nThere may be a best model for a particular benchmark, but software engineering is not one task. It is a pipeline containing planning, repository exploration, implementation, debugging, documentation, testing, validation and adversarial review.\n\nWhy should every stage use the same model?\n\nMy current approach is to treat models like members of an engineering organization:\n\n```\n                    ORCHESTRATOR\n                         Sol\n                          │\n                ┌─────────┴─────────┐\n                │                   │\n             PLANNER             REVIEW\n              Opus            Grok / Kimi\n                │             Truth Seekers\n                │\n         ┌──────┴──────┐\n         │             │\n      WORKERS       ESCALATION\n Gemini Flash        Sonnet\n DeepSeek          Qwen 3.8 Max\n GLM                 Terra\n Luna\n Muse\n MiniMax\n         │\n         ▼\n Tests / CI / deterministic validation\n```\n\nThe principle is simple:\n\nUse the cheapest model that can reliably complete the task, escalate when necessary, and independently review important outputs.\n\nThis isn't purely a personal workflow preference. Recent research on coding-agent routing starts from essentially the same observation: users have access to multiple models with different strengths, and no single model dominates every task. Agent-as-a-Router goes further by treating routing as an execution-feedback loop rather than a one-time model-selection decision.\n\nMy worker pool currently includes:\n\nWorkers receive bounded tasks.\n\nExamples:\n\n```\nImplement this validated plan.\n\nAdd tests for these acceptance criteria.\n\nRefactor these three classes without changing behavior.\n\nTrace this exception to its originating call.\n\nGenerate fixtures covering these boundary conditions.\n\nInspect this module and report deviations from the specification.\n```\n\nThis distinction matters.\n\nI don't necessarily want a worker deciding the architecture while simultaneously implementing it.\n\nThe architecture may already have been decided upstream.\n\nThe worker's job is execution.\n\nThis lets me optimize worker selection for:\n\nrather than demanding maximum intelligence on every call.\n\nMy next tier currently includes:\n\n**Sonnet, Qwen 3.8 Max and Terra.**\n\nThese become useful when the worker encounters something that actually requires stronger reasoning.\n\nFor example:\n\n```\nWorker attempt #1\n        │\n        ▼\nTests fail\n        │\n        ▼\nWorker remediation\n        │\n        ▼\nSame failure / low confidence?\n        │\n       YES\n        ▼\nEscalate\n        │\n        ▼\nSonnet / Qwen / Terra\n```\n\nThe key idea is that **failure itself becomes a routing signal**.\n\nA simple task shouldn't start at the most expensive model merely because it might become difficult.\n\nStart cheap.\n\nObserve.\n\nEscalate.\n\nThis is also where model-routing research is heading: routing can incorporate execution feedback rather than relying entirely on static task classification.\n\nMy preferred planner is currently **Opus**.\n\nPlanning deserves its own model because a bad plan has multiplicative consequences.\n\nImagine spawning ten extremely capable workers against an incorrect architecture.\n\nYou haven't improved productivity.\n\nYou've parallelized the mistake.\n\nA planner should establish:\n\nOnly then does execution begin.\n\nFor complex work, I increasingly prefer:\n\n```\nRequirement\n    ↓\nOpus\n    ↓\nPlan\n    ↓\nPlan review\n    ↓\nWorkers\n```\n\nrather than:\n\n```\nRequirement\n    ↓\nHuge coding model\n    ↓\n\"Go build everything\"\n```\n\nThe second approach looks agentic.\n\nThe first is much easier to govern.\n\nThis distinction became increasingly obvious to me while using different frontier models.\n\nMy current favorite orchestrator is **Sol**.\n\nThe planner answers:\n\nHow should we solve this problem?\n\nThe orchestrator answers:\n\nWhat should happen next?\n\nThose are different responsibilities.\n\nA good orchestrator must continuously reason about system state:\n\n```\nGoal\n │\n ├── Task A → Worker 1\n ├── Task B → Worker 2\n └── Task C → Worker 3\n                 │\n                 ▼\n              failure\n                 │\n        retry or escalate?\n                 │\n                 ▼\n             specialist\n                 │\n                 ▼\n               review\n```\n\nIt must decide:\n\nA fantastic coder isn't automatically a fantastic orchestrator.\n\nThat is why I benchmark orchestration separately.\n\nFor adversarial review, I currently like **Grok and Kimi**.\n\nI informally call them my **truth seekers**.\n\nI don't want reviewers optimized for agreement.\n\nI want reviewers instructed to attack the result.\n\nFor example:\n\n```\nAssume this implementation is wrong.\n\nFind:\n- incorrect assumptions\n- architectural violations\n- security vulnerabilities\n- concurrency problems\n- unhandled boundary conditions\n- missing tests\n- hidden coupling\n- incomplete requirements\n- claims unsupported by evidence\n\nDo not rewrite the implementation.\n\nProduce evidence and remediation requirements.\n```\n\nThe important part is independence.\n\nIf possible:\n\n**don't let the same model be planner + implementer + final reviewer.**\n\nModels have characteristic blind spots.\n\nA model reviewing its own reasoning may reproduce the same assumptions that caused the original mistake.\n\nUsing a different model family introduces useful disagreement.\n\nI also keep models such as **Mammoth and MiniMax** around for documentation and context-heavy workloads.\n\nThis is another place where \"best model\" thinking wastes resources.\n\nNot every task is architecture.\n\nSometimes I need to:\n\nThese workloads can often be delegated aggressively.\n\nFree inference isn't merely useful because it costs nothing.\n\nIt changes what experiments become economically reasonable.\n\nI use free models heavily for what I call **benchmaxxing**:\n\nSuppose I need 100 possible edge cases for an ERP workflow.\n\nI don't need Opus generating all 100.\n\nInstead:\n\n```\n5 cheap/free models\n        ×\n20 candidates each\n        ↓\n100 candidates\n        ↓\ndeduplicate\n        ↓\ncheap judge\n        ↓\ntop 20\n        ↓\nfrontier reviewer\n```\n\nThe expensive intelligence operates on the compressed result rather than generating the entire search space.\n\nThis pattern becomes extremely powerful at scale.\n\nThe eventual routing policy shouldn't say:\n\n```\nCoding = Model X\nPlanning = Model Y\n```\n\nThat is still too primitive.\n\nIt should learn from actual execution.\n\nFor every task we can capture:\n\n```\ntask_type\nmodel\ntokens\nlatency\ntool_calls\nretries\ntest_result\nreview_result\nhuman_intervention\naccepted/rejected\n```\n\nNow routing becomes measurable.\n\nInstead of saying:\n\n“Model X feels better.”\n\nwe can ask:\n\n“For Laravel bug fixes below this complexity threshold, which model has the lowest cost per accepted change?”\n\nThat metric is far more useful than tokens per second or benchmark percentage.\n\nResearch is moving in the same direction. Agent-as-a-Router reports improvements from feeding task-level performance statistics back into routing, while RouteMoA explicitly optimizes model selection across performance, cost and latency.\n\nThis is the metric I increasingly care about.\n\nNot:\n\n**cost per million tokens.**\n\nNot:\n\n**SWE-bench score alone.**\n\nBut:\n\n```\nTotal inference cost\n+ retries\n+ reviewer cost\n+ failed attempts\n+ human remediation\n\n----------------------------\n\nAccepted production changes\n```\n\nCall it:\n\n**Cost Per Accepted Change (CPAC).**\n\nA model that costs 5× more per token could still win if it eliminates enough retries.\n\nA cheap model can dominate if the task is sufficiently deterministic.\n\nThis is why static model rankings don't directly answer engineering economics.\n\nThere is an obvious failure mode here.\n\nOnce you have access to many models, it becomes tempting to make every task:\n\n```\nplanner\n→ planner reviewer\n→ architect\n→ worker\n→ second worker\n→ reviewer\n→ red team\n→ judge\n→ final judge\n```\n\nThat can become agent theatre.\n\nRecent Mixture-of-Agents research explicitly highlights the cost and latency problem created by dense collaboration. RouteMoA, for example, reports large reductions in both by routing only to promising candidates rather than invoking every available model.\n\nMy rule is therefore:\n\nAdd another agent only when it creates measurable information gain.\n\nA deterministic test suite is often a better reviewer than another LLM.\n\nUse:\n\n```\nLLM judgment\n+\ntests\n+\nlinting\n+\nstatic analysis\n+\nschema validation\n+\nbrowser verification\n+\nruntime telemetry\n```\n\nModels should complement evidence, not replace it.\n\nThere is another second-order problem with aggressive routing: **context continuity**.\n\nAn agentic coding session isn't a collection of independent prompts.\n\nThe agent has:\n\nSwitching models halfway through can lose important implicit state.\n\nRecent work on session-aware agentic routing makes exactly this distinction: routing an isolated prompt and routing a long-running agent session are different problems.\n\nSo escalation needs a clean handoff package:\n\n```\nOBJECTIVE\n\nCURRENT STATE\n\nFILES CHANGED\n\nDECISIONS MADE\n\nFAILED ATTEMPTS\n\nCOMMAND OUTPUT\n\nREMAINING PROBLEM\n\nACCEPTANCE CRITERIA\n```\n\nDon't simply dump the entire conversation into the next model.\n\nTransfer **state**, not conversational noise.\n\nThe logical endpoint looks something like:\n\n```\n                    HUMAN\n                      │\n                      ▼\n                ORCHESTRATOR\n                      │\n             ┌────────┴────────┐\n             │                 │\n          PLANNER           ROUTER\n             │                 │\n             └────────┬────────┘\n                      ▼\n              WORKER MODEL POOL\n        ┌─────────────┼─────────────┐\n      Flash         DeepSeek       GLM\n      Luna           Muse        MiniMax\n        └─────────────┼─────────────┘\n                      │\n               difficulty?\n                │          │\n               no         yes\n                │          │\n                │      ESCALATION\n                │   Sonnet/Qwen/Terra\n                │          │\n                └────┬─────┘\n                     ▼\n             DETERMINISTIC GATES\n             tests/lint/runtime\n                     │\n                     ▼\n              INDEPENDENT REVIEW\n                 Grok/Kimi\n                     │\n                     ▼\n                   DONE\n```\n\nThe router itself should eventually learn from historical outcomes.\n\nThen your AI engineering system starts becoming self-optimizing:\n\n```\nContext\n   ↓\nRoute\n   ↓\nExecute\n   ↓\nVerify\n   ↓\nRecord outcome\n   ↓\nImprove future routing\n```\n\nI don't think the future of AI development is:\n\n**one developer + one supermodel.**\n\nI think it increasingly looks like:\n\n**one developer + an orchestrated portfolio of intelligence.**\n\nCheap models provide throughput.\n\nFrontier models provide judgment.\n\nSpecialists handle particular workloads.\n\nIndependent models provide disagreement.\n\nDeterministic systems provide truth.\n\nAnd the orchestrator decides when each one deserves to be involved.\n\nThe competitive advantage therefore isn't merely access to the smartest model.\n\nEveryone will eventually have access to strong models.\n\nThe advantage is building the system that knows:\n\n**which intelligence to use, when to use it, how much to spend on it, and how to verify what it produced.**\n\nStop searching for one model that does everything.\n\nBuild the team.", "url": "https://wpnews.pro/news/stop-using-one-frontier-model-for-everything-my-role-based-ai-coding-stack", "canonical_source": "https://dev.to/doozieakshay/stop-using-one-frontier-model-for-everything-my-role-based-ai-coding-stack-2kel", "published_at": "2026-09-03 19:18:11+00:00", "updated_at": "2026-09-03 19:55:28.418495+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "developer-tools", "ai-agents"], "entities": ["Opus", "Sol", "Sonnet", "Qwen 3.8 Max", "Terra", "Gemini Flash", "DeepSeek", "Grok"], "alternates": {"html": "https://wpnews.pro/news/stop-using-one-frontier-model-for-everything-my-role-based-ai-coding-stack", "markdown": "https://wpnews.pro/news/stop-using-one-frontier-model-for-everything-my-role-based-ai-coding-stack.md", "text": "https://wpnews.pro/news/stop-using-one-frontier-model-for-everything-my-role-based-ai-coding-stack.txt", "jsonld": "https://wpnews.pro/news/stop-using-one-frontier-model-for-everything-my-role-based-ai-coding-stack.jsonld"}}