Developer productivity metrics
for AI-assisted teams.

Which framework measures what

The authors of SPACE write that productivity “cannot be measured by a single metric or dimension.” The frameworks most teams start from, side by side (DORA's metrics in detail):

PR cycle time: definition and formula

PR cycle time is the time from a pull request being opened to being merged. Report the median and the 75th percentile, not the mean: a few long-lived pull requests skew an average. Split it at the timestamps GitHub records to see where the time goes:

• Coding time: first commit to pull request opened.
• Pickup time: opened to first review.
• Review time: first review to merge.
• Deploy time: merge to production, where DORA's change lead time ends.
• GitHub search returns at most 1,000 results, so run the script below per month on a busy repository. A review bot counts as a first review: filter on .author.login if you run one.

gh pr list --repo owner/repo --state merged --limit 1000 \
  --search "merged:>=2026-09-01" \
  --json createdAt,mergedAt,reviews |
jq 'def hours(a; b): ((b | fromdate) - (a | fromdate)) / 3600;
  def pct(p): sort | .[(length - 1) * p | round];
  [.[] | {
    cycle: hours(.createdAt; .mergedAt),
    pickup: (if (.reviews | length) > 0
             then hours(.createdAt; (.reviews | map(.submittedAt) | min)) else null end)
  }]
  | {merged: length,
     cycle_median_hours: (map(.cycle) | pct(0.5)),
     cycle_p75_hours: (map(.cycle) | pct(0.75)),
     pickup_median_hours: (map(.pickup | values) | pct(0.5))}'

How AI coding changes what to measure

Coding agents make a change cheaper to write, so activity counts (commits, pull requests, lines) rise whether or not more ships. SPACE already warns that activity metrics should never be used in isolation to reward or penalize developers, and DX cautions against using AI metrics for individual performance reviews.

How fast AI feels is a poor guide too. In METR's randomized trial of 16 experienced open-source developers on 246 issues (July 2025), tasks took 19% longer with AI allowed, and the developers still believed AI had sped them up by 20%.

In February 2026 METR called its own follow-up data unreliable: 30% to 50% of developers said they held back tasks they didn't want to do without AI. Its raw estimate for newly recruited developers was 4% less time per task, anywhere from 15% less to 9% more.

How to measure AI coding impact per engineer

DX's AI Measurement Framework uses three dimensions: utilization, impact and cost. Zest records the system side of each from the coding agents' own sessions, joined to GitHub by the Zest GitHub App:

• Utilization: which coding agents, models, skills and MCP tools each engineer uses, across Claude Code, Cursor, Codex, GitHub Copilot Chat, Grok Build and Hermes.
• Cost: input, output and cache tokens per session, with an estimated cost at model list prices.
• Impact: the pull request each session led to, PR throughput (merged pull requests per week, averaged over four weeks) and PR cycle time (median and p75 hours, opened to merged, week over week).
• Zest computes no DORA metric and runs no survey: it reads no deployments or incidents, and no Copilot inline completions. Keep your CI/CD, incident and survey tools for those.