Developer Productivity: What the Evidence Says

Measuring developer productivity has a long history of measuring the wrong thing confidently. Here is where it actually stands, including the finding most people skip.

The metrics graveyard

Lines of code. Dead for decades. Rewarded verbosity, punished deletion, and AI finished it off: LOC now measures how much you let a model type.

Commits and pull requests per week. Held up reasonably until AI-assisted workflows inflated volume without moving value. Fifteen small AI-drafted PRs are not obviously more than three considered ones.

Story points. Never measured reality. They measure a team's shared social estimate, which is useful for planning and worthless in retrospect.

Velocity. Story points with a trend line.

The sensible response was to stop looking for one number. DORA covers delivery: deployment frequency, lead time, change failure rate, recovery time. SPACE adds satisfaction, performance, activity, communication and efficiency. DX Core 4 consolidates. The consensus is that you need at least three dimensions and no single metric survives alone.

All of that is correct. All of it is about teams over quarters.

The finding people skip

Here is the uncomfortable part, and it is the most rigorous evidence in the whole area.

In 2025, METR ran a randomised controlled trial on sixteen experienced open-source developers. Real issues from their own backlogs, on mature repositories they knew well. Each task randomly assigned to allow or forbid AI tools.

Before starting, they predicted AI would make them 24% faster.

Afterwards, having done the work, they estimated it had made them 20% faster.

They were 19% slower.

The estimate barely moved after living through it. That is roughly a forty percentage point error about work they had just personally finished, by people paying close attention, on their own code.

To establish what actually happened, the researchers recorded screens and hand-reviewed 143 hours of video.

What that implies

Self-reported productivity data is close to worthless. Surveys asking developers whether a tool helped will report that it helped. METR's 2026 follow-up found a median self-reported 3x speedup from AI while reported value gain was 1.4x to 2x, and they are explicit that speed estimates run high because people drift toward tasks AI does fast regardless of whether those tasks matter.

Your own read on your week is not evidence either. Not because you are careless, but because everyone's is wrong in the same direction.

Anything downstream of self-report inherits the error. That includes most retros, most tool-adoption decisions, and most personal conclusions about what makes you effective.

What survives at the individual level

DORA and SPACE need scale and time. Neither helps you on a Wednesday. At n=1, three things hold up.

Longest unbroken block. The single best proxy for whether real thinking happened. Programming has a re-entry cost that nothing else on a calendar reflects, and a day of eleven fragments produces much less than its hours suggest.

Number of distinct contexts. Rising context count with flat hours means depth traded for volume.

Where your good hours went. Most people have two or three genuinely effective hours. Whether those went to the hard problem or to standup is the highest-leverage fact about your week, and it is knowable.

None of these are performance scores. They are diagnostics, and that distinction matters: the moment a time measure becomes a score it gets gamed, including by yourself.

The 2026 complication

There is a newer problem specific to how people work now.

When you run several agents concurrently, time-on-task stops being well defined. METR notes exactly this: measurements are unreliable for the growing fraction of developers running multiple agents. You kick off a refactor, switch to a second worktree, review the first, rewrite a prompt. How much time went to the refactor? Your editor was focused for eleven minutes. The refactor took forty minutes of wall clock and perhaps six of attention.

Every tracker on the market, ours included, measures the foreground window. That assumption is now weaker than it was, and we wrote about it honestly here rather than claiming to have solved it.

What to actually do

Measure, do not estimate. That is the entire lesson of the METR result and it generalises past AI.

Diagnose, do not score. Use the numbers to notice that your mornings are gone, not to rate yourself.

Protect the block before optimising the tools. Longest unbroken block moves more than any editor configuration will.

Be suspicious of anything that felt fast. Especially your own conclusions about what makes you effective.

Cronus Interface

Cronus exists for the n=1 version of this. It records which app and window you are in and works out what the time served, judged against goals you set once. No timers, nothing to log. You get the three numbers above without maintaining anything.

What it is not: a management tool. There are no team dashboards, no comparisons between people, and we are not going to build them. Individual time data handed to a manager stops being a diagnostic and becomes a score, and the moment that happens it is gamed and worthless. It is $6 a month after a three-day trial, and it never captures your screen.