Measuring developer experience when a machine writes some of the code

The SPACE framework is seven years old. DORA’s four keys are older. Both were built on an assumption so obvious at the time that nobody wrote it down: that a person types the code, and the rate at which code appears is therefore bounded by human effort.

That assumption is now partly false, and the useful question is not whether these frameworks are obsolete. Mostly they are not. It is which specific parts stop working, because the answer is uneven and the uneven bits are where people are currently fooling themselves.

Here is my current read, dimension by dimension. I have been wrong about some of this before and expect to be wrong about some of it again.

Activity: was weak, is now inverted

SPACE’s authors were explicit that Activity - commits, pull requests, lines changed - is the weakest of the five and must never be used alone. That was already true when a person typed everything.

With AI assistance it is worse than weak. It is anti-correlated with the thing you care about, in a specific and predictable way.

An assistant can produce a large, plausible, well-formatted change very quickly. It is particularly good at producing large changes, because generating more is cheaper than deciding what not to generate. Left unguided it will add backwards-compatibility shims to a module that has existed for ten minutes, write tests that assert the implementation rather than the behaviour, and restate the same logic in three places.

Every one of those inflates Activity. Several of them reduce the value of the change. So a metric that was previously noisy is now pointed in the wrong direction: the sessions that generate the most code are disproportionately the ones where nobody was steering.

If you measure one thing and it is Activity, AI assistance will make your numbers improve while your codebase gets worse. This is the single most likely way for an engineering organisation to mislead itself in 2026.

Efficiency and flow: broken in an interesting way

Flow metrics assume that elapsed time is a reasonable proxy for effort - you start, you work, you finish, and the clock roughly tracks the work.

That breaks with agentic tooling, and I can show you how with our own data rather than asserting it.

Across 29 human coding sessions on a single repository in September 2026, the median session ran 65.7 minutes. The mean ran 291.6 minutes - four and a half times the median. The longest session started at 09:09 on the 4th of September and ended at 03:37 on the 8th.

Three days and eighteen hours. Obviously nobody worked for three days and eighteen hours. The session stayed open: you set something running, you go and do something else, you come back the next morning and carry on in the same conversation. The clock never stopped because nothing told it to.

Two things follow. The smaller one is that mean session duration is now a meaningless statistic and you should look at the median, or better, stop reporting duration at all. The larger one is that the concept of an uninterrupted block of focused work - the thing flow metrics were invented to protect - has a new shape. The interruption is no longer a colleague tapping your shoulder. It is a four-minute gap while an agent works, which is too short to context-switch into anything else and too long to sit and watch.

I do not think anybody has a good measure for that yet. I certainly do not. Twenty-nine sessions on one repository is an observation, not a finding, and I would not build a dashboard on it.

Performance: holds up, and gets more important

Performance in SPACE means outcome - did the thing work, did it do what customers needed. DORA’s change failure rate and time to restore are the same instinct.

This is the dimension least disturbed by AI assistance, for the straightforward reason that it never cared who or what produced the change. A broken deployment is broken whoever wrote it.

It also becomes load-bearing in a way it was not before. When Activity was merely noisy you could triangulate across dimensions. Now that Activity is actively misleading, outcome measures are carrying more of the weight, and the gap between “work happened” and “work shipped and held up” is the gap that matters.

This is the reasoning behind measuring effort against confirmed outcome rather than against volume - and the reason effort scoring is deliberately not called value scoring. Effort tells you what a change cost. Only a production outcome tells you whether it was worth it.

The shape that is actually worth watching is an effort measure tracked against headcount, in one organisation, over months:

Note what this comparison deliberately is not. It is one organisation against its own past, scored the same way throughout. Effort measures are not comparable between organisations - too much of the score depends on how a codebase happens to be laid out - so a percentile rank against other companies would be close to meaningless. Against your own previous quarter, the distortions are roughly constant and largely cancel, which is what makes the trend line readable at all.

Satisfaction and well-being: holds, but the questions need rewriting

Ask people how they are and whether they have what they need. That still works. Surveys were never fooled by AI-generated volume because they were never counting anything.

What has changed is that some standard questions now mean something different, and a few have quietly stopped making sense:

• “Do you have the tools you need to do your job?” now conflates having a licence with the tool being any good, and with the organisation having worked out how to use it. Three very different problems, one answer.
• “Do you have enough uninterrupted time for deep work?” is being answered against the new interruption pattern above, which respondents will interpret inconsistently because nobody has named it yet.
• Nothing standard asks about the thing I hear most in conversation, which is the specific fatigue of reviewing code you did not write, at volume, under the assumption that it is probably fine.

If you run SPACE surveys - and you should, they remain the cheapest instrument in this whole field - it is worth revisiting the wording. See our practical guide to implementing SPACE for the mechanics.

Communication and collaboration: shifting, not breaking

The work is moving rather than disappearing. When generation gets cheaper and review does not, review becomes the constraint. That is a collaboration problem wearing a throughput costume, and it shows up as reviewer load concentrating on a small number of people, and as review latency rising while authoring latency falls.

Measure the ratio rather than either side alone. Time from open to first review, against time from first commit to open. If the first is growing while the second shrinks, generation has outrun your capacity to check it, which is the code review bottleneck in its current form.

So what should you actually do

Shorter than the above, and mostly subtraction:

1. Stop reporting Activity as a headline. Keep it for diagnosis if you like. Never put it on a slide with an arrow.
2. Stop reporting mean durations. Use medians, and be suspicious of any time-denominated metric on agentic work.
3. Move weight onto outcome. Change failure rate, time to restore, and whether a change survived contact with production.
4. Keep surveying, and rewrite the questions. The instrument is fine; the wording assumes a world that has moved.
5. Watch the review-to-authoring ratio. It is where the constraint went.

None of this requires abandoning DORA or SPACE. Both were designed by people who said clearly that no single measure should be trusted alone, and the current moment is mostly a very expensive demonstration of why they said it.

What I do not know

Whether “active time” can be extracted from an agentic session transcript in a way that is consistent across tools. The turn boundaries are in the data, so it ought to be tractable, and I suspect the hard part is agreeing a definition of active rather than computing it.

Whether review fatigue is measurable at all without asking people directly, and whether asking directly gets you an honest answer.

If you have looked at your own numbers and found something different - particularly if you have found Activity still behaving itself - I would genuinely like to hear about it. I am on LinkedIn, and there is more on the agentic engineering side of this on my own blog.

---

GuideMode measures delivery outcomes and AI session quality together, across a team. See how it works.