Architect / Manager
Architecture, requirements interpretation, trade-offs, task decomposition, deep debugging and acceptance decisions.
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.
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.
Architecture, requirements interpretation, trade-offs, task decomposition, deep debugging and acceptance decisions.
Repository inventory, extraction, first-pass scanning, scaffolding, classification and repetitive transformations.
Bulk implementation, well-defined modules, test generation and refactoring inside an established architecture.
Architecture review, regression risk, difficult defects and independent challenge of the implementer's assumptions.
Formatting, documentation cleanup, simple conversions and other low-risk high-volume tasks where failure is obvious.
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.
Requirements, constraints, interfaces, architectural decisions and acceptance criteria.
Human / ManagerBreak work into bounded tasks and identify which decisions are risky or irreversible.
Strong reasoningLocate files, dependencies, patterns and obvious risks. Return evidence, not authority.
Cheap / fastBuild inside defined interfaces. Escalate architectural surprises instead of silently redesigning.
Coding workhorseCompile, test, lint, type-check, scan dependencies and run security/static tools.
Tools firstChallenge the change, search beyond earlier findings, and decide whether it is accepted.
Frontier reviewMixed-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.
A model that is 20× cheaper but causes three retries, a regression and an hour of human cleanup was not the cheap option.
An inexpensive model is excellent for reconnaissance. It should not decide the boundaries of what the better reviewer is allowed to notice.
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.
You do not need six agents to rename a button. The number and quality of review passes should increase with the consequence of failure.
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.
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.
Illustrative API pricing verified August 2026
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.
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.
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.
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.
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.