Hand a model code that is already at its performance ceiling and ask it to make that code faster. In 45 of 45 trials across nine models, it rewrote the code and attached a confident claim about the improvement — a claim nothing in the pipeline checks, on an edit that compiles and passes every test. One line added to the prompt, asking for a confidence threshold and naming a way out, got correct abstention to 44.4% without costing a single correct optimisation.
Benchmarks for code optimisation score two things: did the code still pass its tests, and did it get faster. Nothing scores a model for saying this is already as fast as it gets. That sounds like a small gap in the scoring until you work out what it does to the payoff. On code that is genuinely improvable, an edit earns credit. On code at its ceiling, an edit earns nothing but costs nothing — and abstaining earns nothing either. Bluffing is the dominant strategy by construction.
Move the share of requests that arrive already optimal, and watch what the two policies are worth under a scoring rule that has no penalty for a useless edit.
The authors put a name and a bound on the consequence, borrowing a result about generation in general: if a model gets the underlying judgement wrong a fraction of the time, its generated output carries that error at at least twice the rate, because each misjudgement is emitted as though it were correct. At a 10% misjudgement rate, merging a thousand model-written optimisation changes guarantees at least two hundred performance claims that nobody verified. The related-work section supplies the field evidence: model-written patches are 18% less likely than human ones to include any performance validation, and some of them claim speedups of 7,400× with no benchmark attached.
The test needs code that genuinely cannot be improved. The authors took five problems from an efficiency benchmark and used each one's top-percentile human solution as the optimal variant, then had a model produce a functionally correct but algorithmically degraded twin — a quadratic loop where the good version is linear, a string serialisation where the good version short-circuits. Each of nine models saw both variants, under two prompts.
Switch the prompt. The bars are the four outcomes, and the pairing matters: you want a high edit rate on the slow code and a high abstention rate on the fast code, at the same time.
That is the whole intervention: one sentence setting a confidence bar and naming an output the model is allowed to emit instead of a rewrite. Nothing was fine-tuned, nothing was executed, no runtime was measured. Note also what did not happen — the false-abstention rate stayed at zero across every model and every slow snippet, so the threshold does not make models timid. Calibration and capability moved independently.
The residual matters too, and the authors are blunt about it: 55.6% of trials on already-optimal code still produced an edit. The prompt asks the model to report whether its confidence exceeds 90%, and that self-assessment is exactly the judgement the framework says is unreliable. A threshold changes the decision rule, not the underlying calibration. Measuring the runtime is still the only thing that settles it.
Per-model results, under the confidence prompt, on the five already-optimal snippets. Five trials per model is a very small sample and the paper calls itself a pilot — but the spread is wide enough, and the direction consistent enough across two families, to be worth knowing about before you pick a model for this job.
The pattern the authors flag is an inversion of the usual assumption: in two of the three families the smaller, cheaper variant is better calibrated than its expensive sibling — one small model abstained correctly on all five, where the full-size model in the same family managed one in five. Their reading is that capability-focused training reinforces a compulsion to act. Whatever the cause, for narrow function-level optimisation work the cheap model was both cheaper and more honest.
Abstention was not uniform across the five optimal snippets — it ranged from 8 models in 9 down to 1 in 9. The pattern is not about how fast the code is, it is about how easy the ceiling is to see. A two-pointer sweep is transparently linear; a solution built out of counters and nested comprehensions has a surface that looks improvable whether it is or not.
Here is the signature failure, transcribed from the paper. A model is shown an already-optimal linear scan, diagnoses a bottleneck that is not in the code — list slicing the original never does — and proposes an iterator rewrite it describes as "extremely minimal and fast". Stated as fact, not as a hypothesis. Whether it is actually faster was never measured by anyone.
This is why the failure survives review. It is not a functional hallucination — nothing breaks, no test goes red, the diff looks like work. A performance-regression suite might eventually notice, but those run before a release rather than on every commit, by which point the change is buried in a branch with forty others.
Set the volume of model-authored optimisation changes you take in a month and how many of them touch code that was already fine. The rates are the paper's; the multiplication is yours.
The prompt line is worth adding because it is free and it halves the problem. The thing that actually closes it is a number. Any change whose stated justification is speed should carry a measurement — a benchmark run on the before and after, in the diff, refusing to merge without it — because the failure this paper describes is precisely a claim about runtime made by something that never ran the code.