AI developer productivity metrics: what should you actually measure?

The first AI dashboard most teams build shows suggestion acceptance rate, because it is the number the tool hands over for free. It goes up for a few months, everyone feels good, and nobody can say what it has to do with the release that slipped. Acceptance rate measures how often a developer pressed Tab. That is a fact about the editor, not about the team’s output.

Why are the obvious AI metrics the wrong ones?

The obvious AI metrics (acceptance rate, lines of AI-generated code, share of code written by AI) measure activity at the moment of writing, and they reward volume. They are also the easiest numbers to game: once a team is judged on generated lines, it produces more lines, whether or not the work needed them.

Volume is also not neutral. A 2025 analysis of 211 million changed lines found an eightfold increase during 2024 in duplicated blocks of five or more lines. More generated lines can mean more code to maintain, which is the opposite of productivity. A metric that goes up in both the good case and the bad case cannot tell you which one you are in.

Which frameworks already define developer productivity?

Two research frameworks cover most of what an AI-assisted team needs, and AI replaced neither of them.

DORA’s software delivery metrics. Five metrics in two groups. Throughput: change lead time, deployment frequency and failed deployment recovery time. Instability: change fail rate and deployment rework rate. They describe the delivery system as a whole, which is where AI gains either arrive or get absorbed.

SPACE. Five dimensions from the original research: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. Its point is that no single dimension captures productivity, so a team picks a few measures across several of them.

What AI adds. Three questions any AI rollout has to answer on top of those: who uses it and how deeply (utilization), what changed in the work (impact, read through the delivery metrics above) and what it costs.

Read together, they say the same thing: AI metrics sit next to delivery metrics, never in place of them.

What should an AI-assisted team actually measure?

Measure five layers, with one primary metric and one counter-metric each. The counter-metric is the number that would move if the primary one were being gamed or bought at a hidden price.

The experience layer matters more than it looks. Some of the value of AI tools (less time reading unfamiliar code, fewer context switches) never shows up in Git. A one-question survey each quarter captures it. Read it with care, because METR’s 2025 trial found developers believed they were 20% faster while they were measurably slower.

How do you read a metric and its counter-metric together?

Plot the change in each pair against each other and the quarter’s story usually becomes obvious. Take throughput and quality: the horizontal axis is how much more the team merged than last period, the vertical axis is how its change fail rate moved (up is better, so a falling fail rate plots high).

quadrantChart
  accTitle: Throughput change against quality change
  accDescr: Four quadrants. Top right is a real gain, more merged with fewer failures. Bottom right is speed bought with rework. Top left is careful but slower. Bottom left is slower and worse. Three illustrative teams are plotted, one in each of the first three quadrants.
  title Throughput and quality, change versus last period
  x-axis Fewer merged --> More merged
  y-axis Quality worse --> Quality better
  quadrant-1 Real gain
  quadrant-2 Careful but slower
  quadrant-3 Slower and worse
  quadrant-4 Speed bought with rework
  Team A: [0.78, 0.72]
  Team B: [0.82, 0.24]
  Team C: [0.3, 0.66]

Team B is the case a single metric hides. Its pull request count is the best of the three, and on a dashboard without the counter-metric it would be the team everyone copies. With the pair, the next question is clear: which changes failed, and was AI involved in writing or reviewing them?

The same reading works for every layer. Usage up with sessions per person flat means more people tried AI without it becoming part of their work. Spend up with cost per merged pull request down is a team that pays more and gets more for it, which is usually fine.

How do you build an AI productivity metric set in a month?

1. Week one: baseline the delivery layer. Throughput and quality first, from Git and your deployment pipeline. These numbers exist whether or not anybody uses AI, so they are your before.
2. Week two: connect usage and cost. Vendor dashboards and telemetry. Claude Code, for example, exports OpenTelemetry metrics for sessions, tokens, cost, commits and pull requests (claude_code.cost.usage, claude_code.pull_request.count).
3. Week three: send the survey. One question on time saved, one on satisfaction. Anonymous, short, repeated each quarter.
4. Week four: put the layers on one page. Same period for every number, compared with the previous period of the same length. Agree on which counter-metric triggers a conversation.

Then leave it alone for a quarter. Metric sets that change every month never produce a trend.

flowchart TD
  accTitle: A month to build the metric set, then a quarter to read it
  accDescr: Week one sets the delivery baseline, week two connects usage and cost, week three sends the survey, week four puts the layers on one page. Then twelve weeks without changing the metrics before the first trend review.
  W1[Week 1: delivery baseline] --> W2[Week 2: usage and cost connected]
  W2 --> W3[Week 3: survey sent]
  W3 --> W4[Week 4: one-page view, first readout]
  W4 --> Q[Weeks 5 to 16: the same metrics, unchanged]
  Q --> T[First trend review]

How does HubBound cover these layers?

HubBound Metrics covers the usage, throughput and cost layers from agent telemetry and GitHub, adds a delivery footprint for AI, and leaves quality and experience to other sources.

• Usage: Active with AI, Sessions over time, Sessions by tool, Session mix by model, Most used skills and MCP servers.
• Throughput: Commits over time, Pull request outcomes, Time to merge (average hours from opening a pull request to closing it).
• Delivery footprint: AI involvement in commits and Lines added over time, each split by whether the change carries evidence of AI assistance.
• Cost: Cost over time, Cost by model, Cost by person, Cost traced to delivery (spend tied to a specific commit or pull request) and Measurement coverage, plus the Cache efficiency section.

HubBound does not run developer surveys and does not read deployment or incident data, so change fail rate, recovery time and the experience layer need another source. Every number is compared with the previous period of the same length, and the view is the organization or one member, not a team.

When do AI productivity metrics fail?

They fail as soon as they are used to rate individuals. Any metric attached to a person’s review becomes a target, and people meet targets in the cheapest way available: smaller pull requests to raise the count, more generated code to raise the AI share. Use team-level numbers for decisions and person-level numbers only to help someone, privately.

They fail on small teams, where a single long vacation moves every average. Below ten or so people, read the trend over several periods and ignore the swings.

And they fail when attribution is treated as fact. “AI evidence” in a commit is a heuristic based on telemetry and metadata, not a forensic proof. It is good enough for a trend, not for a claim about one change.

What is the one rule worth keeping?

Never report an AI metric without the delivery metric that would expose it. Acceptance rate without time to merge, AI share without change fail rate, spend without cost per merged pull request: each of those on its own is a number that can only go in a direction someone wants.

A 2025 telemetry study of more than 10,000 developers is the clearest example of why. High-adoption teams merged 98% more pull requests, and their review time grew 91%. A dashboard showing only the first number would have reported a triumph. A dashboard with the pair showed where the work was actually waiting.

xychart-beta
  accTitle: Pull requests merged and review time on high-adoption teams
  accDescr: Bar chart of two changes reported for high-adoption teams in a 2025 telemetry study. Pull requests merged up 98 percent, review time up 91 percent.
  title "Teams with high AI adoption (2025 telemetry study)"
  x-axis ["Pull requests merged", "Review time"]
  y-axis "Change (%)" 0 --> 100
  bar [98, 91]