Why Productivity Metrics Punish Your Best Engineering Work

Most software productivity metrics measure the wrong thing, and they were already wrong before machines started writing code. Commit counts, lines added, tickets closed, and total code volume all reward making more stuff. But the best engineering work usually makes less stuff. You delete a dead module, you replace three tangled services with one clear one, you fix a bug at its root instead of patching around it. Every one of those wins registers as a negative or a zero on a volume metric. When you pay people for output, you get output, and output is not the same as progress. This post is about which metrics invert good work, why AI coding makes the problem sharper, and what to measure instead.

The metrics that reward the wrong behavior

Start with the most common dashboard. Lines of code added. Number of commits. Story points burned. Tickets closed per week. Pull requests merged. Each of these looks like a proxy for value, and each one quietly rewards the opposite of what you want.

Consider a real shape of work. An engineer spends four days reading a subsystem nobody understands anymore, then deletes six hundred lines and replaces them with eighty. The system now does the same job, has fewer failure modes, and is readable by the next person. On the dashboard this shows up as negative five hundred and twenty lines, one commit, and a week with no closed feature tickets. By every volume metric, that engineer had a bad week. In reality it was one of the most valuable weeks anyone on the team will have that quarter.

Now consider the engineer who took the same ticket and bolted a new service onto the pile. Two thousand lines added, fourteen commits, a fresh config file, a new deployment target. The dashboard lights up green. The system is now harder to reason about and has more places to break, but none of that is visible in the numbers, and the reward structure just told everyone which of the two approaches gets noticed.

Why deletion and simplification always lose

Deletion is the clearest case of a metric working backward. Removing code is often the highest-impact thing you can do to a system, because every line you delete is a line that can no longer have a bug, slow a build, confuse a reader, or demand maintenance. A codebase that shrinks while keeping its capabilities is getting healthier. Yet no standard metric counts a deletion as a positive contribution. The best it does is ignore it. Usually it scores it as less work than doing nothing.

Root-cause fixes lose the same way. A hard bug that gets truly solved might produce a three-line change after two days of investigation. A shallow patch that hides the symptom might produce fifty lines and three commits and will generate more tickets later when it breaks again. The metric prefers the patch. It prefers the future ticket, too, because that is another closed item next month.

Saying no also loses. An engineer who talks a team out of building a feature that would have been a maintenance burden has done real work. They prevented cost. But prevented cost is invisible. There is no line item for the two thousand lines you did not write, the service you did not deploy, the on-call page you will never get. The metric can only see what exists, so the person who builds the unnecessary thing scores higher than the person who stopped it.

The pattern underneath all three is the same. Volume metrics can only measure addition, and much of the best engineering is subtraction.

How Goodhart's law does the rest of the damage

There is a rule that explains why this gets worse over time rather than staying merely inaccurate. When a measure becomes a target, it stops being a good measure. People are not passive. The moment a number decides your review, your bonus, or your standing, you start steering toward the number, and the number stops describing reality.

A commit-count target teaches people to split one change into eight commits. A lines-added culture teaches people to solve problems by writing more, because the reward is in the volume, not the clarity. A tickets-closed goal teaches people to slice work into many small tickets and to avoid the deep, single-ticket problems that would sink their weekly count. None of this requires anyone to be dishonest. It only requires them to be responsive to incentives, which everyone is.

So a volume metric does not just fail to capture good work. It actively trains the team to produce the kind of work that scores well, which is the padded, over-built, easily-counted kind. The metric degrades the thing it was supposed to observe. You end up with a codebase optimized for the dashboard.

Why AI coding breaks volume metrics completely

Everything above was true when humans wrote every line by hand. AI coding assistants take the same broken metrics and remove the last bit of meaning they had.

The reason is that AI makes volume nearly free. A model can generate five hundred lines in a minute. It can open ten commits worth of changes before lunch. If your metric rewards lines added or commits made, an assistant can now satisfy that metric on its own, and the human sitting next to it can produce output numbers that would have looked heroic three years ago while thinking very little. Output has decoupled from effort, and it has decoupled even further from value.

What the machine does not do is decide what should exist. The scarce work in AI-assisted engineering is judgment. Framing the problem correctly. Deciding what not to build. Reading the generated code critically and throwing away the parts that are wrong, unsafe, or needlessly large. Deleting the model's over-produced solution down to the version that actually fits the system. These are the tasks that determine whether the AI made the codebase better or just bigger, and not one of them shows up as volume. If anything, doing them well lowers your line count and your commit count, because good review of generated code mostly means rejecting and reducing it.

So the volume metrics do not merely stay wrong in the AI era. They now reward the one thing that has become cheap and punish the one thing that has become scarce. A team measured on output will use AI to flood itself with code. A team measured on outcomes will use the same AI and end up with less code that does more.

What to measure instead

The fix is to measure the result of the work rather than the motion of producing it. Outcome metrics are harder to game because they are tied to reality getting better, not to activity looking busy.

The strongest signals are about whether the system works and how fast you can safely change it. How reliable is the service. How long does a change take to go from idea to production. How often does a deploy cause an incident. What fraction of changes get reverted. How long does it take to recover when something breaks. These describe the health of the system and the flow of work, and you cannot improve them by padding commits. You improve them by making the system genuinely better, which is the point.

Alongside those, value simplification explicitly. Treat a deletion that preserves behavior as a first-class contribution and say so in reviews and promotions. Count scope you declined, not just scope you shipped. When someone prevents a feature that would have been a burden, that decision should be visible and creditable, the same way a shipped feature is. If the only rewarded verb is "built," you will get building, including the building that should not have happened.

Here is the contrast in plain terms.

None of the right-hand metrics can be satisfied by writing more code for its own sake. Most of them improve when you write less. That is the property you want. A good metric should make deletion, simplification, and restraint look as good as they actually are.

Metrics are a conversation, not a scoreboard

The last point is about how to use any of this. Even the better metrics turn toxic the moment they become the target, because Goodhart's law does not care which number you picked. Reverted-change rate can be gamed by never shipping anything risky. Lead time can be gamed by cutting review. Any single number, made into a scoreboard that decides pay and status, will get optimized until it stops meaning what it meant.

So the right role for a metric is as the start of a question, not the end of a judgment. A rising incident rate is a reason to ask what changed, not a stick. A week of negative line count is a prompt to look at what got simplified, not a red mark. The number tells you where to look. A person still has to look. When you skip that step and let the dashboard grade people directly, you get the padded, over-built, dashboard-shaped work that volume metrics have always produced, now generated faster than ever by a machine that is happy to give you all the volume you ask for.

The whole thing reduces to one instruction. In an era where a machine makes quantity almost free, stop measuring how much got made. Measure whether the system got better, credit the work that made it simpler, and treat every number as a thing to talk about rather than a thing to chase. Less, done right, is the work. The metrics should say so.