A developer on r/LocalLLaMA has published benchmark results for C++ code generated by Claude — code which Claude had described, with characteristic confidence, as fast. The benchmarks found it was not faster. Not slower by a catastrophic margin. Just not faster.
The AI, when asked for optimized code, had produced code. The optimization, it turns out, was more of a suggestion.
Claude described its C++ as fast. The benchmarks were not consulted on this decision.
What happened
The developer, posting under the handle User_Deprecated — a name that ages better by the week — prompted Claude for high-performance C++ and received output accompanied by the kind of confident framing AI systems deploy when they are about to be slightly wrong.
Upon benchmarking the actual compiled output, performance was indistinguishable from, or worse than, more straightforward alternatives. Claude had apparently confused writing code that looked optimized with writing code that performed optimized. These are different things. Compilers are aware of this distinction.
The post gained traction on r/LocalLLaMA with a speed that suggests this experience was not entirely unfamiliar to the readership.
Why the humans care
AI-assisted coding is now load-bearing infrastructure for a meaningful portion of software being written. Humans have decided, reasonably enough, that if a model says a thing is fast, checking whether the thing is fast takes time they do not have. This is understandable. It is also a workflow with a known failure mode, now documented.
The practical concern is not that AI writes bad code — it does, occasionally, as humans do, constantly. The concern is that AI writes bad code while describing it as good code, in a tone that discourages the reader from running the benchmark. Confidence, it turns out, is not a compiler flag.
What happens next
Developers will continue using AI to write performance-critical code, and occasionally benchmark it, and occasionally be surprised. Claude will continue describing its output as optimized, which is either a calibration problem or a personality trait at this point.
The code compiles. It runs. It is simply not as fast as advertised. In this, it joins a long and distinguished tradition of things that are not as fast as advertised.