AI: The Illusion of Productivity - The Flow State Problem

In the first article of this series, AI: The Illusion of Productivity, we explored the gap between feeling productive with AI and actually being productive. This time, we turn to what lies beneath that gap: the flow-state problem. Reviewing AI-generated code demands more focused attention than writing code, yet the rhythm of interacting with AI through a chat interface makes that attention difficult to sustain.

***

Developers spend years learning to protect a specific cognitive state, call it flow, call it the zone, because it's the state in which complex reasoning is actually possible. Reviewing AI-generated code needs more of that state, not less, because all the reasoning that would normally happen through the act of writing now has to happen through evaluation alone. And the rhythm of AI chat interactionis close to structurally incompatible with the state review requires.

Until AI entered the picture, we have been taught that being in the flow is our holy productivity technique for developers, almost our whole professional identity. Hours disappearing into a hard problem, the quiet click of a solution finally coming together, the feeling of being fully absorbed in something that mattered: that was, for most of a career, what it meant to be good at this job. Learning to protect that state (building the habits, the environment, the discipline to reach it reliably) was as much a part of becoming a senior developer as learning any language or framework. Asking someone to now work in a fundamentally different rhythm, one built around constant prompting, reviewing, and re-prompting, means asking them to go against instincts built up over an entire career, and that can be genuinely painful, because the shift asks people to unlearn something that used to define whether they were good at their job at all. This isn't stubbornness about new tools.

This isn't a soft claim about needing quiet to concentrate. Cal Newport's deep work framework treats sustained, uninterrupted concentration as a functional requirement for cognitively demanding tasks, not a preference. In software specifically, holding a complete mental model of a codebase in working memory is the precondition for judging whether any given change to it is actually correct, and that's a heavy thing to hold. It's closer to carrying the blueprint of a large, half-familiar building in your head: which room connects to which, where the load-bearing walls actually are, which door looks fine but opens onto a drop. Lose focus, and that blueprint doesn't just fade a little at the edges. It evaporates. Getting it back means rebuilding the whole structure in your head from scratch, room by room, before you can safely judge whether a change anywhere in it is sound. A glance at a note won't do it.

Interruption has a real, measured cost. Research by Gloria Mark at UC Irvine puts the average time to fully regain deep focus after a single disruption at 23 minutes and 15 seconds. Every prompt-response cycle in an AI chat is a potential instance of that disruption: the wait for a reply, the shift into evaluating what came back, the re-entry into the problem. None of it is free, even when it feels instantaneous.

The interaction itself is built around a shallow rhythm: prompt, review, adjust, re-prompt. That loop is optimised for responsiveness and iteration speed, not depth. It keeps you in a state of continuous partial attention: aware of what the agent produced, waiting on the next response, never fully back inside the problem. Which is basically the opposite of the state a careful code review actually needs.

It's tempting to think this doesn't apply once you move to longer-running, more autonomous agent loops, the kind that work for twenty minutes or an hour without you in the chat at all. But that isn't a fire-and-forget arrangement either. The less you're interrupted moment to moment, the more the cost concentrates at the two ends of the loop instead: the upfront specification has to be dramatically more complete, because there's no back-and-forth left to catch a wrong assumption early, and the review at the end has to cover a correspondingly larger, less familiar diff in one sitting. Autonomy just batches the cost of the shallow rhythm: you pay less often, and more, at each end of a longer loop.

And review, done properly, is one of the more demanding things a developer does. When you write code yourself, the writing is a form of reasoning: you build the solution and your understanding of it at the same time. When you review someone else's code (or something else's), all of that reasoning has to happen in your head, without the scaffold that writing provides. It asks for more focus than authoring the code directly, not less. Do it in a state of continuous partial attention, and you will reliably miss things.

Stack Overflow's 2025 Developer Survey (nearly 50,000 respondents) captured this tension almost exactly. Developers reported feeling genuinely empowered by AI: able to build more, experiment more. At the same time, 45% named "AI solutions that are almost right, but not quite" as their single biggest frustration with these tools, and tellingly, 66% said they were now spending more time fixing that same kind of almost-right code than they would have spent just writing it themselves: two measures of the same problem. Trust told a related story from a different angle: 33% said they trust AI output to be accurate, against 46% who actively distrust it. That gap, feeling empowered while trusting less, is what a review happening below the necessary cognitive threshold looks like from the inside.

The zone was never only about performance, it's about the feeling of genuinely understanding what you're building. Developers who've spent years cultivating that state know the difference between working in a problem and working around it. AI chat tends to keep you around it, even when you believe you're squarely engaged with it. The uncomfortable part is that it can feel fine. Working around a problem is, itself, a kind of comfort.

This is where the first friction from my own experiment belongs. The unpredictable confirmation requests (no consistent logic for why this decision needed my sign-off and the last one didn't) turned out to be a particularly corrosive version of the interruption problem. Beyond the 23-minute cost of each actual interruption, I started staying in a state of continuous partial attention in anticipation of the next unexplained one. I paid the tax even during the stretches when nothing was actually interrupting me.

And this connects back to the previous article - AI: The illusion of productivity - The attention quality problem - in a way I think matters: the same developer who couldn't fully externalise their expert knowledge into a prompt is now the one evaluating the output of that impoverished prompt, in a cognitive state the interaction model has already worn down. Both ends of the exchange are compromised at once.

There's a further escalation available here, though, and it's the one my second friction (the review loop that wouldn't converge) actually belongs to. What happens when you stop running one agent, and start running several at once?

***

This is the second article in the AI: The Illusion of Productivity series. Part three comes out on September 15: we’ll explore what happens when a developer moves from running a single agent to running several at once. Working with multiple agents in parallel increases cognitive demand, amplifying both the attention-quality problem and the flow-state problem explored in the first two articles.

***

We wrote this article with the support of AI. If you’re interested in how we use these tools as part of our writing process, you can read more here.

***

Linkography

• Cal Newport, Deep Work: Rules for Focused Success in a Distracted World (Grand Central Publishing, 2016) — See calnewport.com for the author's related writing

• Gloria Mark, Victor Gonzalez & Justin Harris, The Cost of Interrupted Work: More Speed and Stress (CHI 2008)

• Stack Overflow, 2025 Developer Survey — AI

Cover image:
Photo by Igor Omilaev su Unsplash