AI productivity metrics in software engineering: what leaders should measure

AI increases engineering activity. When AI-enabled, your teams likely generate more code, open more pull requests, and so forth – research from GitHub suggests developers can complete tasks up to 55% faster using AI tools.

But more activity does not necessarily mean better software delivery.

So, the harder question for engineering leaders is: what should we measure in order to track and verify real delivery gains?

In many organisations, lead time to production does not improve at the same rate. Teams can look more productive in isolation, while outcomes at a system level remain unchanged or become less predictable.

That is what makes AI productivity metrics difficult, and why measuring AI in software engineering requires more than tracking usage, output, or time saved.

In this blog:

• How DORA and flow metrics apply, and where they fall short for AI

• The metrics that matter for software development productivity

• Which AI metrics mislead and why they create false confidence

• How to move from AI adoption to impact using the RACER framework

DORA and Flow Metrics (And Where They Fall Short for AI Developer Productivity)

You’re probably familiar with one or both of DORA metrics and flow metrics. Engineering leaders widely use them to understand  software delivery performance. They look at the system from slightly different angles, but are often used together in practice.

These frameworks still matter, and most engineering leaders should keep using them. The issue is not with the metrics. It is with the context.

DORA and flow metrics were built to measure delivery performance in systems that are broadly behaving as expected. 

AI changes that. It tends to accelerate specific parts of the SDLC first, usually code generation, without removing the constraints around review, testing, release, or planning.

That is why you can see movement in the metrics without seeing real improvement in delivery. 

A System-Level View: What Is AI Productivity in Software Engineering?

If you want to understand whether AI is actually improving productivity, you have to look beyond isolated metric movement and judge whether the system itself is getting healthier.

When AI works effectively, it creates more capacity for value delivery, with better flow, without degrading execution.

In practice, that means improving four things at once:

• Focus: are teams spending more capacity on roadmap work and value delivery?

• Speed: is work moving through the system more efficiently?

• Predictability: are teams delivering more consistently?

• Quality: is throughput increasing without creating more defects and rework?

This is Plandek’s Four Pillars of Productivity.

These exist to give us a broader way to interpret our metrics – including DORA and flow metrics – particularly in AI-enabled SDLCs.

Software engineering productivity is a system outcome. It does not sit inside one tool or one stage of the workflow. It emerges from how work moves from idea to production. If any part of that system cannot absorb increased throughput, the constraint still controls delivery.

This is also why AI does not create uniform gains across teams.

Plandek’s 2026 Engineering Productivity Benchmarks showed lower-performing teams cut Lead Time to Value from 62 days to 33 days and doubled their stories-to-bugs ratio. Higher-performing teams improved too, but much more modestly, with Lead Time to Value moving from 22.5 to 20 days.

The point is not whether a team is “low” or “high” performing. The point is how constrained the system already is. Where review, testing, planning, or release are creating drag, AI can remove a meaningful amount of friction. Where delivery is already efficient, the gains are more incremental.

The Four Pillars of Productivity: AI productivity metrics engineering leaders should track

Once productivity is defined at a system level, there are really two things to understand:

• whether AI is being used at all

• whether it is improving delivery

The Four Pillars of Productivity Framework defines what better delivery looks like (focus, speed, predictability, and quality), and groups metrics into four corresponding groups:

Focus – are we working on the right things?
How much engineering capacity is directed toward value delivery, rather than being consumed by support, rework, or maintenance?

• Value Delivery %

• Support and Maintenance %

Speed – are we delivering efficiently?
How quickly does work move from idea to production, and how efficiently teams convert effort into delivered output?

• Lead Time to Value

• Cycle Time

• Throughput Quotient

• Time to Merge PRs

• PR Efficiency Quotient

• Merge Frequency per author (per week)

Predictability – how consistently are we delivering?
How reliably can teams plan and execute work, without excessive volatility or disruption?

• Sprint Capacity Accuracy

• Sprint Target Completion

• Mid-Sprint Scope Change

• Velocity Volatility

Quality – are we delivering sustainably?
Is increased throughput creating lasting value, or generating defects and rework that consume future capacity?

• Bug Resolution Time

• Stories Delivered : Bugs Raised ratio

• Bugs Resolved : Bugs Raised ratio

Use these metrics for a system-level view of engineering productivity, to show not just how much work is being done, but how effectively that work turns into delivered value.

AI metrics that often mislead engineering leaders

The easiest AI metrics to collect are often the least useful.

Most of them sit too close to the point of code generation. They tell you that AI is being used, or that activity is increasing. They do not tell you whether the system is delivering better outcomes.

That is why these metrics need to be treated carefully:

• AI-generated code percentage – shows usage, not whether that code improved delivery

• PR volume and commit volume – can rise while review slows, quality drops, or lead time stays flat

• Self-reported time saved – useful as a supporting signal, but too subjective to treat as proof of productivity

• Tool usage alone – adoption matters, but adoption is not impact

Even established frameworks can be misread in the same way. DORA metrics, for example, may show stable deployment performance while earlier stages such as review or testing are quietly becoming more constrained under higher AI-driven throughput.

The issue is rarely the metric itself. It's whether you're asking it to answer a question it cannot answer.

This is why Plandek's AIRadar™ connects AI adoption metrics with leading indicators from across the engineering system, helping leaders understand whether AI is improving performance, where gains are being lost and what to improve next.

How to move from AI adoption to real impact: the RACER™ Framework

Knowing which metrics matter is only half the challenge. Engineering leaders also need a way to act on those signals to improve performance and the return on AI investment.

Plandek's RACER™ Framework provides a structured approach to managing the AI transition, from rollout to results, built around five critical questions:

• Rollout: Are teams meaningfully adopting AI?

• Approach: Are they using it effectively?

• Constraints: What's holding AI back?

• Engineering Impact: Is AI improving engineering performance?

• Results: Is the investment paying off?

RACER connects leading indicators with the decisions engineering leaders need to make: which approaches are working, where constraints are absorbing AI gains, and where to intervene to improve outcomes.

Combined with the Four Pillars of Engineering Productivity, it helps teams move beyond measuring AI activity to actively improving engineering performance and ROI.

→ Struggling with AI in your SDLC? Understand the RACER Framework

Turn AI productivity metrics into better engineering outcomes with AIRadar™

More code. More pull requests. More AI spend. But are your teams actually delivering better software, faster? And is the investment paying off?

Plandek's AIRadar™ gives engineering leaders one place to manage the AI transition, from rollout to results.

Built around Plandek's RACER™ Framework, AIRadar brings together leading indicators from across AI tools and the engineering system to guide the decisions that improve engineering performance and make every token count.

With AIRadar, you can:

• Go beyond AI usage metrics. Understand how teams are adopting AI, which tools and approaches they're using, and how those approaches relate to delivered work.

• Identify and remove constraints. Surface the codebase and workflow bottlenecks preventing faster coding from becoming faster delivery, and prioritize where to intervene.

• Improve engineering performance. Compare AI-contributed work with human-only work across Focus, Speed, Predictability and Quality to understand what's improving and what needs attention.

• Understand your AI ROI. Connect seat and token spend with delivered output to understand where AI investment is creating value and where it isn't.

AI adoption doesn't guarantee better engineering performance. AIRadar helps you actively manage the transition, address what's holding back results and build a defensible picture of the return on your AI investment.

From token burn to business return.

Explore AIRadar™

Key takeaways

• AI increases activity, not necessarily delivery – more code and PRs don’t guarantee faster or better outcomes

• Productivity is a system outcome – it depends on how work flows from idea to production, not just coding speed

• DORA and flow metrics still matter – but they don’t fully explain AI’s impact without broader context

• The Four Pillars define real productivity – focus, speed, predictability, and quality must improve together

• Most AI metrics are misleading in isolation – usage and output metrics rarely reflect delivery performance

• AI impact depends on system constraints – without addressing bottlenecks, increased activity won’t translate into value

FAQs

What are AI productivity metrics in software engineering?

AI productivity metrics measure whether AI tools improve software delivery, focusing on system outcomes like speed, quality, predictability, and value delivery, not just activity.

How do you measure AI productivity in engineering teams?

Measure AI productivity by tracking changes across the SDLC, including lead time, quality, predictability, and capacity spent on value delivery, alongside adoption.

Why doesn’t higher AI usage always improve delivery?

Because AI often speeds up coding without fixing bottlenecks in review, testing, or release, leading to more work entering the system without improving output.

Are DORA metrics enough to measure AI impact?

DORA metrics are essential but incomplete for AI. They show delivery performance but don’t fully explain how AI affects flow, constraints, or system behaviour.

What are the most important metrics for AI in software engineering?

The most important metrics align to focus, speed, predictability, and quality – such as Lead Time to Value, Cycle Time, defect ratios, and Value Delivery %.

How does AI affect software engineering bottlenecks?

AI typically increases throughput at the coding stage first, which can expose or worsen bottlenecks in review, testing, and release if those constraints are not addressed