The Number Goes Up. The Work Goes Sideways.

You put a number on a dashboard. Your team hits it. And somehow the thing you actually wanted got worse. That gap between the metric and the goal is the story this week, showing up in AI tools, model headlines, and org charts. Let me catch you up.

The bounty that bred cobras

British officials in Delhi paid a bounty for dead cobras. People started breeding cobras to cash in. When the program ended, the breeders set their snakes loose, and the city had more cobras than when it started. Piyush Bhatia uses that story to explain what just happened at Amazon and Meta with AI tools.

Amazon built a leaderboard called KiroRank to push engineers onto its AI coding tools. It rewarded token consumption, which is easy to count. So engineers ran pointless AI tasks to climb the board. They called it tokenmaxxing. On May 29, 2026, Amazon killed the leaderboard and switched to counting code that actually ships. Meta ran its own tracker across 85,000 employees who burned 60 trillion tokens in 30 days before it got shut down too.

The pattern has a name older than any of this. In 1975, Charles Goodhart put it plainly: when a measure becomes a target, it stops being a good measure. Wells Fargo employees opened 3.5 million fake accounts to hit quotas and ate $3 billion in fines. Same shape, different costume.

The headline that shrinks as it spreads

Some numbers get less true the more people share them. "A 26-billion-parameter model runs in 2GB" is one. Mia Efoxtech traced the real story behind Gemma 4 26B, and the 2GB figure is real but narrow. It measures resident model weights plus a 4K cache. The full install still takes 14.3GB on SSD, and the machine still needs 8GB of system memory.

That gap matters when you plan a roadmap on it. Local speed sounds free until you check throughput. At 5.1 tokens per second on an M2 Air, producing four million tokens takes about 9.1 uninterrupted days, before failures and restarts. Meanwhile Google lists the same model free on its Gemini API today, which torpedoes the "local saves money" case.

The move for your team: never let a shareable number stand in for a decision. Ask what it actually measures, then price the whole thing, hardware, engineering, retries, and review, against the accepted task.

When the auditor flatters itself

Here is the twist that should stick with you. Aastha Joshi built ThirdLine, an AI system to audit other AI agents, and pointed it at itself. The headline result looked great: 100% recall, every planted defect caught. Then precision fell to 38.5% on a real model run. Eight false alarms for five real defects.

Worse, she caught herself citing 55% precision in her own first headline. That number was the F1 score, not precision. Actual precision was 38.5%. She called it exactly what it was: the kind of flattering metric substitution an audit system exists to prevent, done by the person who built it.

High recall hid low precision. In a real queue, false alarms burn reviewer time and teach people to ignore the tool. Her fix is worth stealing: her system fails its own audit and prints "Requires Review" when it falls short. She trusts that result most.

Maps that make the mess feel fine

There is an org version of this too. John Cutler describes a business where eight teams span eight product hierarchies with competing goals, unclear ownership, and split reporting lines. A consultant friend put it this way: "I found myself constantly surprised: You're doing what? Why? For who? Who made that call?"

His warning is the part leaders miss. A company can get very good at documenting dependencies, translating between groups, and hiring fixers who know which office to visit. Those things lower the daily pain enough that nobody fixes the real problem underneath. Insiders navigating a mess does not make the mess coherent. It just means navigation became a specialized skill.

And AI will not save you here. It can surface the conflicting maps and even flag where they clash, but it cannot make conflicting goals and definitions line up. When it smooths over the contradictions, it produces the look of alignment while the tension stays.

The deep cut

Before you put any KPI on a dashboard, ask the one question Bhatia leaves you with: if someone cared only about making this number rise, what would they do? Then design around the answer.

The practical build is three layers, not one. A decision metric that already prices in the harm you want to avoid, so an email campaign that earns $10,000 but loses 300 subscribers at $35 each shows up as negative $500 and gets killed. Guardrail metrics like latency and errors that kill the launch if they break, no matter what the top number says. And usage metrics kept as diagnostics only, never as targets. Netflix ran four versions over two years before one reliably predicted 90-day retention. A metric that never gets revisited is a cobra bounty waiting to happen.

Three questions for your team

• Pick your top team KPI. What is the cheapest way someone could move that number without doing the real work? If you can answer fast, you have a gaming problem.
• Which of your "good" numbers might be hiding a bad one, the way 100% recall hid 38.5% precision? Pair every headline metric with the guardrail it could be masking.
• Where in your org do you pay fixers and translators to navigate a mess instead of fixing it? Name one boundary where the maps stopped lining up, and decide if it is worth refactoring this quarter.