Shares an approach to dividing work among AI agents: use the strongest model for requirements and design, assign well-defined implementation and routine review to other models, and compare independent designs to reduce path dependence.
When using AI agents to develop software, which task most needs a more capable model: design, planning, writing code, or review? The intuitive approach is to generate code with a cheaper model and let the strongest model check it afterward. But if the initial direction is wrong, the final review may not rescue the solution.
The original author takes the opposite approach: use the best model for requirements and design, then reduce the cost of subsequent stages according to how clearly the tasks are defined and how easily their results can be verified.
Start with the conclusion: invest capability in key decisions
The article's argument has three parts:
- Establish the direction first. Use the best model for understanding requirements and designing the solution.
- Constrain execution next. Lower-cost models become more suitable once interfaces, change scope, and acceptance criteria are clear.
- Compare earlier. To benefit from multiple models, have them design independently before comparing their differences, rather than adding a review only after implementation.
Why late review struggles to correct the direction
AI models have a troublesome characteristic: they are good at continuing along an existing direction, but less good at throwing it out entirely.
Suppose a weaker model produces a design, and a stronger model reviews it. The stronger model can usually find problems: an overlooked exception, poorly divided interfaces, or a module that needs more tests. It offers plenty of useful suggestions and makes the original design more complete.
But it rarely returns to the original requirements, disregards the design in front of it, and rethinks how the problem should be solved. The existing design sets the boundaries, and review often becomes an exercise in filling gaps within them. Even a highly capable model can end up producing a carefully improved mediocre design.
This is not necessarily just a tendency to agree. When we hand a model a document and ask it to review it, the task itself implies that the document is broadly sound and that the model should find its problems. The modules, concepts, and technical direction in the original design become the starting point for its reasoning, making it hard to reconsider them as just another candidate solution.
Software development also has considerable inertia. A misunderstanding of the requirements gets expanded during planning. A wrong design direction leads the implementation model to diligently write code within the wrong structure. Once code, tests, and documentation exist, the whole solution increasingly looks like the result of thorough consideration. A stronger model brought in at that point faces more than a mistaken idea: it faces a collection of mutually reinforcing context.
That is why earlier mistakes cost more. Requirements and design may not produce much code, but they determine where all the subsequent code should go. Using the best model there may yield more value than finding a few extra bugs at the end.
Allocate models according to task uncertainty
The requirements stage presents an open-ended problem. The model has to determine what the user actually wants to solve, which remarks are merely casual examples, and which unstated constraints still need consideration. It also has to choose among fundamentally different approaches. These judgments are difficult to capture in a complete checklist.
During implementation, the problem gradually becomes concrete. Which interface to implement, which files to modify, and which tests to satisfy are usually clearer. Even if the model makes a mistake, compilers, type systems, unit tests, and CI can help catch it. A midrange model that understands the design correctly can often finish the work.
Routine code review has an even narrower scope. Does the implementation follow the design? Is error handling missing? Do tests cover boundary cases? These questions have relatively clear criteria. The reviewing model does not have to understand the entire world afresh; it can check the requirements, design, and code item by item. The task certainly requires ability, but may not warrant the most expensive model.
The following table organizes the article's argument; it does not prescribe fixed model tiers:
| Stage | Main judgment | Allocation approach | Reviewable output |
|---|---|---|---|
| Requirements | Actual problem, unstated constraints, and scope | Prioritize a capable model suited to the task | Goals, constraints, and acceptance criteria |
| Design | Technical direction, module boundaries, and tradeoffs | Maintain substantial reasoning effort; generate independent candidates when useful | Designs, assumptions, and reasons for tradeoffs |
| Implementation | Deliver changes against a clear design | Consider a midrange model when design and verification are sufficient | Code, type checks, and test results |
| Routine review | Conformance to requirements and overlooked boundaries | Choose capability according to risk, rather than cost alone | Evidence of defects and unverified issues |
From this perspective, model capability should not be allocated according to workload. Writing code may consume eighty percent of the time without necessarily requiring eighty percent of the intelligence. The decisions that most need a good model are those with many possible choices, difficult verification, and consequences for all subsequent work if the wrong choice is made.
How human and model review differ
Traditional software teams do involve senior engineers in requirements and architectural design. Still, much of the day-to-day development is done by ordinary engineers and reviewed by more senior colleagues. We trust an experienced reviewer to do more than inspect formatting. They have their own experience and judgment, and when the direction is wrong, they can say directly: stop making changes; this solution needs to be redone.
A human reviewer also does not readily treat existing code as an unquestionable premise. They know that code is one solution someone produced within a limited time, and they are responsible for the outcome after it is merged. If starting over is more worthwhile, they have sufficient motivation and authority to do so.
Models are different. They do not have independent judgment developed through long-term involvement in the project, nor do they truly bear responsibility for what happens after a merge. Asked to review, they try hard to play the role of a reviewer. That role usually means improving the current solution rather than pretending it does not exist and designing again from scratch.
Traditional teams can therefore place senior people later in the workflow to correct its direction. An AI workflow cannot rely too heavily on the final review to rescue all the directional mistakes made earlier. If the strongest model arrives only at the end, it may have missed the stage where it could have contributed most.
Generate designs independently, then compare disagreements
A common approach is to use models in combination: model A writes the code, then model B reviews it. Their habits and blind spots are not identical, so this can indeed uncover additional problems and appears to create a form of opposition between them.
But if B sees code that A has already written, it is still drawn into the structure A chose. It may dislike an interface, find an omission, or propose a better implementation, yet rarely revisit why the system was divided that way in the first place. Switching models can reduce shared blind spots without removing the path dependence created by existing work.
If I am willing to pay for two models, I think it is more worthwhile to put that opposition in the design stage. Give A and B the same original requirements and let each produce a design without knowing the other's answer. Do not have A design first and then hand its result to B for review; B will still reason within the boundaries A established. Two isolated contexts create the opportunity for two genuinely different solutions.
Once both designs are complete, compare and combine them. Areas of agreement are usually relatively reliable, while substantial disagreements deserve further questions. Did the models interpret the requirements differently? Did they rely on unstated assumptions? Or does one approach simply fit a particular model's habits better? The strongest model can make the final comparison, or a person can decide the tradeoffs.
The key is not necessarily to use models from two different vendors. It is to ensure independent thinking before introducing disagreement. Different models can increase diversity of thought, but if one sees the other's answer from the beginning, even diverse models can become repairers of an existing solution. Generating answers separately and comparing them afterward puts the extra model capability where it can influence the direction.
Apply the idea to a development task
When resources are limited, rather than letting a cheap model choose a path and asking the best model to check it after substantial progress, let the best model decide which way to go at the start. The later work, with its clear objectives and straightforward verification, can be left to other models.
The following sequence is this blog's practical addition:
- State the original requirements. Record goals, scope, known constraints, and acceptance criteria without treating a particular technical solution as a requirement.
- Review design assumptions first. Require reasons for important choices. If significant disagreements remain, generate candidate designs in independent contexts.
- Make implementation verifiable. Specify interfaces, change scope, and verification methods before deciding whether a lower-cost model is suitable.
- Review according to risk. Check routine issues against requirements. Bring stronger judgment back into the process when critical boundaries or unverified assumptions are involved.
Discussion
Support the author