Measuring developer productivity has always been one of the most broken exercises in software. Over sixteen years in IT, I have watched companies try everything. They counted commit frequency, tracked story points, logged closed tickets, and worst of all, counted lines of code. Every senior engineer knew those numbers were flawed, but before AI, counting code was at least loosely correlated with effort.
That correlation has now completely collapsed. An engineer with an agent can generate 1,500 lines of boilerplate Go or a massive React table component in under a minute. If your definition of velocity is volume of syntax produced, everyone looks like a 10x developer on paper. In reality, generating a pile of unverified code is not productivity. It is just a larger surface for bugs to hide in.
When code generation is free, volume becomes a liability
The core mistake is assuming more code equals more value. In a production system, every line you commit carries an ongoing tax. Someone has to read it the next time they touch the file. It has to be tested, linted, and run in CI. It uses memory, bandwidth, and CPU in production. And each line is a place a security problem can live and later need patching.
The best engineers always knew this. The most valuable pull request is often the one that deletes 500 lines of redundant code and replaces them with a clean 20-line abstraction. When AI makes producing code effortless, the goal is not to write more of it. It is to ship the smallest amount that solves the problem reliably.
The metrics that actually matter
If lines of code are dead, what replaces them? Having built this site end to end with agents, my sense of velocity shifted from typing speed to system throughput. Three measures hold up.
Cycle time, from requirement to working pull request. How long does it take to go from understanding what needs to exist to opening a fully tested, working branch? This is where AI genuinely helps. It collapses the research, the scaffolding, and the boilerplate from days into hours, so a reviewable branch is ready fast. Speed here is real and worth having, as long as "working" is measured honestly, which is the next point.
Defect and regression rate. Does the code actually work when it runs? An engineer who generates 2,000 lines that fail in staging, or that quietly break an existing feature, is moving the team backward no matter how fast the branch appeared. On my own project the standard is concrete: a change is not done when it compiles. It is done when the full test suite passes and my prerender smoke test confirms the real production build actually renders, not just that the functions return the right values in memory. I have learned the hard way that a green test run and a working page are not the same thing, and the whole point of that pipeline is to make the difference visible before a deploy instead of after. First-try pass rate through those gates is a far better velocity signal than lines produced.
Simplicity and maintainability, including negative code velocity. How easy will this be to maintain in six months? Sometimes the highest-value change removes code. One of the better changes I made to this site deleted 156 lines of dead, duplicated CSS that had been silently overriding the real styles, which meant edits sometimes appeared not to work for reasons that had nothing to do with the edit. Removing it did not add a feature. It removed a whole category of future confusion. That is real velocity, and a lines-of-code metric would score it as negative work.
One caution before anyone turns these into a dashboard. The reason lines of code failed as a metric is that the things that actually matter in software resist being counted, and that is just as true of these three. Start ranking engineers by cycle time and people will learn to split tickets to game it. Grade on first-try pass rate and someone will pad the tests. The point is not to swap one number for three better numbers. It is to accept that judgment does not reduce cleanly to a metric at all, which is exactly why the job needs a human exercising it rather than a formula scoring it. These are lenses to think with, not KPIs to optimize.
From typist to quality gatekeeper
The rise of coding agents has finally forced the industry to admit what engineering was always about. We were never paid to type syntax quickly. We are paid for judgment. We are paid to know which architecture fits the problem, which edge cases need guarding, and how to keep a system simple enough that it does not collapse under its own weight.
AI took away the busywork of typing boilerplate. That does not make developers obsolete. It raises the standard, because the thing that is now scarce is exactly the thing that was always the actual job. The developers who win in 2026 are not the ones who generate the most code. They are the ones who understand their systems deeply enough to ship clean, durable software with the least friction, and who measure themselves by what they can maintain rather than what they can produce.
Lines of code were never a good measure. AI just made that impossible to ignore.