Travis MacDonald
AI Engineering • September 12, 2026

Stop Using One AI for Everything.

← All ideas

A practical mixed-model workflow for software development: route cheap models to volume work, strong coding models to implementation, and frontier models to decisions where judgment actually matters.

My rule is simple: spend cheap tokens on volume. Spend expensive tokens on judgment.

01 / The premise

The best model should not do every job.

Most AI-assisted development workflows still act as if one model should plan the feature, read the repository, generate boilerplate, implement business logic, hunt for bugs, review its own work, and write the documentation.

I use a different approach: mixed-model development. The model is not “the developer.” It is a worker inside a pipeline. Different classes of work are routed to different capability tiers, and the expensive intelligence is reserved for decisions where a mistake is costly.

Architect / Manager

GPT-5.6 Sol class

Architecture, requirements interpretation, trade-offs, task decomposition, deep debugging and acceptance decisions.

Scout / Preprocessor

DeepSeek V4 Flash class

Repository inventory, extraction, first-pass scanning, scaffolding, classification and repetitive transformations.

Implementation Workhorse

DeepSeek V4 Pro class

Bulk implementation, well-defined modules, test generation and refactoring inside an established architecture.

Independent Reviewer

Frontier model

Architecture review, regression risk, difficult defects and independent challenge of the implementer's assumptions.

Utility Worker

GPT-5.6 Luna / low-cost tier

Formatting, documentation cleanup, simple conversions and other low-risk high-volume tasks where failure is obvious.

02 / Workflow

Route work by consequence, not prestige.

The roles are more important than the model names. Models will change. Prices will change. The durable architecture is the sequence of responsibility: establish truth, plan, scout, implement, verify, review, then accept.

01

Establish truth

Requirements, constraints, interfaces, architectural decisions and acceptance criteria.

Human / Manager
02

Plan & decompose

Break work into bounded tasks and identify which decisions are risky or irreversible.

Strong reasoning
03

Scout & map

Locate files, dependencies, patterns and obvious risks. Return evidence, not authority.

Cheap / fast
04

Implement

Build inside defined interfaces. Escalate architectural surprises instead of silently redesigning.

Coding workhorse
05

Deterministic checks

Compile, test, lint, type-check, scan dependencies and run security/static tools.

Tools first
06

Independent review

Challenge the change, search beyond earlier findings, and decide whether it is accepted.

Frontier review
03 / Trade-offs

What you gain — and what you take on.

Mixed-model development is not free efficiency. You exchange raw token cost for orchestration complexity. The approach works best when those handoffs are explicit, bounded and measurable.

+

Advantages

  • Lower inference cost by moving volume away from frontier models.
  • Higher throughput through cheap parallel reconnaissance and implementation.
  • Frontier reasoning remains available for architecture and dangerous decisions.
  • Independent model families can expose different blind spots during review.
  • Smaller task-specific context packages reduce distraction and wasted context.
  • Providers can be swapped without redesigning the entire engineering process.
−

Costs & risks

  • Routing and orchestration become engineering problems of their own.
  • Poor handoffs can strip away context the next worker actually needs.
  • Parallel agents can create conflicting implementations or duplicated work.
  • Cheap scans can generate false positives — and more dangerously, false negatives.
  • Without canonical project truth, agents can gradually pull the system in different directions.
  • Optimizing only for token price can be a false economy if review and rework explode.

The system should optimize for the cost of a correct outcome — not the price of a token.

A model that is 20× cheaper but causes three retries, a regression and an hour of human cleanup was not the cheap option.

04 / Auditing

Never let the cheapest model become the gatekeeper.

An inexpensive model is excellent for reconnaissance. It should not decide the boundaries of what the better reviewer is allowed to notice.

0
Deterministic toolsTests, compiler, type checker, linting, dependency and static security scans.
1
Cheap reconnaissanceBroad sweep. Produce structured findings with evidence, location and confidence.
2
TriageValidate, deduplicate and cluster findings. Remove obvious noise.
3
Independent deep reviewRead the evidence, but independently search for issues the earlier pass missed.
4
Fix & verifyApply patches, rerun tests, inspect regressions and require explicit acceptance.

The false-negative problem

If a cheap scanner finds A, B and C, then the frontier reviewer is told to “review A, B and C,” the system can become very good at confirming what it already knows — while completely missing vulnerability D.

The first pass should make the final reviewer faster, not define the limits of its search.

The earlier scan identified the attached possible issues. Validate them, but treat the report only as supporting evidence. Perform an independent review and specifically search for important problems the earlier analysis failed to identify.
05 / Escalation

Capability should rise with risk.

You do not need six agents to rename a button. The number and quality of review passes should increase with the consequence of failure.

Formatting
cheap tier
CRUD / UI
workhorse
Core logic
strong + review
Data migration
frontier
Auth / security
frontier + tools

Escalate by consequence.

Routine failures can return to the implementation model. Authentication, customer data, concurrency, public APIs and irreversible migrations deserve a more skeptical review path.

My routing rule: use the least expensive workflow that keeps the expected cost of failure acceptably low.

06 / Economics

The price spread is real. Fake precision is optional.

Current model pricing is wide enough to justify routing without inventing a magical “annual AI cost” for a hypothetical codebase. Measure your own accepted-task cost instead.

Standard output price per 1M tokens

Illustrative API pricing verified August 2026

bar length ∝ price
GPT-5.6 Sol
$30.00
GPT-5.6 Terra
$15.00
GPT-5.6 Luna
$6.00
DeepSeek V4 Pro
$0.87
DeepSeek V4 Flash
$0.28
Output pricing alone is not a quality ranking and is not a complete workload cost. Real code workflows also incur input-context costs, cache behavior, tool calls, retries and reasoning overhead. Current provider pricing can change; see the official references below.
Cost per accepted taskNot just cost per request.
Retries per taskCheap failures compound.
Escaped defectsWhat review still missed.
Human interventionTime is part of cost.
Cache hit rateStable prefixes matter.
07 / Context

Context is infrastructure.

Every model does not need every historical conversation. A bounded task package should contain the current truth, relevant code, constraints and success criteria — not months of abandoned ideas.

The project sits above the models.

An implementation model can propose a better interface. A reviewer can propose an architectural correction. A scout can flag a suspicious dependency. None of those should silently become canonical project state.

Agents consume the current truth, produce work, and return proposed changes. A manager — human or AI — decides what gets promoted back into canonical state.

AI output is a proposal until something accepts it.
08 / Review

Don't make the implementer grade its own exam.

A separately prompted reviewer — and sometimes a different model family — gives the system a chance to challenge the framing that produced the code in the first place.

A stronger pattern is Model A implements → deterministic tests run → Model B reviews → manager adjudicates.

The end goal

The point is not to use more models. It is to build better software.

Mixed-model development is useful because it creates separation of responsibility. The scout gathers evidence. The architect decides. The builder implements. Automated tools verify what they can. The reviewer challenges the result. The manager decides what becomes truth.

That resembles the mechanisms we already use to keep human engineering teams reliable: specialization, code review, testing, escalation, written decisions and controlled ownership. AI simply makes it possible for a solo developer to reproduce more of that structure.

The better question is no longer “Which model should I use?”
It is: “Which model should be allowed to make this decision?”

Sources & current pricing references

  1. OpenAI — GPT-5.6: Frontier intelligence that scales with your ambition.
  2. OpenAI — API pricing.
  3. OpenAI — How GPT-5.6 fuses frontier intelligence with frontier efficiency.
  4. DeepSeek — Models & Pricing.
  5. DeepSeek — Context Caching.

Model names and prices in this article are examples based on provider information available in August 2026. Providers can change pricing, model availability, limits and capabilities. The workflow principles are intentionally model-agnostic.