Research brief
What is the productivity-experience gap?
The productivity-experience gap is the distance between what output metrics show and what the work asked of the people doing it. In AI-assisted engineering, the shape of the work can change a great deal while the delivery numbers barely move. The gap is that change going unread.
Key takeaways
- Output metrics describe what shipped. They say little about what the work asked of the people who shipped it.
- How fast AI-assisted work feels and how fast it measures can differ. A 2025 randomised trial by METR found exactly that mismatch in experienced developers.
- Closing the gap means reading two things side by side: how the work ran, from the tools, and how it landed, from the people.
- Neither side is enough alone. Ascenda reports both in aggregate, never as an individual view.
Why does the gap open with AI-assisted engineering?
AI changes the shape of effort, not just its volume. Time once spent writing code moves into directing agents, reviewing what they produce and deciding what can be trusted. Engineers may run several sessions at once and switch between them. Story points, cycle time and merge counts keep moving through all of this, so the change doesn't show up where most teams look.
Feeling faster and being faster are different questions
One of the clearest published examples comes from METR. In a 2025 randomised controlled trial, experienced open-source developers worked on real issues in repositories they knew well, with AI tools allowed on some tasks and not on others. Tasks with AI allowed took longer on average, yet the developers believed afterwards that the tools had sped them up (Becker et al., 2025). The authors are careful about how far the result generalises to other settings and newer tools, and so are we.
What is worth reading on each side?
How the work ran. Hands-on versus supervising time, sessions in flight, context and project switching, focus blocks, interventions such as permission prompts, failures and rework, and after-hours share. These can be read from the AI tools engineers already use.
How it landed. This part can't be read from tools. It has to come from the people doing the work: whether they felt strained or clear, drained or activated, and how confident they were in what they shipped.
How Ascenda approaches it
Flow reads how much the work asked from the tools you already use. What it can't read, it asks you: how it felt. Organisations see both in aggregate, never below ten people and never as an individual view, as a direction against the group's own baseline rather than a score. An organisation's own delivery figures can sit beside that readout as its own statement.
To act on it, the organisation declares a change before making it: the change, the measure, the baseline and the window. The readout is reported whichever way it goes. The organisations page explains how this works in practice.
Frequently asked questions
- What is the productivity-experience gap?
- It is the distance between what output metrics show and what the work asked of the people doing it. Delivery figures can hold steady while the work itself changes shape: more steering and checking of AI output, more sessions in flight, more switching between them. The gap is that difference going unread.
- Why does it matter for AI engineering productivity?
- Because AI changes the shape of engineering work, not just its speed. If you only read output, you can't tell whether a way of working holds up for the people doing it. Reading the work and the people's own account side by side is how you find out.
- Doesn't faster output mean AI is working?
- Not necessarily, and perceived speed is not the same as measured speed. In METR's 2025 randomised trial, experienced open-source developers took longer on tasks where AI tools were allowed, while believing the tools had made them faster. The point is that neither impressions nor a single output number settles the question.
- Is the productivity-experience gap the same as burnout?
- No. It describes a mismatch between two kinds of measure, not a condition in a person. People tell us how the work felt, in their own words and on their own terms.
- Can you measure it from tool data alone?
- Only half of it. Tool data can show how the work ran: hands-on versus supervising time, concurrent sessions, switching, interventions, failures and rework. How the work landed can only come from the people doing it, which is why Flow asks rather than infers.
- How do organisations act on it?
- By declaring a change before making it: what will change, which measure it should move, the baseline and the window. The baseline freezes, and the readout is reported whichever way it goes. A cause is named only when the rollout was designed to show one.
Sources
- Becker, J., Rush, N., Barnes, E. and Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR.