Lines of code was always a weak productivity metric, and most engineering leaders have known that for a long time: it rewards verbosity, penalizes clean abstraction, and says nothing about whether the code does what it's supposed to do. It survived as long as it did mostly because it was easy to measure, not because anyone believed it was a good measure.
AI-assisted coding tools have made that weakness worse, not better. A model can generate a large volume of plausible-looking code in seconds, which means lines of code (or its close cousins, commits per day or pull requests merged) can now be inflated with almost no relationship to actual delivered value. The metric didn't get more meaningful when the tooling got better; it got easier to game.
What actually needs measuring instead
The teams handling this well have moved toward outcome-based measures that are harder to inflate mechanically: cycle time from a ticket being picked up to it being verified in production, defect escape rate (how much AI-assisted code makes it to production and then has to be reverted or hotfixed), and reviewer load, since a team generating code faster than it can be properly reviewed is building a backlog of unverified risk, not shipping faster.
Reviewer load in particular is worth watching closely. If AI tooling doubles the volume of code proposed for review without a corresponding increase in review capacity or rigor, the team hasn't gotten more productive. It's accumulated a queue of code that's been merged on trust rather than verified, which tends to surface as production defects on a delay, not immediately.
The harder, more honest measure
The uncomfortable version of this is that the right metrics are slower to move and harder to attribute cleanly to a single tool or process change. Cycle time and defect escape rate respond to a lot of variables at once, which makes them less satisfying in a dashboard than a lines-of-code counter ticking upward. That's exactly why they're worth using: a metric that's hard to game is usually one that's actually measuring something.
Teams adopting AI coding tools without changing what they measure tend to see the dashboard improve well before they can tell whether delivery actually got better. The fix isn't slower adoption of the tooling. It's retiring the metrics the tooling broke before they quietly start driving the wrong behavior.