The current AI coding discussion spends too much time asking which model is “best.”
I think that framing is already becoming obsolete.
There 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.
Why should every stage use the same model?
My current approach is to treat models like members of an engineering organization:
ORCHESTRATOR
Sol
│
┌─────────┴─────────┐
│ │
PLANNER REVIEW
Opus Grok / Kimi
│ Truth Seekers
│
┌──────┴──────┐
│ │
WORKERS ESCALATION
Gemini Flash Sonnet
DeepSeek Qwen 3.8 Max
GLM Terra
Luna
Muse
MiniMax
│
▼
Tests / CI / deterministic validation
The principle is simple:
Use the cheapest model that can reliably complete the task, escalate when necessary, and independently review important outputs.
This 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.
1. Workers: Optimize for Throughput
My worker pool currently includes:
- Gemini Flash
- DeepSeek
- GLM
- Luna
- Muse
- MiniMax
Workers receive bounded tasks.
Examples:
Implement this validated plan.
Add tests for these acceptance criteria.
Refactor these three classes without changing behavior.
Trace this exception to its originating call.
Generate fixtures covering these boundary conditions.
Inspect this module and report deviations from the specification.
This distinction matters.
I don't necessarily want a worker deciding the architecture while simultaneously implementing it.
The architecture may already have been decided upstream.
The worker's job is execution.
This lets me optimize worker selection for:
- speed
- cost
- tool-use reliability
- instruction adherence
- coding ability
- context handling
rather than demanding maximum intelligence on every call.
2. Escalation: Don't Pay Frontier Prices by Default
My next tier currently includes:
Sonnet, Qwen 3.8 Max and Terra.
These become useful when the worker encounters something that actually requires stronger reasoning.
For example:
Worker attempt #1
│
▼
Tests fail
│
▼
Worker remediation
│
▼
Same failure / low confidence?
│
YES
▼
Escalate
│
▼
Sonnet / Qwen / Terra
The key idea is that failure itself becomes a routing signal.
A simple task shouldn't start at the most expensive model merely because it might become difficult.
Start cheap.
Observe.
Escalate.
This is also where model-routing research is heading: routing can incorporate execution feedback rather than relying entirely on static task classification.
3. Planning Is a Separate Capability
My preferred planner is currently Opus.
Planning deserves its own model because a bad plan has multiplicative consequences.
Imagine spawning ten extremely capable workers against an incorrect architecture.
You haven't improved productivity.
You've parallelized the mistake.
A planner should establish:
- objective
- constraints
- affected components
- architecture
- dependencies
- implementation sequence
- acceptance criteria
- rollback considerations
- verification strategy
Only then does execution begin.
For complex work, I increasingly prefer:
Requirement
↓
Opus
↓
Plan
↓
Plan review
↓
Workers
rather than:
Requirement
↓
Huge coding model
↓
"Go build everything"
The second approach looks agentic.
The first is much easier to govern.
4. Orchestration Is Not the Same as Planning
This distinction became increasingly obvious to me while using different frontier models.
My current favorite orchestrator is Sol.
The planner answers:
How should we solve this problem?
The orchestrator answers:
What should happen next?
Those are different responsibilities.
A good orchestrator must continuously reason about system state:
Goal
│
├── Task A → Worker 1
├── Task B → Worker 2
└── Task C → Worker 3
│
▼
failure
│
retry or escalate?
│
▼
specialist
│
▼
review
It must decide:
- what can execute in parallel
- what has dependencies
- what needs additional context
- which model should receive which task
- whether an agent is genuinely progressing
- when retries have diminishing returns
- when to escalate
- when to request review
- when the objective is actually complete
A fantastic coder isn't automatically a fantastic orchestrator.
That is why I benchmark orchestration separately.
5. The Truth-Seeker Lane
For adversarial review, I currently like Grok and Kimi.
I informally call them my truth seekers.
I don't want reviewers optimized for agreement.
I want reviewers instructed to attack the result.
For example:
Assume this implementation is wrong.
Find:
- incorrect assumptions
- architectural violations
- security vulnerabilities
- concurrency problems
- unhandled boundary conditions
- missing tests
- hidden coupling
- incomplete requirements
- claims unsupported by evidence
Do not rewrite the implementation.
Produce evidence and remediation requirements.
The important part is independence.
If possible:
don't let the same model be planner + implementer + final reviewer.
Models have characteristic blind spots.
A model reviewing its own reasoning may reproduce the same assumptions that caused the original mistake.
Using a different model family introduces useful disagreement.
6. Specialists Still Matter
I also keep models such as Mammoth and MiniMax around for documentation and context-heavy workloads.
This is another place where "best model" thinking wastes resources.
Not every task is architecture.
Sometimes I need to:
- synthesize repository documentation
- classify thousands of records
- generate structured test data
- summarize execution logs
- transform specifications
- produce synthetic datasets
- extract knowledge
- generate evaluation cases
These workloads can often be delegated aggressively.
7. Free Models Are an Engineering Resource
Free inference isn't merely useful because it costs nothing.
It changes what experiments become economically reasonable.
I use free models heavily for what I call benchmaxxing:
- synthetic datasets
- test datasets
- prompt experiments
- regression evaluations
- model comparisons
- adversarial cases
- parallel candidate generation
- disposable research agents
Suppose I need 100 possible edge cases for an ERP workflow.
I don't need Opus generating all 100.
Instead:
5 cheap/free models
×
20 candidates each
↓
100 candidates
↓
deduplicate
↓
cheap judge
↓
top 20
↓
frontier reviewer
The expensive intelligence operates on the compressed result rather than generating the entire search space.
This pattern becomes extremely powerful at scale.
8. Route by Evidence, Not Brand
The eventual routing policy shouldn't say:
Coding = Model X
Planning = Model Y
That is still too primitive.
It should learn from actual execution.
For every task we can capture:
task_type
model
tokens
latency
tool_calls
retries
test_result
review_result
human_intervention
accepted/rejected
Now routing becomes measurable.
Instead of saying:
“Model X feels better.”
we can ask:
“For Laravel bug fixes below this complexity threshold, which model has the lowest cost per accepted change?”
That metric is far more useful than tokens per second or benchmark percentage.
Research 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.
9. Cost Per Accepted Change
This is the metric I increasingly care about.
Not:
cost per million tokens.
Not:
SWE-bench score alone.
But:
Total inference cost
+ retries
+ reviewer cost
+ failed attempts
+ human remediation
----------------------------
Accepted production changes
Call it:
Cost Per Accepted Change (CPAC).
A model that costs 5× more per token could still win if it eliminates enough retries.
A cheap model can dominate if the task is sufficiently deterministic.
This is why static model rankings don't directly answer engineering economics.
10. Avoid the Multi-Agent Trap
There is an obvious failure mode here.
Once you have access to many models, it becomes tempting to make every task:
planner
→ planner reviewer
→ architect
→ worker
→ second worker
→ reviewer
→ red team
→ judge
→ final judge
That can become agent theatre.
Recent 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.
My rule is therefore:
Add another agent only when it creates measurable information gain.
A deterministic test suite is often a better reviewer than another LLM.
Use:
LLM judgment
+
tests
+
linting
+
static analysis
+
schema validation
+
browser verification
+
runtime telemetry
Models should complement evidence, not replace it.
11. Context Makes Switching Models Harder
There is another second-order problem with aggressive routing: context continuity.
An agentic coding session isn't a collection of independent prompts.
The agent has:
- inspected files
- executed commands
- accumulated hypotheses
- encountered failures
- modified code
- received tool output
Switching models halfway through can lose important implicit state.
Recent work on session-aware agentic routing makes exactly this distinction: routing an isolated prompt and routing a long-running agent session are different problems.
So escalation needs a clean handoff package:
OBJECTIVE
CURRENT STATE
FILES CHANGED
DECISIONS MADE
FAILED ATTEMPTS
COMMAND OUTPUT
REMAINING PROBLEM
ACCEPTANCE CRITERIA
Don't simply dump the entire conversation into the next model.
Transfer state, not conversational noise.
12. The Architecture I'm Moving Toward
The logical endpoint looks something like:
HUMAN
│
▼
ORCHESTRATOR
│
┌────────┴────────┐
│ │
PLANNER ROUTER
│ │
└────────┬────────┘
▼
WORKER MODEL POOL
┌─────────────┼─────────────┐
Flash DeepSeek GLM
Luna Muse MiniMax
└─────────────┼─────────────┘
│
difficulty?
│ │
no yes
│ │
│ ESCALATION
│ Sonnet/Qwen/Terra
│ │
└────┬─────┘
▼
DETERMINISTIC GATES
tests/lint/runtime
│
▼
INDEPENDENT REVIEW
Grok/Kimi
│
▼
DONE
The router itself should eventually learn from historical outcomes.
Then your AI engineering system starts becoming self-optimizing:
Context
↓
Route
↓
Execute
↓
Verify
↓
Record outcome
↓
Improve future routing
The Bigger Point
I don't think the future of AI development is:
one developer + one supermodel.
I think it increasingly looks like:
one developer + an orchestrated portfolio of intelligence.
Cheap models provide throughput.
Frontier models provide judgment.
Specialists handle particular workloads.
Independent models provide disagreement.
Deterministic systems provide truth.
And the orchestrator decides when each one deserves to be involved.
The competitive advantage therefore isn't merely access to the smartest model.
Everyone will eventually have access to strong models.
The advantage is building the system that knows:
which intelligence to use, when to use it, how much to spend on it, and how to verify what it produced.
Stop searching for one model that does everything.
Build the team.
Top comments (0)