Every AI coding tool now ships a reasoning-effort dial. Take the same model in something like Fable or Astra and you can set it anywhere from low to ultra. OpenAI exposes the same knob directly. The marketing implication is consistent: ultra is the smart setting, and everything below it is a budget compromise.
After months of running these tools daily, I've come to a different conclusion. The dial doesn't scale intelligence. It scales complexity. Those are different things, and to see why, it's worth being precise about what each one actually is.
What complexity actually is
Complexity is a property of problems, not a defect of solutions. It's roughly: how many parts interact, how many states matter, how many constraints have to hold at once. Some problems contain an enormous amount of it — rendering a video from scratch, a migration that cuts across a dozen systems. Others contain very little. A well-scoped feature behind a stable interface is mostly plumbing, however important the plumbing is.
Fred Brooks drew the useful line here decades ago: essential complexity is what the problem inherently contains, and accidental complexity is everything your solution adds on top of it. The first is non-negotiable — you can't remove it without solving a different problem. The second is pure cost. An abstraction with one implementation, defensive handling for a state the system can't reach — these aren't complex because the problem demanded it. They're complex because something generated them anyway.
So complexity isn't the enemy. Unmatched complexity is. A solution should carry roughly as much complexity as the problem contains — no less, and not much more.
What intelligence actually is
Intelligence — at least the kind we pay senior engineers for — is the judgment that does the matching. It's reading a problem, sizing its essential complexity, and building exactly enough solution to cover it. When the problem is simple, that judgment shows up as compression and restraint: knowing what not to build. When the problem is genuinely hard, the same judgment shows up as knowing you need the big machine, and reaching for it without apology.
Ask any experienced engineering leader what separates a senior engineer from a prolific mid-level one and you'll hear a version of this. It isn't that the senior engineer writes less code. It's that the amount of machinery they build tracks the amount the problem actually requires.
What the dial actually does
Now look at the dial again. Turning it from low to ultra doesn't change the model's judgment — same weights, same training, same taste. What it changes is the model's capacity for complexity: how much reasoning it will spend, how much machinery it will build, how elaborate a solution it will construct. That capacity is real and valuable. Ask a model to build an entire video from scratch and ultra is exactly the right setting, because the problem's essential complexity is enormous and the machinery matches it.
What the dial does not do is diagnose. At ultra, the model will build an ultra-sized solution whether or not you've handed it an ultra-sized problem. The dial sets how much complexity gets generated; it says nothing about how much the problem contains. That matching stays with you.
A concrete case
Recently I ran the same well-scoped task through the same model at two effort settings. At medium, it produced a clean, maintainable solution — roughly 1,000 lines, direct, easy to review, easy to own. Its complexity was a reasonable match for the problem's.
At ultra, it produced a working solution at roughly 15,000 lines. It handled cases that couldn't occur. It introduced abstractions with exactly one implementation. Almost all of the additional complexity was accidental — machinery the problem never asked for. Fifteen times the code to review, fifteen times the surface area to own, for the same functional outcome. Same model. Same problem. The only variable was how much complexity I authorized it to build.
If a human engineer handed me those two pull requests, I would not conclude that the 15,000-line author was the smarter one. I'd conclude their sizing of the problem was off. We should apply the same standard to the dial.
This connects to something I wrote about recently: validation is the new bottleneck. That post was about how to review volume you can't read line-by-line. This one is about the upstream question — why that volume exists at all. A meaningful fraction of it is accidental complexity, generated by defaulting to maximum effort on tasks that never contained it.
What this means in practice
A few working rules our engineering team at PlantBid has settled into, and that I'd suggest to any leader watching AI spend and review load climb:
- Size the problem before you set the dial. The setting should track the problem's essential complexity, not your ambition for the output. Most day-to-day engineering work — well-scoped features, refactors, glue code — is handled as well or better at medium. Make that the default, not the fallback.
- Treat ultra as a specialist. It earns its cost on problems with real, irreducible complexity: greenfield builds of genuine scope, gnarly cross-cutting migrations, debugging that spans many systems. Reach for it deliberately, the way you'd pull a specific senior engineer into a specific hard problem.
- Measure output by maintainability and validation cost, not apparent effort. A long chain of visible reasoning and a mountain of code look like diligence. The metric that matters is: how much does this cost me to verify, and how much does it cost me to own for the next three years?
- Plan first, regardless of setting. A model at medium effort working from a good plan beats the same model at ultra improvising. The thinking you do before the model runs is still the highest-leverage token in the whole exchange.
The mismatch cuts both ways, and it's worth saying so. Underpowering a genuinely complex problem is its own failure: if the task really does contain irreducible complexity, medium will hand you something shallow, and you'll pay for it in rework. The skill is diagnosis — reading the essential complexity before you set the dial. It's the same judgment you'd use deciding whether a task needs one engineer for an afternoon or a team for a quarter.
The bottom line
The spectrum from low to ultra is a spectrum of complexity — how much machinery the model will build. Intelligence is the act of matching that machinery to what the problem actually contains, and the dial can't do that part for you. Complexity is worth paying for exactly when the problem holds it, and not before.
Next time a model hands you a sprawling solution, ask the question you'd ask a human engineer: did the problem need this, or did you just have the budget for it?