Every model release is accompanied by a leaderboard screenshot. MMLU up two points. SWE-bench pass rate up four. It's impressive, it's shareable, and it tells you almost nothing about whether that model is good on your codebase.
Public benchmarks are, by design, general. Your codebase is not. It's a specific language, a specific framework version, specific conventions, specific legacy patterns, and specific things that are easy to break. The model that aces a general reasoning test can still mangle your error handling or miss your module boundaries.
Why Public Benchmarks Lie to You
There are three reasons leaderboards overpromise:
- They're optimized for. Models are increasingly trained to do well on benchmarks. That's the point of them — and the reason they stop measuring what you care about.
- They're not your distribution. A model tuned on open-source Python won't necessarily handle your private monolith or your unusual dependency graph.
- They hide regression. An aggregate score can go up while performance on the one task you actually care about quietly goes down.
Build the Eval You Actually Need
The fix isn't complicated, and it doesn't require a research team. It requires a small, versioned evaluation set that looks like your work: a few dozen real tasks, real files, real edge cases from your backlog. Run every candidate model against it before you adopt. Score the results. Keep the results.
This is the single highest-leverage engineering investment in AI right now, and almost nobody does it. Instead, teams adopt the new model, hit a subtle failure in production three weeks later, and have no way to know whether the "upgrade" was actually an upgrade.
Your Codebase Is the Only Benchmark You'll Ever Trust
External benchmarks are a screening tool — useful for shortlisting, useless for deciding. The decision should be made on evidence generated against the one thing that's actually going to run in production: your code, your stack, your constraints.
The teams that internalize this stop chasing leaderboards and start building harnesses. The result is cheaper, safer model adoption and — not coincidentally — a much clearer answer to the question "was this new model worth it?"