The model is a dial
Frontier models changed the useful abstraction level of prompting.
The stronger the model becomes, the less value there is in narrating every turn of the route. The leverage moves upward: define the destination, specify the evidence, state what failure looks like, and make the review boundary explicit.
That does not mean prompts should become vague. It means precision belongs in the outcome contract, not in a speculative list of keystrokes.
AI-assisted: This page was developed with AI as an accelerator. The thesis, framing, and final approval remain human decisions.
The second shift follows from the first. Model selection is not a prestige ladder. It is . Spend deeper where ambiguity, failure cost, synthesis, or time horizon require it. Use the smallest sufficient profile everywhere else.
Prompting moved up an abstraction layer
Early prompt engineering often treated the prompt as a route description. Open a file. Find a function. Add a branch. Run a command. Return a summary.
That structure can still help with deterministic or brittle work. It is also a low abstraction level. The person writing it must predict the implementation path before the model has inspected the environment. Every route decision embedded in the prompt becomes a decision the model cannot improve without first disobeying the prompt.
A brief moves one level up. It defines the goal, constraints, and acceptance criteria, then leaves the route open. An outcome contract moves higher again. It defines not only what should exist, but also how the result earns trust.
Route explanation
Explains the route step by step, so the prompt owns the method and the model follows it.
- Open this file
- Change this line
- Run this command
The shift is from route precision to outcome precision.
Route precision says which steps to take. Outcome precision says what must be true when the work is finished. A capable model can search, inspect, test, and revise its route. It cannot infer an unstated audience, an invisible failure condition, or who has authority to approve the result.
Those remain contract work.
An outcome contract is not an outcome wish
"Build a polished page" is an outcome-shaped sentence, but it is not a contract. It has no evidence standard, no boundary, and no definition of failure. The model can produce something that looks complete while leaving every important judgment unresolved.
A useful outcome contract carries six fields.
- Result. The observable thing that must exist.
- Audience. The person or system the result must serve.
- Constraints. The boundaries the route cannot cross.
- Evidence. The tests, sources, measurements, or artefacts that prove the result.
- Failure conditions. The states that must block completion, even if the output looks plausible.
- Review gate. The person or independent process that can accept the work.
Here is the compact template.
outcome_contract:
result: "What must exist when the work is finished"
audience: "Who or what must be able to use it"
constraints:
- "A boundary the route cannot cross"
evidence:
- "A test, source, measurement, or inspectable artefact"
failure_conditions:
- "A state that blocks completion"
review_gate: "The independent check or human approval required"
Notice what is missing: a compulsory implementation transcript. The model still needs relevant context, references, and interfaces, but it can choose the route after inspecting them. You define what earns acceptance. It works backwards from that acceptance state.
This is the freedom of a tight brief. The model has room to solve the path because the destination does not move.
Model choice is effort allocation
Once the prompt is an outcome contract, model choice becomes easier to reason about. You are no longer asking which model is best in the abstract. You are asking how much cognitive and operational effort this contract needs.
Four variables do most of the work.
Path ambiguity
How many viable routes exist, and how much discovery must happen before one can be chosen?
A known transformation over a known file has low path ambiguity. A cross-system architecture decision has high path ambiguity. High ambiguity pays for synthesis because the route itself is part of the problem.
Failure cost
What happens if the result is wrong?
A reversible draft can tolerate a cheap first pass. A destructive migration, public claim, or production decision needs a more cautious profile. Failure cost is not the same as task size. A one-line change can carry a large blast radius.
Time horizon
How long must the model preserve intent across decisions?
A single-turn transformation has a short horizon. A build that inspects, edits, tests, diagnoses, and revises has a longer one. Long-horizon work consumes more of the and benefits from stronger state management, whether that comes from the model, the surrounding files, or both.
Reviewability
How quickly can another process detect a bad result and reverse it?
Strong tests and clean diffs lower the effort required for an initial attempt because mistakes surface cheaply. Weak observability raises the required effort. If a result cannot be reviewed, the model has to carry more of the assurance burden before acting.
Operating profile, not a universal ranking.
The profiles in the matrix are operating shorthand.
| Profile | Useful shape |
|---|---|
| Haiku with light effort | Bounded, reversible, short-horizon work with a clear check |
| Sonnet with standard effort | Moderate synthesis, familiar implementation, and visible review evidence |
| Opus with deep effort | Ambiguous synthesis, high failure cost, or decisions that shape a long chain of work |
| Codex with high effort | Tool-led implementation where repository inspection, code changes, and verification dominate |
This is not a universal ranking, and it does not claim literal equivalence between providers. Haiku, Sonnet, Opus, and Codex name useful working profiles here. The right profile depends on the contract and the environment around it.
The model is only one control
A model picker compresses several separate decisions into one brand name. That is operationally weak because changing the model is not the only way to change capability.
You can change the . You can provide a larger or tighter context. You can grant tools. You can persist state across turns. You can require a fresh audit or human approval.
These controls are orthogonal.
A high-effort model with no evidence can spend more producing a slower guess. A lighter model with a narrow contract, relevant files, deterministic tools, and a strong review gate can outperform it on the actual outcome.
This is why model selection should happen after contract design. The contract tells you what kind of uncertainty remains. The surrounding controls tell you which uncertainty the model must carry itself.
A practical allocation method
Use this sequence before choosing a model.
Define acceptance first. Write the result, audience, evidence, failure conditions, and review gate before discussing the route.
Classify the uncertainty. Separate uncertainty about the destination from uncertainty about the path. Destination uncertainty is a briefing problem. Path uncertainty is a reasoning problem.
Price failure. Ask what a plausible but wrong result would cost. Include reversal cost, public exposure, data loss, and downstream work built on the decision.
Inspect the environment. Count the useful context, tools, tests, and checkpoints already available. A furnished environment reduces the amount the model must invent or remember.
Choose the smallest sufficient profile. Start with the lowest effort that can carry the remaining ambiguity and failure cost. Raise it when the contract demands more, not because a larger model is available.
Spend review separately. Model effort and review effort solve different problems. Deeper reasoning reduces some errors before action. Independent review catches errors the same reasoning process cannot see.
The result is a system that can dial effort up without leaving every control at maximum. That matters because excess effort has a cost in , tokens, attention, and throughput.
Common failure modes
Maximum effort as a default
This spends time on tasks whose route and check are already obvious. It also hides weak contracts because the model appears busy. If the acceptance state is vague, more reasoning does not make it precise.
Model choice before contract design
Picking the model first encourages post-hoc justification. Define the work, then allocate the profile. Otherwise every task mysteriously grows to fit the most prestigious option.
Outcome language without evidence
Replacing steps with a vague destination removes useful structure without adding assurance. An outcome contract needs evidence and failure conditions. Without them, it is only a wish with a heading.
One control standing in for the whole system
Changing the model cannot compensate for missing context, absent tools, no persistence, or a weak review gate. Treat those as separate controls so each can solve the problem it actually owns.
The rule
Explain less of the route. Define more of the outcome.
Then choose the smallest sufficient effort for the ambiguity and failure cost that remain.
The model is a dial. The contract is the control surface.
Source note
The model names on this page label operating profiles drawn from practical use. They are not benchmark claims, a provider ranking, or a claim that the models are equivalent. The allocation method is based on task ambiguity, failure cost, time horizon, and reviewability.