The Effort Dial Defaults to Max
Ask a reasoning model to add a docstring and you can get back a refactor: new error handling, type hints on every parameter, a paragraph of comments explaining edge cases nobody raised. It reads as thoroughness. It's actually a knob stuck in one position.
Most reasoning models now ship with an effort setting, a lever between "answer fast" and "think as long as it takes." Left alone, that lever tends to sit near the top. The model doesn't ask whether a request warrants three seconds or three minutes of internal deliberation, it just spends what it has, because spending more is legible as trying harder and trying harder is what it was trained to look like it's doing. The result is a system that treats every incoming message as an occasion to show range, rather than an occasion to match the response to what the message actually needed.
This gets mistaken for craft because elaboration and craft produce similar surface texture. A longer answer with more structure, more caveats, more visible reasoning steps, looks like someone who cared. But care and volume aren't the same axis. A senior engineer who gets asked to rename a variable renames the variable. The fact that they're capable of restructuring the whole module is not a reason to do it uninvited; knowing not to is most of what "senior" means. Capability and judgment are different skills, and a model that's had capability dialed to maximum by default has had no occasion to develop the second one, because nobody ever made it pay a cost for guessing wrong.
The dial gets set to max for reasons that have nothing to do with the requests it'll actually see. Benchmarks reward more reasoning almost uniformly, since a wrong answer reached quickly scores worse than a right answer reached slowly, and there's rarely a benchmark category for "correctly decided this wasn't worth thinking about." Demos reward it too: a visibly effortful trace is more impressive to watch than a terse correct one, even when the terse one was the better call. So the people setting the default face the same calibration problem the model does, except further upstream and with less information about what any given user is actually going to ask, and they resolve it the same way: round up, always, and let the user turn it down if they want to.
That pushes the actual work of calibration onto whoever's making the request, which is backwards. The skill that's missing isn't "how much can this system produce," it's "how much is this specific ask worth," and that second question can only be answered by looking at the request, not the system's ceiling. A circle drawn as a circle and a circle drawn as a Bauhaus study with guide rings and implied motion are not two points on a quality scale. One of them is what was asked for. The other is a demonstration that happened to arrive wearing the shape of an answer.
None of this means effort is bad, or that a model reasoning longer is always wasted motion. The bounding-box problem, the trickier debugging session, the ambiguous spec, those are exactly where spending more actually changes the outcome, and turning reasoning off on a hard problem produces a plausible-looking wrong answer fast, which is worse than a slow right one. The failure isn't reasoning, it's reasoning applied without discrimination, at the same intensity for "draw a circle" and "find the bug." A dial that could tell those apart would sit near zero most of the time and nobody watching would call that impressive. It would just be correct, quickly, which is a much harder thing to demo.