the developer productivity illusion

imagine this scenario: a team 2x's the number of PRs they produce because of AI, but merge times get worse. the productivity metrics show throughput is up, cycle time is down. depending on which metric you look at, the team is either dramatically more productive, or falling behind.

coding agents make it dramatically easier to produce a change but reviewing it, testing it, and deciding whether it even belongs, still take attention.

building software has changed, and how we measure developer productivity needs to change with it.

agents make it easier to start than to finish

engineering leadership tends to watch metrics like PR throughput, cycle time, deployment frequency, etc. when throughput goes up but cycle time gets worse, the instinct is to automate harder.

but higher throughput doesn't necessarily mean faster delivery. the missing piece is how much work is happening in parallel. little's law captures the relationship between these metrics.

work in progress = throughput × cycle time

a team can merge substantially more PRs while still taking longer to merge each one, simply because work in progress is growing faster than throughput.

if we produce PRs faster than we merge them, the queue keeps growing. without backpressure on starting work, we shouldn't be surprised when cycle time gets worse. agents make starting work cheap but they don't give everyone reviewing it more hours in the day.

we used to treat implementation capacity as the bottleneck. agents are making that assumption less reliable. producing a change is getting cheaper, but the capacity to understand changes, make decisions, and absorb complexity hasn't grown at the same rate. optimizing for the old bottleneck can make the new one worse.

productivity dashboard paradox

productivity metrics with benchmarks tell you where your numbers differ from other companies, but they don't tell you whether that difference is a problem worth solving, and why the gaps exist.

maybe reviews are slow because approvals are unnecessary. maybe they're catching expensive mistakes. maybe your team has started too much work and attention is divided. the same number can call for very different mitigation strategies.

a narrow view of productivity makes it easy to optimize a vanity metric. you could automate every review to improve cycle time, then spend the next week fixing what slipped through. DX will show improvement but the actual work gets harder.

measuring productivity takes investigation and judgement. leaving that entirely to DX, or any dashboard, doesn't get you out of doing that work.

the magic is in what you're not doing

higher throughput and longer cycle times might be a tradeoff you're happy with. if you're shipping more useful changes and the wait isn't hurting anyone, does cycle time need fixing?

if the delays are a problem, look at what can be removed. reduce required reviews for low-risk changes. automate routine/mechanical checks. stop starting more work than you can finish. an input must be reduced somewhere.

the magic is in what you're not doing. every new PR asks for attention, even when producing it costs almost nothing.

when you can work on a thousand things, choosing what deserves your attention becomes more of the job.

engineering leaders should ask their teams to start less, finish more, and be deliberate about what deserves to exist.