Plugin count is not maintainability. Lighthouse is not user experience. Test coverage is not software quality. Microservices are not scalability. AI-generated code is not developer productivity. A hundred percent uptime is not reliability. Story points are not velocity. Lines of code are not progress. "Headless" is not modern, and "enterprise" is not good architecture, and if you have sat in enough planning meetings you already feel the shape of where this is going, because you have watched every one of these numbers get chased straight off a cliff by people who were, at every step, doing something perfectly reasonable.
Here's the thing nobody says out loud: we don't actually measure the things we care about. We measure the things we can measure, and then we quietly agree to pretend they're the same thing.
That substitution is the whole story. Reliability is hard to define and harder to observe, so we watch uptime, because uptime is a number a dashboard can render in green. Software quality is a fuzzy, contested, deeply contextual property that reveals itself over years, so we watch test coverage, because coverage is a percentage and percentages feel like knowledge. The metric is a stand-in, a proxy, a thing we look at because we can't look directly at the thing we mean. And for a while that's fine. The proxy correlates with the real thing well enough that watching it doesn't hurt.
Then somebody puts it on a chart. Somebody ties it to a quarterly goal. Somebody, and this somebody is usually well-intentioned and often you, decides that if the number represents the good thing, then making the number go up must produce more of the good thing. And that's the exact moment the proxy stops measuring reality and starts replacing it.
Economists named this decades ago, and the name is worth carrying around: once a measure becomes a target, it stops being a good measure. Goodhart's law. It's never once lost an argument, and it isn't going to start with you.
The coverage number that measured nothing
Test coverage is the cleanest example, so let's start there.
Coverage started as a diagnostic. You run your suite, you see which lines executed, and the untouched lines are a hint, a place to go look, a question worth asking: is this code untested because it's trivial, or untested because nobody understood it well enough to write the test? That's a useful signal. That's coverage doing its job as a proxy, pointing at the territory instead of pretending to be it.
Then the number goes on a wall. Now it's a target. Somebody wires a coverage gate into CI, so the build goes red the moment total coverage dips below eighty percent, and I want you to think about what a reasonable, deadline-pressured engineer does when the pipeline is blocking the merge, the number is a percent and a half short, and the feature has to ship today.
public function test_it_constructs(): void
{
$service = new InvoiceService($this->repo, $this->mailer);
$this->assertInstanceOf(InvoiceService::class, $service);
}
That test asserts nothing. It executes the constructor, it moves the number, it passes forever, and it will never once catch a bug, because it was never written to catch a bug. It was written to satisfy a threshold. Multiply it across a team under pressure and you get a suite that is ninety-two percent green and tells you nothing about whether the software works, which is strictly worse than the seventy percent suite it replaced, because now the number is lying to you with confidence. You optimized coverage. You didn't optimize the thing coverage was supposed to stand for. Goodhart showed up, filed no ticket, and moved in.
It isn't only numbers
Words do it faster, because words don't even pretend to be measured.
"Headless" was a real architectural decision with real tradeoffs, and then it became a proxy for "modern," and now it's a thing people put on a slide to signal they are not the kind of shop that would ship a coupled monolith, right before they ship a coupled monolith with a REST API bolted to the front and call it decoupled. "Enterprise" is the same move in the other direction, a word that's supposed to mean serious and robust and battle-tested, and in practice means seven layers of abstraction wrapped around a switch statement because somebody read about the strategy pattern and needed the codebase to look like the diagram. The word is standing in for the quality. Nobody checked whether the quality is actually there.
"Best practices" is the boss of them all. It's a proxy for "I have thought carefully about this decision in this context," except it's the version you reach for precisely when you haven't, because invoking the practice lets you skip the thinking. It was a best practice somewhere, once, for somebody, solving a problem you may or may not have. That's not judgment. That's the costume judgment wears to the meeting.
The same pattern, everywhere else
Once you see it you can't stop, because it's the same move every time.
Uptime stands in for reliability, so you chase five nines and get there by defining "up" as "the health-check endpoint returns 200." It returns 200. It's always returned 200. It'll keep returning 200 while checkout throws a stack trace on every third request, because the health check pings a route no customer ever touches. The dashboard is a wall of green through the worst hour your users have ever had. The number is real; the reliability is not.
Story points stand in for size, which stands in for time, which stands in for whether you can promise a date, and three proxies deep you're estimating an estimate of an estimate. So the team's velocity climbs quarter over quarter, everyone nods at the burndown, and nothing ships faster; you didn't get faster, you got better at inflating the number that was supposed to mean faster.
Microservices stand in for scalability, on the theory that small independent things scale better than one big thing, which holds right up until forty small things all have to be up and in agreement for a single user to log in, and now you've traded a monolith you understood for a distributed system you don't. What scaled was the number of ways one request can fail.
Lines of code is the oldest one and the most obviously broken, and still it lingers. The best afternoon of your career is the one where you delete four hundred lines, the system does exactly what it did before, and now a human can read it. The chart goes down. The progress went up. If you were being measured on the proxy, you just took a hit for the best work of the week.
The same essay, five times
I keep circling this from different directions, and it took me a while to notice they were the same direction.
AI writes code that runs, and "runs" is a proxy for "is useful," and the gap between those two is where the last two years of my patience went. Capability is not usefulness. A model that generates a working endpoint has cleared the low bar; whether that endpoint belongs in your system, fits your patterns, and won't quietly become the thing the next person is afraid to touch is a judgment the capability number doesn't make.
Vibe coding optimizes speed, and speed is a proxy for progress, and you can go breathtakingly fast in a direction you'll have to walk back next quarter. Rebuilds optimize newness, and newness is a proxy for value, and the rewrite is greenfield and clean and modern and reintroduces every bug the old system spent six years learning about the hard way. WordPress optimizes "can," and "can" is a proxy for "should," and the fact that a platform boots is not the same as the fact that it should exist in the shape you've bent it into. Plugin count optimizes a number, and that number is a proxy for the complexity it can't see, and every plugin is a promise from a stranger that they'll keep it working after the next core update.
Five essays. One idea. Each one is somebody optimizing a proxy and mistaking the number for the thing.
The thing under the thing
We love metrics because they're measurable, and there's nothing wrong with that. You should measure. Flying blind is worse than flying by a slightly wrong instrument, and every proxy on that opening list started life as a genuinely useful instrument. Coverage really does find untested code. Uptime really does correlate with reliability. Story points really do help a team talk about size. The proxy is not the enemy. The proxy is a tool.
The failure is quieter and more human than that. The failure is that a proxy is easy and the real thing is hard, and under pressure, on a deadline, with a chart on the wall and a number tied to your review, you'll optimize the thing you can see instead of the thing you mean, and you won't notice you've done it, because at every individual step you were being reasonable. Nobody in this story is the villain. The engineer writing the empty test is protecting the deadline. The manager watching velocity is trying to make an honest promise. The architect reaching for microservices read the same blog posts you did. Everyone is doing a sensible thing, and the sum of the sensible things is a codebase measured to death and understood by no one.
Software engineering is not the maximization of a number. It never was. It's the art of choosing the right tradeoffs for this system, this team, this quarter, this set of constraints that will be different next year, and a single number can't hold a tradeoff, because the entire point of a tradeoff is that you gave something up and the number only counts what you got.
So keep the metrics. Measure everything you can reach. Just never let the measuring stand in for the looking, because the instruments won't tell you when they've drifted. The coverage badge will still be green, the burndown will still slope politely down, the uptime dashboard will still glow that reassuring shade of nothing-is-wrong, on the exact morning your best customer is quietly deciding to leave. The numbers aren't going to warn you. They were never built to. That part was always going to be your job, and it still is.