AI: The illusion of productivity - The attention quality problem

For months, the Nephila team has been running a series of experiments with agentic coding. This work has led to some insights worth sharing, as they touch on a central issue in the current debate around AI and developer productivity.

This is the first article in a four-part series exploring AI’s real impact on software development, which we’ll publish throughout September. Starting with the attention quality problem, Iacopo Spalletti, CTO and Solution Architect, draws on his firsthand experience, supported by objective data, to highlight the gap between feeling that a tool is helping and the actual benefit it delivers.

***

At the beginning of my analysis and experiments to introduce structured AI-assisted development in our team, I ran a series of structured experiments with an AI coding agent on a realistic project: not a toy demo but something closer to what actually crosses our desks. I wanted to see, systematically, what "agentic coding" is like once you push it past the happy path, before deciding how, or whether, to bring it into the way the whole team works.

I ended up in a fight with the tool.

Two things kept happening. First, the agent would stop and ask me to confirm a decision, sometimes a small one, sometimes a significant one, with no consistent logic I could detect for why this choice needed my sign-off while a comparably weighty one, five minutes earlier, had been made autonomously without a second thought. The line between "ask the human" and "just proceed" felt arbitrary rather than principled.

Second, when setting up a review loop with implementing and reviewing agents working in tandem, more often, round after round, you could see the agents spiraling: the two would go back and forth (a fix, a critique of the fix, a fix of the critique) without ever converging. Neither side was making real progress toward agreement. They were two agents writing confident-sounding but ultimately passive aggressive specs and review comments, stuck in a disagreement that only I could resolve, and doing that meant staying close enough to the actual code to notice the loop wasn't closing.

I couldn't step away. The workflow demanded constant monitoring: I had to be ready to interrupt and jump in at any moment, and steer the agent toward what I judged to be the right call. I wanted to delegate, but what I got instead was a heavier supervisory load, one that landed squarely on the focus the tool was supposed to free up.

I want to be fair about this before going further: this has been my experience in the early days of experimenting with this kind of workflow. It varies with the quality of the prompt, with whether you're using the right skills and structured workflows, and with the experience you build over time in how you guide an agent. I'm not offering this story as proof that agentic coding doesn't work. I'm offering it as a concrete instance of something I think the current conversation about AI productivity keeps skipping past: agentic coding does not solve problems magically. It requires experience and active supervision that cannot be taken for granted, and most of what gets said about AI and productivity right now assumes exactly that.

It turns out this isn't just my own frustration talking. In 2025, METR, a nonprofit that runs some of the more careful empirical work on AI capability, put a version of this exact dynamic under controlled measurement and found the same gap between feeling helped and being helped that I'd just lived through. I'll get into the actual numbers in a moment, because they're worth sitting with but the shape of the finding is the same shape as my own experience above.

Even if the developers in that study had been right, even if AI genuinely had made them faster, there's a prior question nobody in that room was asking.

The Attention Quality Problem

The pitch behind every AI coding tool is roughly the same: offload execution, so you can spend more of your own attention on thinking. It's an appealing trade. It's also, I'd argue, backwards. Producing something genuinely useful out of an AI agent requires more clear thinking than doing the work yourself, not less, because you now have to externalise that thinking precisely enough for something else to act on it correctly. Shallow thinking produces shallow prompts, and shallow prompts produce outputs that cost more to fix than they would have cost to write in the first place.

The METR study above is the clearest entry point into why. Sixteen experienced developers, on mature open-source codebases they'd worked in for years, completed 246 real tasks: bug fixes, features, refactors. Before starting, they forecast a 24% speedup from AI. After finishing, they still believed they'd been sped up by 20%. When actually measured, they were 19% slower. Economists predicted a 39% speedup. Machine learning researchers predicted 38%. Everyone was wrong, and wrong in the same direction.

The number that matters here is the inversion, not the 19% itself. This is the signature of an illusion, not just an inefficiency: a systematic, repeatable gap between how productive the work felt and how productive it actually was.

METR's own analysis points at something specific: these codebases carried high implicit quality standards (documentation conventions, testing coverage norms, linting rules) that the developers had internalised over years but couldn't easily put into words for an AI. The knowledge that makes an expert fast is precisely the knowledge that's hardest to hand over in a prompt.

It's worth being precise about what's changed since that study and what hasn't. Agents in 2026 are genuinely decent at inferring conventions from the surrounding code: they read the existing tests, match the prevailing style, pick up on patterns without being told them explicitly. But that ability rides entirely on how consistent the codebase already is. A codebase with genuinely uniform conventions hands an agent something reliable to learn from. A codebase accumulated over years, with drift, exceptions, and tribal knowledge nobody wrote down (which describes most codebases old enough to matter) gives it nothing solid to infer from. The externalisation problem doesn't disappear with better models: it relocates to exactly the codebases where it was always hardest, the old, valuable, inconsistent ones, which can't simply be assumed away.

This isn't a one-off finding, either. Studies of agentic prompting consistently find that a meaningful share of prompts are missing information the agent actually needed: one 2026 study of over 20,000 real agentic sessions found that 44.1% of episodes contained underspecified instructions. Articulating context precisely takes the same mental effort as understanding the problem in the first place. If you haven't done that thinking, no amount of prompting technique manufactures it for you.

The cost of skipping that thinking shows up downstream, reliably. A Harness survey of engineering leaders and developers found 67% spend more time debugging AI-generated code than they expected to. Analysing 470 real pull requests, CodeRabbit found logic and correctness errors 1.75 times more common in AI-generated code than in human-written code. Workday's 2026 research on enterprise AI adoption found that nearly 40% of the productivity value AI creates gets consumed by rework and misalignment. The time AI saves gets spent fixing outputs that shouldn't have needed fixing.

This is the part I recognise from the inside: shallow prompting feels like productivity while it's happening. You type a few lines, something appears on screen, you move on to the next thing. The output is visible immediately. The debt is invisible until review time and by then it's wearing the costume of "someone else's problem" because, in a sense, it is: you handed the thinking to the tool, and the tool handed something plausible-looking back.

One honest caveat, because I don't want to overstate a single data point: METR's original study used early-2025 tools, and METR itself published a follow-up in February 2026 using more capable, late-2025 models. It's worth citing precisely rather than gesturing at vaguely, because the actual numbers are more interesting than a tidy "things got better" story. For developers returning from the original study, the estimated speedup was -18%, still a slowdown. For newly recruited developers, it was-4%. closer to flat but still not positive. METR itself describes this as "very weak evidence": by then 30 to 50% of developers were refusing to submit tasks they didn't want to do without AI, and the study's own control group was evaporating, because people no longer wanted to work the old way even for research purposes, even at $50 an hour.

So the honest state of the evidence, as of the most recent primary data, is this: no confirmed positive speedup yet, wide confidence intervals straddling zero, and a study design that had to be abandoned because using AI has become too normalised to isolate a clean baseline. That's a stronger and more specific claim than "the models have probably improved by now": It says the measured slowdown hasn't been reversed on the best evidence currently available, even as anecdote and self-report increasingly insist otherwise.

Which is the deeper point. Model capability might eventually close the specific 19% gap METR measured but it's much less likely to close the gap between feeling helped and being helped, because that gap isn't a property of the model: it's a property of a person working next to something fluent and confident. Decades of research on automation bias (a term coined in the 1990s to describe how people in highly automated environments substitute trust in the system for their own vigilant checking) shows this pattern is durable, not a symptom of immature tooling. This effect is generally worse under cognitive load, not better and it shows up in current-generation tools too: a 2026 study of cognitive biases in LLM-assisted development found that 48.8% of programmer actions in AI-collaborative workflows exhibited some form of cognitive bias, with developer-LLM interactions themselves accounting for 56.4% of the biased actions observed, using today's tools, not the outdated ones METR originally studied.

None of this is new to software, either. Research bridging self-reported and objectively measured developer productivity has long found the two diverge, in ordinary non-AI work, in systematic and non-random ways. AI didn't invent the gap between feeling productive and being productive: it gave that gap an unusually persuasive new surface to operate on, a collaborator that produces confident, well-formatted, plausible output on demand, exactly the condition under which we're most likely to mistake fluency for correctness.

There's a second failure point downstream of all this, though, and it has a different cause. It's not about what goes into the prompt, it's about what happens when you sit down to evaluate what comes back.

***

This is the first part of the AI: The Illusion of Productivity series. Part two lands on September 8: we'll look at why reviewing AI-generated code takes more focused attention than writing it yourself, and how that's already reshaping the way teams write code day to day. 

***

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

Related posts