Developer productivity: how to measure it, with cubic's data

Developer productivity is how effectively a team turns engineering time into working software that reaches users, and no single number captures it. With AI coding tools, output has grown fast: in cubic's State of AI coding 2026 report, PRs merged per developer doubled from a median of 6 per month (June 2025) to 12 (May 2026), and the median PR grew from 56 to 124 lines of code changed.

More merged code isn't the same as more value delivered. Research frameworks such as DORA, SPACE and DevEx measure productivity with a few team-level delivery and quality metrics plus regular developer surveys, and they use counts of lines, commits or pull requests only as context, if at all.

What the State of AI coding report shows about developer output

The report draws on hundreds of thousands of commits by teams of at least two developers. Its data note says the metrics cover only commits with tracked AI attribution, "only a fraction of all commits," and describes them as a directional look at emerging patterns.

The report sums this up as developers "merging roughly three times more code than they were a year ago, a substantial increase in developer output." It concludes that the value delivered has grown with AI adoption, while cautioning that "AI tends to generate more verbose and boilerplate-heavy code than humans" and that "the impact is difficult to measure precisely."

Both cautions apply when you measure a team: verbose code inflates line counts, and none of the three figures shows whether the changes held up in production, how long they waited for review, or how the people who wrote and reviewed them experienced the work.

Also keep in mind who is in the data. Among teams that track which model wrote each commit, the report says AI now authors 90 to 100% of code, up from 78% in mid-April. It calls them "the most AI-forward teams in the industry" and says to "treat this as a leading indicator, not an industry average." Bug Bench's AI coding statistics break down AI-written code in the pull requests we review by model and coding agent, refreshed every day.

The SPACE paper says developer productivity "cannot be measured by a single metric or dimension." For any team, AI-heavy or not, that means asking:

• How quickly and safely do changes reach users?

• Do those changes work, or do they come back as incidents and rework?

• What slows developers down, and can they focus?

Why lines of code, commits and PR counts mislead

Output counts are easy to collect, which is why they keep coming back. Each one rewards something other than useful work.

In 2003, Martin Fowler wrote in Cannot Measure Productivity that "any good developer knows that they can code the same stuff with huge variations in lines of code, furthermore code that's well designed and factored will be shorter because it eliminates the duplication." Coding agents make line counts weaker still. When an agent writes most of the lines in a pull request, a line count measures the tool more than the team.

The SPACE authors make the same case for activity metrics in general. They write that even straightforward metrics such as the number of pull requests, commits or code reviews "are prone to errors because of gaps in data and measurement errors." Activity metrics, they add, "should never be used in isolation either to reward or to penalize developers." In their example, when many places moved to mandatory work from home during the pandemic, some measures went up, such as code commits and the speed of merging pull requests. Qualitative data showed that some people were struggling with their well-being at the same time. The paper's table of example metrics marks lines of code and story points with a warning to use them "with (even more) caution."

Any count also stops working once it becomes a target. The first pitfall in DORA's metrics guide is "setting metrics as a goal." Ignoring Goodhart's law with a mandate such as "Every application must deploy multiple times per day by year's end" makes it more likely that teams "will try to game the metrics."

How to measure developer productivity with DORA, SPACE and DevEx

Three frameworks from published research answer different questions about a team, and none of them relies on output counts alone.

DORA: software delivery performance

DORA, a research program run by Google Cloud, uses five software delivery metrics. Change lead time (from commit to production), deployment frequency and failed deployment recovery time measure throughput. Change fail rate and deployment rework rate measure instability: the share of deployments that need immediate intervention, likely a rollback or a hotfix, and the share that are unplanned and happen because of an incident in production.

DORA's guide says its research "has repeatedly demonstrated that speed and stability are not tradeoffs," and that top performers do well across all five metrics. It also says the metrics are "best suited for measuring one application or service at a time," and it warns against comparing very different applications or using the metrics to compete with other teams.

SPACE: five dimensions of productivity

The SPACE of Developer Productivity, by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler, appeared in ACM Queue in February 2021. Its five dimensions give the framework its name:

• Satisfaction and well-being: how fulfilled, happy and healthy people are.

• Performance: the outcome of a process, such as reliability or customer satisfaction.

• Activity: the count of actions or outputs, such as pull requests or code reviews.

• Communication and collaboration: how people and teams communicate and work together.

• Efficiency and flow: doing work with minimal delays or interruptions.

The paper takes on five myths, including "Productivity is all about developer activity" and "One productivity metric can tell us everything." Its advice is to capture several metrics across multiple dimensions ("at least three are recommended") and to make sure "at least one of the metrics include perceptual measures such as survey data."

Merged PRs per developer, the number that doubled in the report, belongs to the activity dimension. Read it next to a performance measure such as reliability and a satisfaction measure from a survey.

DevEx: the friction developers feel

DevEx: What Actually Drives Productivity, by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler, appeared in the March-April 2023 issue of ACM Queue. It focuses on developer experience, "the lived experience of developers and the points of friction they encounter in their everyday work," and reduces it to three dimensions:

• Feedback loops: "the speed and quality of responses to actions performed," such as waiting for tests to run or for a code reviewer's approval.

• Cognitive load: "the amount of mental processing required for a developer to perform a task."

• Flow state: being "fully immersed in a feeling of energized focus, full involvement, and enjoyment."

The paper measures each dimension two ways, through developers' perceptions from surveys and through workflows from system data, because "neither alone can tell the full picture." In its example, "seemingly fast code review turnaround times may still feel disruptive to developers if code reviews regularly interrupt their work progress." For more on interruptions, see our post on context switching.

Measuring developer productivity in practice

A short list of team-level measures, reviewed monthly, plus a quarterly survey is enough to start, and it covers all three frameworks.

Start with delivery and stability

Track DORA's five metrics for each service from your Git history, deploy logs and incident records. Together they show how fast changes reach production and how often they come back.

When lead time grows, split it into stages (coding, waiting for a first review, review rounds, merge and deploy) and look at the longest one first. DORA's guide suggests this kind of leading indicator, for example measuring "how long code reviews take or the quality of your tests."

Watch review load as output grows

When each developer merges twice as many pull requests and each one is bigger, the review queue grows with them. Track PR size and time to first review per team, next to merged PRs, so output that stalls in review shows up. Our guide to pull request metrics covers which ones to pull from GitHub and how to read them.

Note which models and agents the team used in each period you compare. The report found that "new flagship frontier models are quickly adopted within two weeks of release," so the tools behind one month's numbers may differ from the next month's.

Add a developer survey

Run a short survey every quarter. The DevEx paper's example measures translate into questions like these:

• How easy is it to deliver software here?

• How often can you focus without interruptions?

• How satisfied are you with how long tests and CI take?

• How satisfied are you with how long it takes to deploy a change to production?

The paper says "a quarterly or semi-annual survey cadence is optimal for most organizations." Share the results and act on one or two of them, because "a lack of follow-up action commonly causes developers to feel that repeatedly responding to surveys is not a worthwhile exercise."

Use the survey to find friction, and leave speed estimates out of it. METR found that self-reported speedups from AI "can be quite unreliable." Read survey answers next to system data instead. If developers say CI is slow but CI duration looks fine, check queue times and flaky reruns before deciding the complaint is wrong.

A starter scorecard

Rules that keep the numbers honest

• Measure teams and services, not individuals. SPACE says activity metrics should never be used on their own to reward or penalize developers, and DORA's guide warns against using its metrics to compete with other teams.

• Keep metrics in tension. DORA recommends "multiple metrics, including some with a healthy amount of tension between them," so output and speed are always read next to stability.

• Read the trend over a few quarters. One month says little.

• Talk before you build dashboards. DORA lists "focusing on measurement at the expense of improvement" as a pitfall and suggests starting with conversations.

What studies found about AI and developer productivity

The controlled studies disagree because each measured a different task, sample and generation of tools.

Peng et al. is a controlled experiment on a single task, and the paper lists its authors' affiliations as Microsoft Research, GitHub Inc. and MIT Sloan School of Management.

Self-reports and measurements diverged

In the METR study, developers forecast that AI would cut their completion time by 24%, and afterwards estimated that it had cut it by 20%. In its own summary of the study, dated July 10, 2025, METR reports that "when developers use AI tools, they take 19% longer than without." When AI was allowed, they mostly used Cursor Pro with Claude 3.5 and 3.7 Sonnet, the frontier tools of February to June 2025.

Self-reported speed also runs ahead of self-reported value. From February to April 2026, METR surveyed a convenience sample of 349 technical workers, 87 of them software engineers. The median self-reported speed change from AI tools was 3x, while METR's three measures of the value of their work had medians between 1.4x and 2x. METR expects "speed changes would typically overstate value changes," and warns that "survey results are not necessarily grounded in reality."

The tools keep changing

METR's 2025 summary page now says "these results are out of date," and that METR believes they "no longer reflect the current impact of AI models on open-source developer productivity." In February 2026, METR reported on a follow-up that started in August 2025, with 57 developers, 143 repositories and more than 800 tasks. Its raw results showed "some evidence for speedup," but METR called the data "an unreliable signal": more developers declined to take part, or held back tasks, because they did not want to work without AI. METR believes developers are likely "more sped up from AI tools now" than in early 2025, but calls its data "only very weak evidence for the size of this increase," and it is changing the study's design.

Throughput went up, and so did instability

DORA's 2025 report, State of AI-assisted Software Development, drew on survey responses from nearly 5,000 technology professionals, collected between June 13 and July 21, 2025. It found that 90% use AI as part of their work and more than 80% believe it has increased their productivity, while 30% report little to no trust in the code AI generates. AI adoption now improves software delivery throughput, "a key shift from last year," but "it still increases delivery instability."

The report's headline is that AI is "an amplifier" that magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. Without a solid internal platform, clear workflows and aligned teams, it says, "AI creates localized pockets of productivity that are often lost to downstream chaos."

Measure quality next to output

Tracking output alone can make an AI rollout look like a clear win while instability grows, which is the pattern DORA's 2025 report describes. DORA's instability metrics catch it, as more deployments need a rollback or hotfix and more unplanned deployments go out to fix incidents.

Review is one of the last places to catch a bug before it ships, and how many bugs it has to catch varies with the model that wrote the code. Bug Bench, cubic's public benchmark of AI coding models, counts bugs found by cubic's code review in AI-written code that a developer upvoted or an AI coding agent addressed, per AI-attributed line. In Bug Bench's ranking window, Jun 22 to Oct 11, 2026, the relative bug rates of the seven ranked models ranged from 0.65 to 1.50, where 1.00 is the rate across all AI-attributed lines and lower is better. Bug Bench is observational, not causal: teams choose their models, so each rate reflects the code a model was used for as well as the model.

For a productivity program, that means:

• Track bugs caught in review and bugs found after release, per service, next to lead time and merged PRs.

• Hold AI-written code to the same review standard as human-written code. AI code review can take the first pass on every pull request, so the people reviewing can spend their attention on intent and design.

• After any tooling or model change, watch change fail rate and deployment rework rate for a few months, along with throughput.

FAQ

What does developer productivity mean?

It's how well engineers turn their time into working software that users get. The SPACE authors add that it "is about more than an individual's activity levels or the efficiency of the engineering systems relied on to ship software." Developer experience (DevEx) is a narrower idea: the friction developers meet in their daily work, measured through surveys and system data.

Can developer productivity be measured?

Martin Fowler argued in 2003 that it can't, because "we can't measure output." The frameworks that came later work around that by measuring outcomes and experience: delivery speed and stability in DORA, several dimensions at once in SPACE, and friction in DevEx. Ranking individuals by an output count still doesn't work.

Is AI increasing developer productivity?

Output has gone up: in the State of AI coding report, merged PRs per developer doubled between June 2025 and May 2026. Measured speed depends on who uses the tools and where. In Peng et al.'s experiment, developers with less programming experience, older programmers and those who program more hours per day benefited the most. METR's 19% slowdown came from experienced developers in mature projects they knew well, a result METR now calls out of date.

Is the number of commits a good measure of developer productivity?

No. Commit counts change with how people split their work, and SPACE classes them as activity, one of five dimensions. For a team that already counts commits, the paper advises against adding more activity counts such as pull requests and coding time. It suggests a metric from each of two other dimensions instead, "perhaps perception of productivity and pull request merge time."