Every few weeks, another frontier AI model drops. GPT-something new, Claude whatever-next, Gemini 4-point-something. And every time, engineering teams across the world do the same thing: they stop what they're doing, pull up the leaderboard, argue about MMLU scores, run a few quick tests, write up a comparison doc, and then... keep evaluating.
Their competitors ship.
I've watched this pattern destroy momentum at companies I've led and companies I've advised. The engineering team spends three weeks building a model evaluation framework. By the time the framework is done, two new models have dropped and the whole comparison is stale. Meanwhile, a smaller team with a "good enough" model has shipped a working product, gathered real user feedback, and started iterating.
The benchmark obsession is a real problem. And it's getting worse.
The Benchmarks Are Broken
Here's something the leaderboards don't advertise: the benchmarks don't mean what you think they mean.
MMLU and GSM8K are two of the most widely cited tests for AI model quality. Top frontier models now score 91%+ on MMLU and 94%+ on GSM8K. At those numbers, the scores tell you nothing. You cannot differentiate between models. You're looking at a ranking table where everyone is tied at the top.
According to research on benchmark saturation, roughly 45% of benchmark data overlaps with model training sets. Models aren't demonstrating capability. They're demonstrating memory.
The clearest proof: researchers tested GPT-4 by hiding answer choices in MMLU questions. A model with no prior exposure should guess the right answer about 25% of the time... by pure chance. GPT-4 guessed correctly 57% of the time. More than double chance. The model had memorised the test.
This is Goodhart's Law in practice. When a measure becomes a target, it ceases to be a good measure. AI labs optimise their models to score well on benchmarks, not to be genuinely more useful. The leaderboard is, in many cases, a marketing document.
In March 2026, MIT Technology Review ran a piece on exactly this problem. Their conclusion: standard benchmarks test narrow, idealised scenarios. Enterprise use cases are not idealised scenarios.
The Number Your Team Should Actually See
Here's a real-world result worth paying attention to.
One organisation switched to an AI model with a benchmark score 3% higher than its predecessor. Their customer support escalations went up 12%.
Read it again. Better benchmark score. Worse product outcome.
This is the real-world gap. In medical AI research, models showed a 20% performance drop with genuinely unseen test images. Training never saw those images, so the model never learned the task... only the test set.
The problem isn't unique to AI. I've seen software teams spend months choosing a database because one scored better on a synthetic workload benchmark... then deploy it to production where the benchmark metric was completely irrelevant to their actual query patterns. The benchmark answer was technically correct. The business decision was wrong.
What You Lose While You Benchmark
The loss from endless evaluation isn't visible on any project tracker. Nobody writes "competitor gained 400 users while we compared leaderboards" in the sprint retrospective.
Every week of evaluation is a week without user feedback. Every week without user feedback is a week you're making product decisions blind. Your competitor who shipped the "good enough" version three weeks ago has already fixed the things your benchmark wouldn't have surfaced anyway.
I've been in rooms where engineering teams spent six weeks building a comprehensive model evaluation framework. Rigorous testing. Multiple dimensions. Proper statistical analysis. By the time the framework was complete, the model in first place had dropped six weeks earlier and was already on its second version. The framework arrived outdated before anyone acted on it.
The irony: the evaluation process itself was well-engineered. The problem was the belief a benchmark score would tell them something their own production data wouldn't.
The One Benchmark Worth Running
Fortune has written about how Salesforce handled this. Instead of relying on academic benchmarks, they built internal evals for CRM-specific tasks... prospecting, lead nurturing, account management. The generic MMLU score told them nothing. Their own eval told them everything.
You don't need Salesforce's budget to do this.
Pick 50 real examples from your production data or your intended use case. Be specific. If you're building a code review tool, use 50 real pull requests. If you're building a customer support bot, use 50 real support tickets. If you're automating a data extraction workflow, use 50 real documents.
Write a scoring rubric for each example. What does "correct" look like? What does "acceptable" look like? What's a failure?
Run every model candidate against your 50 cases. Score them.
You'll learn more in four hours than you would in four weeks of benchmark research. And you'll learn things the benchmarks genuinely won't tell you: how the model handles your edge cases, your specific formatting requirements, your domain language.
Build your own eval. It's the only benchmark worth running.
A Note on Precision vs Direction
There's a legitimate version of careful model evaluation. If you're embedding AI into a regulated product... medical, legal, financial... you need rigorous testing before you ship. This isn't benchmark obsession. It's proper due diligence.
Most teams aren't in regulated industries. Most teams are building SaaS tools, internal workflows, or developer tooling where the appropriate quality bar is "does it work well enough to get user feedback?" and the appropriate evaluation method is "ship a working prototype and see."
The benchmark comparison taking two engineers three weeks to build is almost never the right tool for this decision. A working prototype with real users is.
How I Think About Model Selection Now
After years of watching this pattern, here's my current approach.
Start with a shortlist. The major frontier models from Anthropic, OpenAI, and Google are all capable for most use cases. Pick two or three based on price, API terms, and any hard constraints like data residency, context window, or latency requirements. This takes an afternoon, not a sprint.
Build your own eval. Fifty real examples, a simple rubric, four hours. Run your shortlist against it. Pick the best performer.
Ship it. Get real users on it.
Iterate. Your users will surface the failure modes the benchmark wouldn't have. Fix those. Run your eval again with new examples from production. Repeat.
This isn't "move fast and break things." It's moving at the speed your learning requires. You learn from users. You don't learn from benchmarks.
The Best Benchmark Score Doesn't Win
The AI labs will keep releasing models. The benchmark tables will keep updating. Someone will always hold the highest MMLU score this week and lose it next week.
None of this matters to your users. Your users care whether the product does the job.
Ship something. Make it better. The only eval worth running is the one your users run for you.
What's stopping you from shipping the "good enough" version today?