The Productivity-Experience Paradox

• July 21, 2026

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 created by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler. 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. It’s Deming’s 12th point made real, a call to “remove barriers that rob people in management and in engineering of their right to pride of workmanship.”

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.

Brian Houck, a Distinguished Scientist at DX who researches developer experience and co-authored the SPACE framework, thought the decoupling interesting enough to write about it and talk about it on the DX podcast. Having someone of his calibre take my finding that seriously is something I’m super excited about.

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. One participant described work that would have taken three days getting done in three 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.

Something else moved over those six months too. At the first timepoint, the dimension that lined up most closely with feeling productive was flow state. By the second timepoint, it was the speed of the feedback loop, and flow state had almost dropped out of the picture. In other words, as AI took over more of the writing, what made engineers feel productive seems to have changed: at the start it went with being absorbed in a hard problem, and by the end it went with how fast the code came back.

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.

In his keynote at AI Engineer in Melbourne, right before mine, 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. And it’s no accident - casinos are designed to manufacture exactly this, hooking people through what’s called an illusion of control.

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. We’ve all been there.

Output is one thing, the craft is another

At AI Engineer, I happened to meet Nicholas Gruen, who spoke to me about a philosopher called Alasdair MacIntyre. In particular, what Nicholas thought I might find interesting was MacIntyre’s framing of the internal goods of a practice - the skill, the mastery, the satisfaction you can only get by doing the thing itself - and external goods - money, status, output. MacIntyre warned that the external goods, the ones institutions trade in, have a habit of crowding out the internal ones. I’m really grateful to Nicholas for the introduction to his work - it gave me a much richer way to think about what I’d been seeing.

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. It’s this loss I was afraid of when I wrote about the software engineering identity crisis last year, and now it’s starting to show up in the data.

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. Flow meant being deep in the problem-solving, and often that meant building it yourself. Cognitive load meant holding a mental model of the solution in your own head, and feedback loops meant how quickly you could unblock yourself and get on to the next piece.

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.

Others are starting to wonder the same thing. Thoughtworks’ Ken Mugrage recently asked whether developer experience is dead, and landed where I have: not dead, but overdue for a rethink.

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

In November I’m heading to another Shonan meeting in Japan built around exactly this, an academic gathering with the working title “Crafting the Future of Developer Experience”, and some of the people in that room helped build the frameworks we’re now questioning. I know I don’t have all the answers, but those are definitely the conversations I want to be in.

This post draws on my Masters research at the University of Auckland, supervised by Kelly Blincoe. A preprint paper covers the first two of the study’s research questions: how does AI shift software engineers’ perceived focus across development tasks, which I wrote about in The Middle Loop, and how does AI impact software engineers’ perceptions of their developer experience and productivity, which is this post. There’s more to come on the study’s other two questions - what AI is doing to how engineers grow their skills and confidence, and whether prompt engineering is (or was) becoming a core skill in its own right.