The productivity pitch for AI coding tools is simple: write less, ship faster. By most surface measures, it is working. Stack Overflow’s 2025 developer survey puts adoption at 84% of developers using or planning to use AI tools, up from 76% the year before. The tools are useful.
But something has quietly changed about how developers work, and I haven’t seen a ton of discussion on it, yet.
The prompt-and-wait loop
Flow state in software development is not just being “in the zone.” It has a specific cognitive structure. A developer holds a large mental model in working memory: the system, the problem, the constraints, the edge cases. They reason through that model continuously. Sustained engagement is where the hard problems get solved.
AI tools interrupt that loop structurally. The workflow now looks like this: frame a problem, write a prompt, wait, review output, correct or accept, repeat. The wait is the issue. It is not neutral time. It is an invitation to disengage: check Slack, glance at another tab, look at another PR.
Sophie Leroy’s research on attention residue names the mechanism. When attention partially leaves a task, part of it stays behind. Cognitive resources for the current task drop, and the effect is largest on demanding work. That is exactly what flow state is built for.
The data backs this up. A 2025 randomized controlled trial run by METR on experienced open-source developers found that AI tools made tasks take 19% longer. The same developers, after the study, believed AI had sped them up by 20%. They were not bad at their jobs. They were experienced engineers working on their own codebases. The mental model was deteriorating underneath them while the work felt faster.
Where the gaps go
The prompt-and-wait habit doesn’t stay contained. Once a developer learns that “waiting” is a normal part of the workflow, the wait gets filled. The tab switch becomes a task switch. The task switch becomes a second active project. The second project becomes normal.
This is where the multi-project problem comes from. Not from individual undiscipline, but from a tooling pattern that makes shallow engagement feel like productivity. The vendors have noticed. GitHub now ships features designed specifically to let one developer drive multiple agents in parallel, with status panels for “working / waiting / done.” The assumption baked in is that a developer’s job is to dispatch and supervise, not to think continuously. Whether the work is actually better for it is a different question.
The longer-term effect is harder to see in a quarter. A 2026 randomized controlled trial by Anthropic researchers had 52 mostly-junior engineers learn an unfamiliar Python library, half with AI assistance and half without. The AI group scored 17 percentage points lower on a comprehension quiz covering concepts they had used minutes earlier. They shipped working code. They could not explain it. The researchers’ framing was blunt: “AI-enhanced productivity is not a shortcut to competence.”
Flow state demands a specific kind of cognitive work: holding a system in your head and reasoning through it. That is the same work that builds the engineer who debugs production at 2am. When the work gets outsourced, the engineer does not get built.
What some teams are trying
I haven’t found the silver bullet here.
Some developers have started treating the wait deliberately. Instead of switching contexts during the gap, they use it to articulate what they expect the output to look like before they read it. Edge cases, failure modes, what “wrong” would look like. It is a small discipline. It keeps the mental model active rather than outsourcing it entirely.
Others are experimenting with structured separation: focused blocks for reasoning and review, separate from AI-assisted generation. The cognitive demands are different enough that mixing them constantly degrades both.
At the team level, some engineering managers are starting to treat AI-enabled multi-project staffing as a debt they are taking on rather than a free efficiency gain. The tool makes it feel feasible to spread a developer across three engagements. Whether the depth holds up is a different question, and it usually surfaces later, when something breaks.
None of these are settled practice. They are experiments, and the tradeoffs are real. A developer who refuses to context-switch is not necessarily more productive in a world where stakeholders expect responsiveness. The point is not to reject the tooling. It is to be deliberate about what the tooling is doing to the work.
A closing thought
The AI coding tools aren’t going anywhere, and that’s fine. The velocity gains on defined, well-scoped tasks are real. The problem is the assumption that adopting them doesn’t require changing anything else about how a team works.
The developers and engineering leaders paying attention right now are asking a harder question. Not just are we shipping faster, but are we thinking as well as we used to. Those are not always the same thing.
We are in unprecedented items and learning as we go. Let’s hang on and figure it out together.