The Measurement Problem

There are two consensus positions on measuring developer output, and they contradict each other.

The first says lines of code are garbage. Counting lines rewards verbosity, punishes deletion, and turns engineers into typists. Anyone who has watched a LOC-incentivized team pad a codebase knows the critique is earned.

The second position is quieter but more widespread: track net lines anyway. Most dashboards, most "AI productivity" reports, most internal velocity reviews boil down to net growth - how much bigger did the codebase get this sprint. The same people who say LOC is garbage will nod along at a chart of net lines added.

Both positions break down when a team works AI-augmented. We measured a client engineering team we advised through fifteen days of AI-augmented development - every PR, adds and removes - and the data contradicts both camps. Not because lines suddenly measure quality. They don't. But because the right combination of line metrics is the only telemetry you already have, and it reads cleanly once you stop asking it the wrong question.

Three numbers, one diff

Every diff carries three measurements. Most teams look at one.

Absolute lines - adds plus removes. A PR with +4,000/-3,000 is 7,000 absolute lines. This is the closest thing in the repo to cognitive throughput: every added line and every removed line is a decision somebody - human or model - made and somebody reviewed. Absolute measures how hard the engine is turning.

Net lines - adds minus removes. The same PR is +1,000 net. Net measures codebase growth: how much more code exists than before. Useful, but it tells you nothing about effort. A +1,000 net PR could be 1,000 absolute lines of greenfield or 7,000 absolute lines of restructuring.

Add/remove ratio - adds divided by removes. The same PR runs about 1.3:1. The ratio is a phase indicator: a high ratio means the team is mostly building new surface; a ratio near 1:1 means the team is reshaping what exists. The ratio says nothing about quality and nothing about speed. It tells you what kind of work is happening.

The car analogy holds up better than it should. Absolute is the tachometer - how hard the engine is working. Net is the speedometer - ground covered. Ratio is the gear indicator. Reading any one of them alone, you will misjudge the car. A high-revving engine at low ground speed isn't a broken car; it's a car in a low gear, climbing.

Absolute is the tachometer. Net is the speedometer. Ratio is the gear. Read one without the others and you will misjudge the engine.

The data

The numbers below are real PR data from a client engineering team we advised - a small B2B SaaS team working AI-augmented through a stretch that included a feature burst, a consolidation pass, and a multi-tenancy rework. Dates are anonymized to phase windows.

Fifteen days. 48,163 absolute lines. 19,430 net. Sustained throughput of roughly 3,000-4,000 absolute lines per day across every phase - feature burst and consolidation alike.

Two rows bracket the window deliberately. The monolith conversion before it is net negative - nearly five thousand lines removed - and it is the single PR that made the feature burst possible. The 3.5:1 PR after the window shows the cycle restarting: consolidation finished, building resumed.

Constant developer, variable direction

Here is the finding the single-metric views miss.

The team's absolute throughput barely moved. Roughly 3,000-4,000 absolute lines per day during the feature burst. Roughly the same during consolidation. The engine ran at a constant rate for fifteen straight days.

What moved was the ratio. During the burst it climbed from 2.5:1 to 4.8:1 - overwhelmingly adds, new surface area, feature velocity. Then it dropped to 1.5-1.8:1 - heavy adds and heavy removes, the team reshaping what it had just built, paying down the structural debt the burst created, and reworking the platform for multi-tenancy.

Same developers. Same tools. Same daily effort, to within the noise. Only the direction changed.

The developer was constant. The direction was the variable. Most measurement systems have it backwards - they assume the work type is constant and the developer is the variable.

This is the specific failure mode of net-only tracking. Look at the table through a net lens: the best feature-burst PR landed +5,438 net; the deepest consolidation PR landed +1,613. A net dashboard reports a 70% productivity collapse. The metric made the work look worse, not better. But the consolidation PRs carried comparable or higher absolute throughput than the burst PRs - 7,901 and 10,457 absolute lines against the burst's 3,673-8,278. The team didn't slow down. It downshifted to climb.

The monolith conversion makes the same point at the extreme: net -4,813. Net-only tracking scores the most leveraged engineering work of the whole period as worse than doing nothing.

What "LOC is garbage" gets wrong

The standard rebuttal to all of this is to stop counting lines entirely. We think that critique is aimed at the right villain and the wrong tool.

LOC is garbage as an individual performance target. The moment a line count decides someone's review, Goodhart's law takes over and the metric is dead - engineers will generate volume, and AI tools will happily generate it for them. Nothing in this piece argues otherwise.

But "don't make it a target" and "don't measure it" are different conclusions. Adds and removes per PR are sitting in your git log right now, free, complete, and unfakeable in aggregate at the team level. Discarding them because one reading of one metric was abused leaves you with the alternatives most teams actually use - gut feel, story points, and survey data - none of which would have told you what the table above tells you.

It also leaves you unable to interrogate the headline research. The most-cited study of 2025 found experienced developers were slower with AI assistance - measured by task completion time. Maybe so, for that workflow on those repos. But task-time studies and net dashboards share a blind spot: neither can distinguish a slow developer from a fast developer in a reshaping phase. A team at 1.5:1 with 10,000 absolute lines in a window looks, to both instruments, like a team that lost a week. The three metrics together show the opposite: a constant engine in a different gear.

Low ratio plus high absolute is not a slowdown. It is the same engine in a different gear - and it is the gear that makes the next burst possible.

Reading the three together

The combinations are the diagnostic, not any single number:

• High absolute, high ratio (3:1+) - building. New features, new surface. Expect this to accumulate structural debt; budget for the next phase.
• High absolute, low ratio (under 2:1) - reshaping. Consolidation, refactoring, platform rework. This is forward motion that net charts report as stalling.
• High absolute, net negative - preparation. Deletion-heavy restructuring that makes future work cheap. The most undervalued row in any git log.
• Low absolute, any ratio - the only genuine slowdown signal in the set. When the tachometer drops, ask why. When only the speedometer drops, check the gear first.

Three cautions before you operationalize this. First, keep it at team level - the moment any of these numbers attaches to an individual's review, you've rebuilt the original LOC mistake with better vocabulary. Second, don't target the ratio; it's telemetry, not a goal, and a team told to "get the ratio up" will simply stop deleting code. Third, the ratio indicates work phase, not quality - a 4.8:1 burst can be excellent work or careless work, and the line counts won't tell you which. They tell you what kind of work is happening and whether the engine is actually turning.

A claim you can test this week: pull adds and removes per PR from your own git log for the last quarter. If your team works with AI assistance, we'd expect the same shape - absolute throughput far steadier than net, and the ratio swinging with work phase. If a ratio stays above 3:1 for months with no low-ratio windows, the measurement question becomes a consolidation question - the data is pointing at the cadence, not the metric.