Why Lines of Code Suddenly Became a Real Productivity Metric

Start by being precise about what the classic complaint actually says, because most people misremember it. The complaint is not 'lines of code has no relationship to work done.' It's 'lines of code is trivially gameable by the people you're measuring, and measuring it corrupts them.'

Those are different claims. A human developer who knows their lines are being counted can pad. They can avoid deleting dead code because deletions show up as negative productivity. They can copy-paste instead of refactoring. They can resist the single most valuable thing a senior engineer does, which is making a codebase smaller. Every one of those distortions is a response to being measured, not a property of the code itself.

This is textbook Goodhart's Law: when a measure becomes a target, it stops being a good measure. The reason lines of code became a punchline is that it's an unusually pure demonstration of Goodhart. The gaming is so easy and so obvious that the metric collapses almost immediately under any incentive pressure.

Willison's transcript frames this directly: a lot of people will tell you it makes no sense to measure productivity in lines of code, and for human authorship they are right. Hold onto that framing, because the whole argument turns on it. The objection is load-bearing on one assumption. A human is being incentivized. Remove that assumption and see what's left standing.

Now watch what changes when the author is an agent.

An agent working a task does not know or care that you are counting its output. It has no career, no performance review, no incentive to look busy. When it produces two hundred lines that implement a feature, those two hundred lines are an artifact of the task, not an artifact of the metric pointed at it. The feedback loop that corrupts human LOC simply isn't wired up. There's no one on the other end to corrupt.

That's the crux of Willison's case: with coding agents it sometimes does make sense to talk about lines of code as an indicator of productivity, precisely because the Goodhart failure mode requires a self-interested author and the agent isn't one.

I want to be careful here, because it's easy to overread this. The claim is not that an agent's line count measures value. It's narrower and more useful: the single strongest reason we had for throwing the number away no longer applies. That reopens the question. It does not answer it in the metric's favor.

Think of it the way you'd think about the Autonomy Spectrum that runs from copilot to full autonomy. At the copilot end, a human still owns and shapes the output, so the old incentive distortions creep back in. At the autonomous end, where the agent is generating and iterating on code with minimal human authorship, the output volume becomes a cleaner signal of how much machine work happened. The metric gets more honest exactly as the human gets further from the keyboard. That's the opposite of how it behaved before, and it's the detail most commentary misses.

Here's the gotcha, and it's the one that trips up people who get excited about agent output volume. When an agent can produce a thousand lines in a minute, the constraint on your project stops being how fast code gets written. It becomes how fast code gets understood and trusted.

This is where Willison's title earns its keep. His framing pairs lines of code with conceptual integrity: the idea, borrowed from Fred Brooks, that a system should feel like it came from one coherent mind. An agent that emits large volumes of working code can quietly erode that. Every module solves its immediate problem. Nothing enforces that the modules agree with each other about how the system should work.

So the productivity picture splits in two. Line-generation throughput goes up, sometimes enormously. Review-and-integration throughput does not, because a human still has to hold the whole thing in their head. If you only watch the first number, you'll conclude your team got ten times more productive. If you watch the second, you'll notice the pull-request queue backing up and the on-call incidents rising.

You'll want to internalize this before you set any agent-productivity target of your own. The line count is now a real measure of one thing (machine output) and a dangerous proxy for another (delivered, coherent, maintainable software). Confusing the two is the modern version of the old mistake. The tooling ecosystem knows this, which is why observability platforms for AI systems keep shipping. Langfuse, for instance, is on a rapid release cadence: its v3.225.4 release landed with fixes to automation and header-handling behavior, the kind of unglamorous plumbing that exists so teams can actually see what their agents are doing rather than just counting what they emit.

If you're reading this as someone who runs agents rather than frameworks, you might reasonably ask why a debate about a developer metric should concern you. The answer is that the same logic is coming for every task you delegate to an agent.

The pattern generalizes cleanly. Any output metric that was useless for humans because humans game it becomes potentially meaningful for agents that don't. Emails drafted, tickets closed, reports generated, documents summarized: all of these were terrible productivity measures for people, for exactly the lines-of-code reason. Point them at an agent and the gaming incentive vanishes. The number starts describing work done instead of work performed for an audience.

That's genuinely new, and it's the forward-looking piece. We are entering a period where a whole category of discredited metrics quietly becomes usable again, because we removed the actor who made them lie. Managers who learned to distrust output counts over decades are going to have to relearn when that distrust applies and when it's obsolete.

But the second lesson travels too. Volume of agent output is never the same as value delivered. The bottleneck just moves downstream to whoever verifies, integrates, and owns the result. If you take one operating principle from all of this, make it that one: count the agent's output honestly, then judge it entirely separately. The count tells you how much the machine did. It tells you nothing about whether you should have wanted it.

Precision matters here, so let's map the cases where line count remains garbage even with agents doing the work.

• Refactoring and deletion. The most valuable agent runs often produce a negative line count: they collapse duplication, remove dead paths, simplify. A raw LOC metric punishes exactly the work you want most. If your target rewards volume, your agent (or the human steering it) learns to stop cleaning up.
• Verbose vs. dense solutions. Two agents can solve the same problem in 50 lines or 500. The 500-line version is not five times more productive. It's frequently worse, and it's more for you to review.
• Generated boilerplate. Some large diffs are near-free: scaffolding, config, repetitive tests. Counting them the same as hard logic inflates the number.
• The review debt they create. As covered above, every line an agent writes is a line someone eventually has to trust. Unreviewed volume isn't productivity. It's a loan against future incident response.

The practical test you can apply: ask whether the line count is being used to describe what happened or to incentivize what happens next. Description is fine. Willison's argument works because he's describing agent output after the fact, in an environment where no one is being paid per line. The moment you turn that description into a target ('agents should ship 20% more lines this quarter'), you've reinvented every distortion the industry spent decades escaping, just with a machine that games it faster and without complaint. The Goodhart trap doesn't require malice. It only requires a target.

So you want a productivity read on your coding agents, and you now understand that raw line count is at best a partial one. What do you track?

Watch the pair, never the single number. Output volume tells you how much machine work happened. Alongside it, watch the things that measure whether that work was worth having:

• Time from generation to merged-and-trusted. If agents write faster but nothing ships faster, your gain is illusory and your review queue is the real constraint.
• Rework rate. How much agent output gets reverted, rewritten, or triggers a follow-up fix? Rising rework alongside rising volume is the signature of the conceptual-integrity problem Willison names.
• Incident correlation. If sections of the system with heavy agent authorship generate disproportionate on-call load, your throughput number is hiding a quality tax.

This is where the plumbing pays off. The reason tools like Langfuse keep shipping releases is that you cannot manage what you cannot observe, and agent output at volume is invisible without instrumentation. The observability layer is what lets you pair the honest count with the honest outcome.

There's a broader economic point underneath all of this, and it's why the metric debate is really a productivity debate. When labor is automated, the cost structure of software changes: generating a candidate solution becomes cheap, and the scarce, expensive resource becomes human judgment about which solutions to keep. That shift is showing up across the whole AI stack, right down to the physical energy economics of running these systems, where the constraint is no longer model cleverness but how efficiently you convert power into useful output. The parallel is exact. In both cases the raw production number is real and rising, and in both cases the number that actually matters is how efficiently that production turns into value. Count the lines. Just don't confuse the counting with the judging.