Do we need new productivity metrics for AI?

Productivity isn't writing more code: measuring good engineering in the age of AI

Velocity is up. Pull requests are up. Lines of code are way up. AI has changed how software gets built, so it's tempting to conclude that the old way of measuring engineering has broken, because productivity means something different now. There's a growing chorus that argues exactly that, calling for new, AI-native metrics built for a world where agents write much of the code.

Yes, AI has changed how software gets built, and it has changed where the risks sit. But what it hasn't changed is what good software looks like: reliable, readable, maintainable code that reaches users quickly and keeps working.

The "more code = more productive" trap

AI makes code cheap. A single prompt can produce in seconds what used to take an engineer an afternoon, and it's tempting to treat that as the whole story: more output, more pull requests, therefore more productivity. It's also the easiest thing to measure, which is a large part of its appeal.

It's a poor proxy, and not a new one. Good engineers have long known that lines of code say very little about quality. If anything, fewer lines are often better: less to read, less to test, less to break. Yet good code is also readable and maintainable, which often means more lines, with logic spelled out clearly for the next person who has to change it. Concise and readable pull in opposite directions, and balancing the two is a matter of human judgement.

The data suggests that volume alone isn't translating into results. In a McKinsey survey of product and engineering leaders, most of them director-level and above, only around 25% reported meaningful or top-tier AI-driven acceleration, defined as more than a quarter of their teams achieving twofold productivity gains. The rest saw far more modest movement. If generating code were the bottleneck, cheap code would have produced faster gains; the gap suggests the constraint lies elsewhere, in review, testing and integration.

AI changes the risks, not the standard

Real productivity has always combined speed, quality and efficiency, working together rather than traded off against each other. A team that ships fast but breaks production isn't productive. Neither is a team that produces flawless code no one asked for. Applied deliberately, AI can improve all three at once.

The instinct behind many new frameworks is that AI needs its own yardstick, but AI coding tools learned from code written by people, and we already know what good engineering looks like when people do it. Why invent a separate benchmark for when AI does it?

The acceptance bar should stay where it is: Does it work? Can others understand and change it? Does it hold up in production? Did it solve the problem that actually needed solving? In regulated environments, the bar also includes accountability: a named engineer remains responsible for every change, however it was drafted. But the same bar doesn't mean the same risks. AI produces confident, plausible output in large volumes, and its mistakes look different from a tired engineer's. Fluent output also invites automation bias: reviewers tend to trust what looks right. That's why review and testing become the scarce resource, and why DORA's 2025 research describes AI as an amplifier: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones.

Existing measures for a new delivery model

Not everyone agrees the established measures are enough. Writing in Forbes, Ameya Kanitkar, CTO of AI measurement company Larridin, argues that quality and productivity measurements such as DORA (DevOps Research and Assessment), and SPACE were built for a world where humans wrote all the code, and that AI-native development needs new measures, such as AI code share (how much code is AI-generated), code turnover (how much is rewritten soon after it's written) and innovation rate (how much effort goes into new capability rather than maintenance).

Look at what the new metrics capture. Code turnover overlaps heavily with rework, which DORA now measures directly. Innovation rate asks whether effort is turning into value, a real question, but one DORA never claimed to answer; it belongs to product and outcome measures, which have always sat alongside delivery metrics. AI code share is new, and useful as a description of how work is getting done, but it measures adoption, not whether the result is any good.

Conclusion

The way you measure good software development doesn't change just because you've introduced AI. DORA, FLOW, SPACE and DevEx-style measures (deployment frequency, lead time, change failure rate, time to restore) remain the right anchor, because they were measuring whether the system was healthy: fast, stable, and improving. AI changes the mechanics of delivery; it doesn't change what a healthy engineering system looks like.