How to measure AI developer productivity: key metrics to track

Ask most engineering orgs how AI is affecting their productivity and you’ll get a usage number.

Licenses issued, weekly active users, a survey where everyone says they’re faster.

None of that tells you whether your software reaches production sooner or breaks less often. And if you’re the one defending the AI budget to a board, that’s the question you’ll get asked.

The gap is well documented. 89% of executives say AI increased the speed of work. Only 6% can point to organization-wide ROI.

In this article, we’ll discuss the five groups of AI developer productivity metrics you should track. For each one, you get what to measure and where to find the number in systems you already own.

What to set up before you measure AI developer productivity

You need two things if you want AI productivity metrics to mean anything: a baseline from before AI adoption and tags to tell AI-written code apart from everything else.

Neither costs much to set up.

The baseline you can reconstruct after the fact if you have to. The tagging you can’t, which is why you should do it first.

Tag AI-authored code

If you can’t tell which pull requests involved AI, all you can do is compare this quarter against last quarter.

That’s not enough. Skipping this step breaks everything downstream.

You need to compare AI-assisted work against the rest, or you’ll never know whether AI moved the number or whether it was something else.

100+ projects delivered. We’re ready for yours. Let’s talk →

You’ll be talking with our technology experts.

Do all three of these. None of them is reliable on its own:

• A required field in the PR template. A checkbox or a three-way choice: none, assisted, agent-generated. Block the merge if it’s empty.
• Commit trailers. Something like AI-Assisted: claude-code, written by a Git hook or by your agent’s commit step. It survives squash merges better than labels do.
• Automatic labels from tool telemetry. If your assistant exposes an API or an audit log, join it to PR authorship and apply the label in CI. Don’t rely on anyone remembering.

Self-reporting won’t be perfect. Audit it against tool telemetry once a quarter and move on. Imperfect tags still beat no tags by a wide margin.

Pull a 12-week baseline before rollout

Twelve weeks is long enough that one bad release or one holiday period won’t skew the picture.

Already rolled out? You can still build the baseline. All of this data is sitting in your systems already:

• Deployment frequency and change lead time. Commit-to-deploy timestamps in your continuous integration and delivery (CI/CD) logs.
• Change fail rate. Incident tickets linked to releases.
• Code churn. Git history, counting lines added then rewritten or reverted within two weeks.
• Review turnaround, review cycles, and PR size. Your Git host’s API.

End the window a month before your official rollout, not the day before. Engineers try these tools long before anyone approves a budget for them.

Key AI developer productivity metrics

Here’s the whole framework. Five groups, and how AI changes each one:

Each group won’t tell you much on its own. The value is in reading them against each other to get the full picture.

Delivery speed and stability (DORA metrics)

Start here. DORA now publishes five delivery metrics, and all five come from systems you already run:

• Change lead time. Commit-to-deploy timestamps in your CI/CD logs.
• Deployment frequency. Deploy records from the same CI/CD pipeline.
• Failed deployment recovery time. Incident open and close timestamps.
• Change fail rate. Incident tickets joined to release IDs.
• Deployment rework rate. Rollback and hotfix records against the same release IDs.

What good looks like: throughput improving while both instability metrics hold flat or fall.

DORA’s 2025 research found a positive relationship between AI adoption and throughput but a persistent negative relationship with stability, which they call the AI productivity paradox.

In 2024 the same research tied a 25% adoption increase to a 7.2% decrease in delivery stability.

I don’t accept a throughput gain as a result unless the stability numbers came with it. If change fail rate moves up more than a point, that’s the real finding.

AI adoption rate and usage metrics

Track four usage numbers and no more:

• AI adoption rate. Share of engineers with an active license who use it, from tool admin telemetry.
• Weekly active usage. Same telemetry, measured weekly rather than monthly.
• Share of merged code AI-authored. Your PR tags joined to line counts from Git.
• Suggestion acceptance rate. From the assistant’s own analytics, where it exposes them.

For reference points, 93% of developers use AI tools monthly and roughly 27.4% of merged code is AI-authored, while 90% of developers use AI at work with a median of two hours a day.

Even so, leading organizations reach only about 60% active usage.

Treat usage strictly as a diagnostic. It explains why the other layers moved, and it’s never the result.

AI code quality metrics

Code health is where AI’s cost shows up latest and hurts longest. The four code quality metrics you need to follow are:

• Code churn at 30 and 90 days. Lines added then rewritten or reverted, from Git history analysis.
• Revert rate on AI-tagged PRs. From Git, split by AI tag against untagged work.
• Duplicated block rate. From static analysis you already run, whether SonarQube, Qlty, or a CI linter.
• Refactoring share of total changes. Also from Git history, tracked as a percentage of all changes.

Read all four on a delay, not in the week the code merges. The cost you’re looking for takes a month to appear and a quarter to confirm.

It helps to know what you’re likely to find. The industry-wide picture isn’t encouraging.

GitClear’s analysis of 623 million changes found block duplication up 81% since 2023. Refactoring fell from 21% of changes in 2022 to 3.8% in 2026.

Teams now prefer duplication over refactoring roughly 5:1. Before AI, they preferred refactoring 2:1. Measured churn rose from 3.1% in 2020 to 5.7% in 2024.

Of the four, watch refactoring share the closest.

Falling refactoring won’t cause an incident on its own. It just means whoever touches that code next pays for it, and the bill doesn’t arrive for a year or two.

AI code review metrics

These metrics answer the question that decides your ROI: where did the saved authoring time reappear? Four metrics, all from your Git host’s API on tagged PRs:

• Review turnaround. Time from PR open to approval.
• Review effort. Comments and review cycles per PR, the depth signal behind turnaround.
• PR size. Lines changed per pull request.
• Debugging time on AI-tagged work. Time between first review and merge on tagged PRs, plus follow-up fix commits.

Review turnaround on its own will mislead you. A PR approved in an hour with two comments and no back-and-forth wasn’t reviewed carefully. It was waved through.

Review effort is what catches that. Chart it next to PR size every week.

The scale of this is bigger than most people expect.

Faros AI telemetry across 1,255 teams found PRs 154% larger, review times 91% longer, and 9% more bugs per developer, alongside 21% higher task completion.

Separately, 66% of developers report spending more time fixing almost-right AI-generated code, which Stack Overflow’s survey names as the number-one frustration with these tools.

My recommendation is blunt: cap PR size in policy, at something like 400 changed lines, and enforce it in CI.

Larger AI-generated diffs don’t get better review. They get less.

If review effort keeps climbing anyway, AI code review tools can absorb the mechanical pass. They don’t change what you should be measuring.

Developer trust and business impact metrics

Measure this quarterly, by survey, because the SPACE framework was right that at least one measure has to be about perception. Here are three metrics to track:

• Developer trust in AI output. A quarterly survey question, tracked as a trend rather than a snapshot.
• Share of engineering time on new capability. Roadmap time allocation versus maintenance and toil.
• Net hours saved after review and rework. Calculated, not surveyed. The method is in the next section.

Trust is not a soft metric. DORA found 30% of developers report little or no trust in AI-generated code against 24% who trust it substantially, and Stack Overflow found 46% distrust its accuracy versus 33% who trust it.

Watch what low trust does in practice. Developers either spend real time checking the output, or they give up checking and merge it anyway. The first shows up in your review numbers. The second shows up in your change fail rate.

And for business impact, I’d borrow from DX Core 4, a measurement framework that pairs delivery speed with quality and business impact.

Its headline impact metric is percentage of engineering time spent on new capabilities, and that’s the one number a non-technical executive reads correctly on the first try.

How to calculate net time savings from AI coding assistants

And then there’s the big one – how much time AI coding assistants actually save your team.

The calculation has three parts. Start with the hours your engineers say AI saves them. Subtract the extra time review now takes. Subtract the time spent fixing output that was almost right. What’s left is your real number.

You need four inputs. Here’s where each one comes from:

• Hours saved per engineer. Ask your team. Or use 3.9 hours a week, DX’s Q1 2026 average, as a placeholder until you have your own.
• Review time before AI. Pull it from the baseline you set earlier. I’ve used 3 hours per engineer per week.
• How much review time has grown. Faros measured 91% longer reviews across 1,255 teams. I’ve used 60% to stay conservative.
• Rework load. How many engineers lose time to almost-right output, and how much. I’ve used two-thirds of the team at 1.5 hours a week.

Run it for a 50-engineer org and you get:

• Gross saving: 50 × 3.9 = 195 hours a week
• Added review: 50 × 3 × 60% = 90 hours
• Added rework: 33 × 1.5 = 50 hours
• Net: 55 hours a week

Per engineer, that’s 1.1 hours a week instead of 3.9. Still a real gain worth having.

AI failure patterns to watch out for

You’ll only spot these by reading the groups together. Five come up again and again:

• High usage, flat delivery. The tool is in the workflow and nothing ships sooner. Usually a review or deploy bottleneck, not a tooling problem.
• Throughput up, stability down. The most common pattern in the research and the easiest to hide by reporting only throughput.
• Perceived speed diverging from measured speed. When your survey and your Git data disagree, believe the Git data.
• Falling refactoring share. Your engineers are copying code instead of restructuring it. A year from now, every change to that part of the codebase will take longer than it should.
• Uniform results. AI helps most on new, simple code. DORA’s ROI research cites a Stanford finding of 35-40% gains there, against 10% or less on complex legacy work. One org-wide average hides both numbers.

Watch that last one closely. It’s the one that tells you your dashboard is built wrong.

If every team reports the same uplift, you’re averaging between two very different realities. Split the numbers by codebase age to get real, actionable results.

Measuring AI developer productivity: FAQs

Looking for a reliable engineering partner?

Choosing an engineering partner mostly comes down to trust. Will they tell you what a project actually takes, and will they give you the real number instead of the flattering one?

We build complex custom software for companies that can’t afford to get it wrong. Our teams work on one project at a time, so the people building your product have the space to care about it.

We use AI agents throughout, always supervised by senior engineers. We’re engineers who use AI, not vibe coders, and we’d rather show you a measured result than a promise.

42% of our engineers hold an M.S. in computer science, we hire from the top 1.5% of applicants who come through our process, and we’re ISO 27001 certified. Since 2012 we’ve delivered for companies including Microsoft, Norfolk Southern, and Royal Caribbean.

If that’s the kind of team you’re looking for, you’re in the right place.