The Productivity-Experience Paradox

This is the second post in a series I’m writing about the most interesting findings from my Masters research on the impact of AI on software engineering, as well as some of the thoughts I’ve had since. This one is about how AI made engineers feel more productive, and why that productivity might be masking something we should care about.

The first post, The Middle Loop, focused on my first research question - where engineers spend their time and focus when they use AI to build software. The short answer is less time on most core development tasks, especially writing code, and slightly more time reviewing. The longer answer includes evidence of a new category of work, supervisory engineering work, sitting neatly between the inner and outer loops of software development.

This post is more about how that shift feels, which was the focus of my second research question - how does the use of AI coding assistants impact software engineers’ perceptions of their developer experience and productivity?

I described the study in that last post so I won’t repeat it all here. It’s worth noting that my study ran between October 2024 and April 2025, which in AI terms is already quite a long time ago. The landscape has shifted a lot since then, so it’s best read as a snapshot of that window. If you’re interested in a more detailed write-up of the methodology and results of these first two research questions, there’s a preprint paper available.

Measuring the feeling

Measuring productivity is tricky. For starters, as an industry, we can’t really agree on what it even means, let alone how to measure it well. DORA defined it as “the extent to which an individual feels effective and efficient in their work, creating value and achieving tasks.” in their 2024 Accelerate State of DevOps report, and that sounds about right to me.

Notice how they used the word feels? In that definition, productivity is already a perception, so I did the straightforward thing and asked participants to rate how their productivity had changed since using an AI coding assistant. Open-ended questions let them describe their experiences in their own words, which is where the participant quotes in this post come from.

For developer experience I needed more structure, so I used the DevEx framework. It takes the fuzzy notion of how development work feels and splits it into three dimensions we can better reason about:

• Feedback loops: how fast, and how useful, the responses to your work are, whether from a compiler, a test, code review, or a colleague.
• Cognitive load: the mental effort it takes to get something done.
• Flow state: how seamlessly you can work and hold your concentration, free from interruptions.

I chose it for a few reasons. It’s the framework the industry has actually adopted (with entire DevEx teams built on the concept) largely because those three dimensions are concrete enough to operationalise where more comprehensive taxonomies aren’t. And there hadn’t been much research tracking how professional developers’ sense of these three dimensions shifted with sustained use of AI, which felt worth examining more closely.

Productivity went up - and stayed up

Productivity was the good news, and it stayed good news over the six-month study period. It was remarkably stable - 84% of participants reported AI improving their productivity at both timepoints. More than three-quarters of matched participants gave the exact same positive rating both times. Whatever else was going on, people felt like they were getting more done.

Developer experience drifted the other way

Developer experience is the more complicated half of the story. Most engineers were still doing fine but a growing minority weren’t, and the positive group appeared to be thinning out over time. To see how it was playing out, I sorted the matched participants into three groups based on how they felt AI had affected those three DevEx dimensions: a positive cohort who felt it had improved all three, a negative cohort who felt it had worsened at least one, and a mixed group in between - nothing worse, but not everything better either. Then I tracked how people moved between them over the six months.

The negative cohort nearly doubled, from 14% to 27%, and the positive cohort barely held. Only 37% of those who started there were still fully positive by the end. Engineers are feeling like they’re getting more done but are feeling worse doing it.

The negative cohort was quite sticky, too. Not one person who started in it climbed all the way back to fully positive; the best any of them managed was to claw back to neutral. But basically, once the experience soured, it tended to stay that way.

When viewed next to the chart above, you can see how productivity and developer experience appear to be diverging. Output is holding high and steady while the experience underneath begins to erode.

The coupling we took for granted

For a long time, research has told us that developer experience and productivity are related - that they travel together. That’s the core premise behind the DevEx framework, and the reason leaders have been told to focus on improving developer experience: improve that, and productivity will follow.

There’s something quite humane in that premise. It meant caring about engineers’ day-to-day lives wasn’t a trade-off against output. It was the output strategy. You didn’t have to choose between treating people well and getting results. The incentives lined up.

Unfortunately, this is exactly the coupling my data suggests may be breaking once AI enters the picture.

Interestingly, whether they move together depends on how you look at it. Compare engineers at a single point in time and they do. The ones with better developer experience also feel more productive. But follow the same engineer over the six months, and a dip in their experience wasn’t matched by a dip in their productivity. The correlation between change in flow state and change in productivity came out at 0.02, about as close to zero as it gets. And that’s the paradox: over time, with AI, developer experience and productivity appear to stop moving together.

What this means for engineers

If experience and productivity really are decoupling with AI, will leaders still be able to justify caring about developer experience? I really hope so, but the case for investing in it was always that it paid off in output, and that’s exactly what’s now up for debate. In fact, we’re already seeing attention (and investment) shift toward agent experience: engineering better context and harnesses so the models themselves work more effectively. And if the returns now come from improving how the agents work rather than how the engineers feel, what happens to the human engineers?

Well, when their experience keeps eroding but their output doesn’t, nothing forces the problem to the surface. The dashboards look fine, but the people aren’t. But that hidden strain doesn’t just vanish. Where does it go, you might ask. You know where. Burnout and turnover, that’s where. It’s why Steve Yegge calls it the AI vampire - the tool that makes you far more productive while draining you dry.

Three dimensions, pulling in different directions

So what’s actually driving the decline? Developer experience didn’t deteriorate evenly across the three dimensions - one of them took the brunt of the hit while another actually improved.

Flow state took the steepest fall. The share rating it worse nearly tripled over the six months, from 7% to 20%, by far the biggest move of the three. One participant named it exactly: “less ‘in the zone’ time, because while code is being produced, I now find myself switching context more often.”

Cognitive load got worse too, though far more gently. Those rating it worse crept up from 6% to 9%. This is the part the demos don’t show you: the constant evaluation, the “almost right but not quite” suggestion that costs more to check and fix than it would have to just write yourself.

Feedback loops got better. This was the only dimension that improved over the study period. Makes sense too - now you can ask your AI coding assistant for help and have a working solution back in seconds. Gone are the days of hunting around on Stack Overflow for hours.

I do wonder if there might be a connection between feedback loops improving and flow state deteriorating. Think about it. AI now hands you a response every few seconds, but every response is a whole bunch of text and a little decision: read it, judge it, accept it or fix it, then prompt again. It’s a context switch, over and over, and it’s hard to stay in the zone when you’re switching gears that often. One participant put it quite succinctly: “This does break the flow, but still speeds up the overall process.” You feel faster, but more interrupted, both true at once.

Counterfeit flow

Since flow state took the hardest hit, it’s worth asking why. Orchestrating agents, or supervisory engineering work, can feel great: you’re moving faster, reaching further and achieving more with less. There’s almost a nice rhythm to it; the problem is that that feeling and real flow aren’t necessarily the same thing.

Jeremy Howard described what that feeling might really be. He pointed out that Mihály Csikszentmihalyi, the psychologist who gave us the idea of flow, also described a counterfeit cousin of it: junk flow, or dark flow. It can look a lot like the real thing, but it’s the opposite of good for you: you get hooked on a superficial version that feels like flow at first, then slowly turns into something you’re addicted to rather than something that helps you grow.

So what separates the two? Real flow is when a genuine challenge stretches your skills and you grow from it. Junk flow just keeps you pulling the lever. Prompting an AI can feel a lot like pulling that lever - sometimes it nails it, sometimes it hands you nonsense - but you keep going, chasing the next good result, even when you know you should probably just stop and do it by hand. The dopamine’s more in the anticipation than the payoff.

Output is one thing, the craft is another

I think that concept also fits my data quite nicely. With AI, the external good, productivity, holds steady or climbs. The internal goods - flow, mastery, the joy of the craft - erode. AI is brilliant for the external goods and potentially corrosive for the internal ones.

How you feel about AI has a lot to do with which of these goods you’re chasing. If it’s the external goods you’re after, this technology is close to a superpower - more productivity, more output. But if you’re more interested in the internal goods - the figuring-out, the hours inside a hard problem - then it can really feel like a loss: it takes the part you loved and hands it to a machine, and what’s left is supervision and accountability. Yes, the output still arrives, faster than ever, but the bit that made it yours has been delegated away, and the pride and satisfaction of having done it yourself are gone.

Designing what comes next

So what do we do with a finding like this? The instinct is to fix it, to stop the bleeding with better tooling that supports developer experience in this new world.

But if the craft is genuinely relocating - if the making is moving into orchestration - then the job is to define the new role and design it to be worth doing. That’s the argument behind a keynote I gave last month at that same AI Engineer conference, Craft in the Time of Agents: craft isn’t dying, it’s moving. And if the system is producing more output while eroding the joy and lived experience of being a software engineer, that’s a system-design problem, not a personal failing, and it’s ours to solve, deliberately, by building the roles people actually want to grow into.

Which leads me to a bigger question. Do the frameworks we’ve used to talk about developer experience in the before-times still hold with AI in the mix? Maybe they need rethinking, or maybe they need replacing altogether. They were built for a world where a developer’s work revolved around the production of working code.

When code production is increasingly a machine’s job, and the human work is more about specification, judgement and verification, those constructs are measuring a job that’s materially different. Some of what I found - the supervisory engineering work, the productivity-experience paradox, the way “feeling productive” detached from flow - doesn’t sit neatly inside the frameworks we have.

I think developer experience is starting to mean something different, and the ways we frame and measure it need to catch up.