Engineering KPIs in the AI Era: 12 Metrics That Still Matter When AI Writes the Code

Your dashboard says the team opened more pull requests this quarter than ever before. Commits are up, and so is the share of code suggested by AI tools. Yet the release that customers were promised slipped again, two incidents came from rushed changes, and the senior engineers say they spend most of their week reviewing. Something is growing. It is not obviously delivery.

That gap is why engineering KPIs deserve a fresh look in 2026. When producing code gets cheaper, metrics that count output stop telling you much. The useful questions move downstream: how quickly does a change become a reliable improvement for users, what does it cost the team to get it there, and is the pace sustainable?

This guide gives engineering managers, tech leads and founders a balanced set of 12 metrics, explains which popular numbers to retire, and offers a 30-day plan to put them to work. The examples and thresholds are illustrative starting points for your own experiments, not industry benchmarks.

Why engineering KPIs need a rethink now

AI coding tools have moved from completing a line to drafting whole changes. That shifts where time goes. Implementation can shrink while understanding, review, testing and safe release take the same effort, or more. A KPI set built around how much gets written will report a boom even when the delivery pipeline is congested.

DORA's State of AI-assisted Software Development 2025 describes AI's primary role as "an amplifier, magnifying an organization's existing strengths and weaknesses." In practice, a team with clear ownership, fast feedback and healthy review habits can turn AI help into faster delivery. A team with long queues and unclear priorities can use the same tools to produce longer queues.

So the job of your KPIs is to show the whole system: work flowing in, work flowing out, what breaks along the way, and how the people doing it are coping. If you only measure the first part, AI makes your numbers look better while your customers notice nothing.

Three rules before you pick a metric

Measure the system, not the people. Delivery metrics describe how a team, a service and a process behave together. DORA's own guidance warns that "the goal is to improve your team's performance over time, not to compete against other teams or organizations." Once a number is used to rank individuals, people optimise the number, and it stops describing reality.

Pair every speed metric with a quality metric. Faster deployments are good news only if they do not come with more rollbacks. Shorter cycle time is good news only if escaped defects stay flat. Reviewing speed and stability side by side is what keeps a KPI program honest.

Read trends, not snapshots. A single week can be distorted by a holiday, an incident or one large migration. Look at medians and the slow end of the distribution over several weeks, and compare a team with its own history. The SPACE framework makes the same point from the research side: developer productivity "cannot be measured by a single metric or dimension."

Delivery flow: how fast work reaches users

1. Change lead time

The time from a change being committed to it running in production. It is one of DORA's throughput metrics and the clearest single view of how long your pipeline makes finished code wait. If lead time grows while coding gets faster, the delay is in review, testing or release, not in writing code.

2. Deployment frequency

How often you deploy to production. Frequent, small deployments usually mean smaller risks per release and faster feedback. Track it per service or application, as DORA recommends, rather than as one company-wide number that hides very different systems.

3. Cycle time, split into waiting and working

The time from an issue moving to In Progress until it is Done. On its own it is a blunt number. Split it by status and it becomes a diagnostic: time actively being built, time waiting for review, time waiting for QA, time blocked. In AI-assisted teams the active part often shrinks and the waiting parts become the story.

4. Review wait time

How long a ready pull request waits for its first substantive review. This is the metric most likely to move when AI increases the volume of changes, because review capacity does not grow at the same rate. Our guide to code review in the AI era covers how to manage the queue once you can see it.

Quality and stability: what breaks on the way

5. Change fail rate

The share of deployments that need immediate intervention, such as a rollback or hotfix. This is DORA's main instability signal and the natural partner to deployment frequency. If both rise together, you are shipping faster and breaking more; slow down before celebrating.

6. Deployment rework rate

The share of deployments that are unplanned and caused by a production incident. DORA added it alongside change fail rate as a second instability metric. It is especially telling for AI-assisted teams: a rise suggests that changes are passing review but still not doing what the product needed.

7. Failed deployment recovery time

How long it takes to recover when a deployment fails and needs immediate intervention. Fast recovery reflects good observability, small changes and practised rollback. It matters more as release volume grows, because more releases means more chances for something to go wrong.

8. Escaped defects

Bugs found by customers or in production rather than before release, ideally grouped by severity. It is not a DORA metric, but it captures quality problems that never trigger a rollback, such as a wrong calculation or a confusing permission. Watch the trend, and read the bugs themselves: the pattern is often more useful than the count.

Outcomes: are you building the right things

9. Planned versus unplanned work

The share of engineering time spent on planned roadmap work versus interrupts, urgent fixes and support escalations. A steadily rising unplanned share means quality or technical debt is eating capacity, even when every delivery metric looks healthy. Tag issues by type and review the split each sprint.

10. Sprint goal or outcome completion

Did the team achieve the outcome it committed to, as opposed to closing a number of tickets? Record whether each sprint goal or quarterly objective was met, partly met or missed, and why. This keeps the conversation on value delivered. It is also a better measure than sprint velocity for comparing a team with itself over time, because story points are not comparable across teams.

Team health: can you keep this pace

11. Work in progress and aging work

How many items each person or team has in progress at once, and how long the oldest items have been open. High work in progress is a reliable predictor of long cycle times and constant context switching. AI makes it easy to start more things in parallel; this metric shows whether anything is finishing.

12. Developer experience score

A short, regular survey asking engineers about focus time, build and test speed, review delays, clarity of priorities and satisfaction. Keep it to a handful of questions, run it at a steady cadence, and act visibly on what it says. It captures what system metrics miss, including the SPACE dimensions of satisfaction and well-being, collaboration, and efficiency and flow.

Metrics to stop using as KPIs

Some numbers are easy to collect and actively misleading when treated as performance targets, especially now:

• Lines of code and commit counts. AI makes these grow almost for free. More code often means more to review and maintain.
• Pull requests opened per person. Rewards splitting work into fragments and says nothing about whether changes were useful or safe.
• AI suggestion acceptance rate as productivity. Useful when evaluating a tool, misleading as a measure of output. An accepted suggestion can still be wrong.
• Velocity compared across teams. Story points are a planning aid calibrated by each team; comparing them invites inflation.
• Individual leaderboards of any delivery metric. They damage collaboration, which is exactly what keeps review and incident response working.

You can still look at some of these numbers for diagnosis. Just do not set targets on them or present them as evidence of performance.

Build a one-page KPI review

A KPI is only useful if someone looks at it and asks a question. Keep the review to one page, owned by the engineering manager or tech lead, and spend fifteen minutes on it each week or sprint. A layout like this works for most teams:

Notice that the table asks a question for every number. If nobody can say what decision a KPI informs, drop it. For a deeper look at the four classic delivery measures, see DORA metrics explained, and for the human side of throughput, our guide to engineering team productivity.

A 30-day rollout your team can try

1. Week 1: pick and baselineChoose five to eight metrics from the twelve, with at least one from each group. Pull the last two or three months of data you already have, and write down known distortions such as holidays, migrations or incidents.
2. Week 2: share the purposeExplain to the team which questions the KPIs answer, that they describe the system rather than individuals, and that nobody will be ranked on them. Run the first short developer-experience survey.
3. Week 3: review and choose one experimentHold the first fifteen-minute review. Pick the single biggest constraint, such as review wait time, and agree one change to try, for example a named backup reviewer or a limit on parallel work.
4. Week 4: compare and keep what helpedCheck the targeted metric and its quality partner against the baseline. Four weeks gives signals, not proof, so record context and keep measuring. Retire any KPI nobody used.

Track the work behind the metrics in Projiq

Several of these KPIs depend on clean data from your issue tracker. In Projiq, custom workflow statuses let you separate active work from waiting states such as review and QA, so cycle time by status reflects reality. Issue types and labels make the planned-versus-unplanned split easy to report, and sprint goals and reports keep outcome completion visible next to the work itself.

Deployment and incident data stays in your CI/CD and monitoring tools; Projiq tracks the planning and delivery work around it. Start with the statuses your team actually uses, and adjust the workflow when the board stops matching how work really moves.

Sources and further reading

The KPI selection, pairings and rollout plan above are Projiq's editorial guidance. The linked research describes delivery metrics and productivity measurement; it does not validate the specific 30-day plan.

• DORA: Software delivery performance metrics
• DORA: State of AI-assisted Software Development 2025
• Forsgren et al.: The SPACE of Developer Productivity (ACM Queue, 2021)