The AI Productivity Paradox

Why More AI Doesn’t Mean Better or Faster - Now or in the Future

Apr 10, 2026

Article 1 in the AI Productivity Paradox Series

Developers, economists and AI experts all predict that AI will make software development faster. It feels faster when using it. We have a number of studies that it is faster in laboratory/synthetic settings (Peng et al., 2023; Noy & Zhang, 2023; Brynjolfsson et al., 2023). Yet in the real world, in outcomes that matter - it feels faster, but isn’t (Becker et al., 2025). This is true now, and I will argue, likely will be in the future as well.

The premise of this article is uncomfortable but evidence-backed: the software industry’s rush toward parallel AI agent architectures is optimizing for a metric that feels like productivity but isn’t. The organizations and developers using them can’t tell the difference, because of well documented cognitive biases that have been studied for decades.

Don’t believe me? Let’s talk data. The research organization METR published results from a randomized control trial (Becker et al., 2025) – a preprint, not yet peer-reviewed, but methodologically careful – studying 16 experienced open-source developers working on established open-source repositories. Sixteen is a small sample size. But the design is unusually strong for this kind of research: real developers, real codebases, real tasks, with both objective measurement and self-assessment. These weren’t toy projects or synthetic benchmarks. The repos averaged 22,000 Github stars, and over a million lines of code. The developers knew the codebases. They chose their own tasks and issues to tackle. And they predicted, before starting, that AI tools would make them about 24% faster. After completing the tasks, they estimated that AI had made them roughly 20% faster.

But the measured reality: 19% slower.

That’s a 43-percentage point perception gap - in the wrong direction! This reveals a fundamental disconnect between how productive these developers felt and how productive they actually were.

The METR finding doesn’t stand alone. Dell’Acqua and colleagues (2023) ran a randomized controlled trial with 758 BCG consultants using GPT-4 across 18 realistic business tasks. On tasks within AI’s capabilities, consultants using AI were faster (25%) with higher quality (40%). But on tasks that fell outside that frontier, consultants using AI were 23% less likely to get the correct solution.

The frontier is jagged - AI is great at some things and terrible at others, and users cannot tell which side of the line they are on. The developers in the METR study were navigating this jagged frontier 2 years later - and the 43-point percentage gap tells us that they too couldn’t see the boundary.

This finding should stop the software industry in its tracks. But it won’t, because it collides head-on with the narrative driving billions of dollars in investment: that AI coding assistants are making developers radically more productive, and that running moreAI agents in parallel will multiply those gains. Brooks showed fifty years ago that adding people to a software project adds communication overhead that defeats the throughput gains (Brooks, 1975). Parallel agents do the same thing to a developer’s working memory.

The examples in this article come mostly from software development – the knowledge domain with some of the richest data on AI-assisted work – but the science applies to all knowledge work. Attention residue doesn’t care whether you’re switching between code reviews or patient cases. Working memory has the same ceiling whether you’re holding a software architecture, a complex proof or a differential diagnosis in your head.

For well-defined tasks with clear acceptance criteria, automate fully – the evidence supports it. This article is about everything else: the work where your understanding matters, where requirements emerge through iteration, and where what you build needs to be maintained and evolved over time.

I’ve used Claude Code in deep pair-programming mode daily for the last two months (over 550 session hours logged), run a small research group on AI in medical education, and teach pragmatic AI introductions for physicians at Harvard teaching hospitals. My experience working in software development teams confirms what decades of cognitive science research has mapped precisely: the specific pattern of running multiple AI agents simultaneously triggers well-documented failure modes of sustained cognitive performance. The science explains why it feels productive but isn’t – and it points directly at what works instead.

The parallel agent future isn’t coming. It’s here. The question isn’t whether it works – it’s whether we’d know if it didn’t.

Who is this article for, and what kinds of problems does it apply to?
I think the evidence and conclusions apply to knowledge work broadly, but I expect this to be most immediately relevant for those who are, or aspire to be, knowledge craftsmen and craftswomen. This is for you.
The problems you tackle can be great or small – often at the limits of our knowledge, or radically new applications to old problems – and you are committed and accountable for the solutions you deliver. You want to do this quickly and well.
You know that even in solving existing, supposedly well defined problems, discovery of the real problem still needs to happen. And when you are paying attention, you bring the best of your tools, technology and understanding to bear.
You are not an academic – you are pragmatic and want to solve things well, as quickly as possible. You also know that how things feel and what really works are not always the same, and if you are going to change your approach, you’ll need solid evidence or a darn good reason. You apply this critical thinking to every new tool and approach handed to you – you enjoy looking through the hype. You take on new tools easily, you sharpen your own tools, but you do it while producing great work. This article builds on that approach and that kind of evidence.
There are others, for whom the work in knowledge work dominates. If this applies to you, you might not feel like you have the chance, or the time, to do quality work – you just need to get it done as quickly as possible. You might just be handed specifications to be completed or you might be a manager whose success depends on executing well-defined specifications at scale. You might think this doesn’t apply to you. Keep reading.

The Science of Why Multitasking Fails

You know the pitch. Run two, no three AI coding agents in parallel – one doing the search feature, another on the payment refactoring, and the other on test coverage – get three things done in the time it takes to do one! Go from coder to god-like orchestrator. You monitor their progress, review their output, steer corrections, and ship!

Sounds like a no-brainer, and unfortunately it is. Here’s what’s actually happening in your head while you do this. Four decades of cognitive research have mapped this out precisely, and it’s not pretty.

You Can’t Fully Leave a Task Behind

You’re reviewing Agent 1’s search implementation. It’s going well – the approach is solid, but there’s a tricky edge case you need to think through. Then Agent 2 pings: it’s done with payment refactoring and is ready for review. You want to keep them all humming, so you switch.

But your brain doesn’t switch cleanly. Organizational psychologist Sophie Leroy calls this attention residue – when you move from one task to another, part of your thinking circuits stay stuck on the first task, especially if it was unfinished or complex (Leroy, 2009). It’s not a discipline problem. It’s structural. Your brain is still spending cycles on that search edge case while you’re trying to evaluate the payment code.

Leroy’s experiments showed that people who switched before completing a task performed significantly worse on the next one. The residue was strongest when the first task was cognitively demanding and unresolved - exactly the state you’re in when you tab over to a second agent while the first is in mid-execution.

You’re never fully present with any single agent’s output. You think you are. You’re not.

The Faster You Go, The Less You See

But, you say, the agent is focused on a single task, and I am just focused on keeping it moving in the right direction. Quick check-ins, quick corrections, moving fast!

It is fast. And that’s a problem for us. It makes us nearly blind to errors and issues big and small, we learn less and it is more stressful and frustrating.

Mark, Gudith and Klocke (2008) found something counter-intuitive: interrupted people doing email and communication tasks finished faster than uninterrupted people. Shorter messages, quicker work – compensatory acceleration. We’ve all experienced this - the magic power of deadlines. If all your tasks were simple communications, and you only measured completion time, interruptions would look like they help.

Unfortunately after just twenty minutes of interrupted work, stress was significantly higher. Frustration, time pressure, effort, mental workload all got significantly worse. The speed has to come from somewhere. You pay for it with shallower engagement and more mental and emotional energy.

For more complex tasks, the speed, performance and learning costs are much higher. Czerwinski, Horvitz, and Wilhite (2004) found that resuming a suspended task was harder than starting a new one, and the difficulty scales with task complexity, duration, and number of interruptions – all factors that parallel agent coding maximizes. Parnin and Rugaber (2011) confirmed this directly: only 10% of interrupted programming sessions could be resumed in under a minute. Most of the time, programmers needed extensive navigation and re-reading to rebuild their mental models.

In one striking case from the study, a programmer returning from an interruption forgot a simple step they’d been about to take. They completed the surrounding code, then spent the entire remaining session unsuccessfully debugging the resulting issue - a bug that wouldn’t have existed without the interruption. As Parnin and Deline (2010) put it: “when resuming work, developers experience increased time to perform the task, increased errors, increased loss of knowledge, and increased failure to remember to perform critical tasks”.

Programming requires holding complex interlocking abstractions in your head. When you switch, they don’t blur – they collapse. And the collapse isn’t just slower processing – it’s a form of blindness. Hyman and colleagues (2010) showed that people talking on cell phones while walking – a trivially simple task – were significantly less likely to notice a clown riding a unicycle directly in their path - inattentional blindness. When your cognitive resources are engaged elsewhere, you don’t just process things more slowly. You literally fail to perceive what’s right in front of you.

Now apply that to code review. You’re reviewing Agent 2’s payment refactoring while your brain is still chewing on Agent 1’s search edge case. You’re not just doing a slightly worse review. You’re the person walking past the clown. The subtle type coercion bug, the missing null check, the architectural choice that will cost you weeks to months of work – these are the unicycling clowns of code review. They’re right there in the diff. You looked directly at them. You didn’t see them.

I experienced this first hand. Running two parallel tasks – one going smoothly, one difficult. The moment I switched to the challenging task, it dominated everything. And when I switched back to the smooth one, I was no longer the same reviewer. I was skimming where I had been reading. Not slightly less careful – fundamentally different. The kind of review that misses clowns, and remembers nothing!

Your Working Memory Has a Hard Ceiling

Why do our mental models collapse? Because of a hard constraint: human working memory is finite. Miller’s classic 1956 research showed that we can hold roughly seven items in short-term memory. Cowan’s synthesis later refined this to a capacity of only about 4 (Cowan, 2001).

Now consider what is needed to keep track of in a single code base change: the current code state, the intended modification, how it fits within the architecture and approach, alternative strategies to be considered, the potential efficiencies of this approach, the potential side effects of this approach, the testing strategy for correctness, for edge cases. Even allowing for “chunking” of some related patterns, this is at or above the ceiling – for one task.

And here’s what makes parallel agents uniquely destructive: task switching reduces your working memory. Liefooghe, Barrouillet and Vandierendonck (2008) demonstrated this directly: the act of switching between tasks impaired the maintenance of items in working memory, and the impairment scales the more you task switch. The switching process itself eats the resources you need to hold your mental model together.

When you run parallel agents, you’re not doubling your capacity. You’re dividing it - and then taxing the remainder with the overhead of the switch. At two agents, you’re asking depleted working memory to maintain two complete problem representations. At three, you’re likely past the point where meaningful review is possible. You might still bereading the code, but you’re not understanding it – not the way that catches the subtle architectural mistake that will cost you three weeks in six months (yes, even with smarter AI).

Flow States Require Sustained Focus

You know what flow feels like. You’re deep in a problem, the code is flowing, you’re making connections and seeing patterns. Hours feel like minutes. Csikszentmihalyi’s research identified three conditions for this state: clear goals, immediate feedback, and a challenge-skill balance (Csikszentmihalyi, 1990).

Parallel agents violate all three simultaneously. Clear goals fragment into multiple goal streams. Immediate feedback becomes delayed and interleaved. Challenge-skill balance tips toward overwhelm – not because the coding is necessarily harder, but because the meta-cognitive load of tracking multiple problem states is a different kind of difficulty, and as we’ve seen already, not the productive kind for human brains.

A 2024 daily diary study confirmed this directly: multitasking significantly hinders flow states and reduces subjective work performance, even when controlling for individual differences (Pluut, Darouei & Zeijen 2024).

The Compound Effect

These mechanisms don’t operate independently. They stack.

And they go deeper than you think. Rubinstein, Meyer and Evans (2001) showed that task switching involves two distinct cognitive systems – goal shifting and rule activation– worsening completion time by up to 40%. Braver’s research on cognitive control (2012) adds a further dimension: sustained focus enables proactive control, where you actively maintain goals and anticipate demands before they arise. Fragmented attention forces you into reactive control – responding to each new demand as it arises – producing shallower results.

And the damage may be cumulative. Ophir, Nass and Wagner’s 2009 study found that heavy media multitaskers (people who use multiple media at the same time) perform worse on task-switching tests than light multitaskers – the opposite of what you would expect from practice. While the hypothesis that heavy media multitaskers are more distractible than others has not been consistently replicated (as explored in the replication studies and meta-analysis by Wiradhany and Nieuwenstein, 2017), the core finding – that heavy multitaskers are no better and possibly worse at the switching they do constantly – was replicated. While the literature is descriptive (describing people who are already heavy media multitaskers), and not causative (if we cause people to become heavy media multitaskers what happens to them), it is possible (given the perceived rewards of feeling more productive discussed above) that developers who habitually use parallel agents may be training their cognitive control to get worse at the very task switching that parallel agents demand.

With parallel agents, the cascade looks like this:

You switch to check Agent 2 -> attention residue from Agent 1’s problem clings
You try to understand Agent 2’s output -> working memory splits between two problem contexts, and the switch itself has consumed some of the working memory you need
You realize that Agent 2 went in a wrong direction -> cognitive load spikes as you formulate a correction
You switch back to Agent 1 -> your cognitive control mode shifts from proactive to reactive mode, and compensatory acceleration may kick in – you review faster and shallower
Agent 1 has progressed while you were away -> inattentional blindness means you’re looking at the code but missing what matters, with up to 40% of your time consumed by the switching itself.
You never reach flow because the cycle repeats before sustained focus can take hold.

This isn’t a theoretical failure mode. It’s the everyday experience of anyone running parallel agents – except it doesn’t feel like failure. It feels like being busy and responsive and in control.

Which brings us to the most dangerous part: you can’t trust your own perception of whether it’s working.

The AI Amplification Effect

Google’s DevOps Research and Assessment (DORA) program’s 2025 report on the “State of AI-Assisted Software Development” surveyed nearly 5,000 technology professionals. It arrived at a key central finding: AI is an amplifier – it magnifies the strengths of high-performing teams and it magnifies the dysfunctions of struggling ones (DORA, 2025). The cognitive science we’ve just reviewed helps us to understand what gets amplified and in what direction.

Deep pair programming amplifies our cognitive strengths: sustained focus, architectural judgement, the kind of understanding that compounds over time. We’ll dive into that in a later section. The parallel AI agent pattern amplifies the opposite: every failure mode we’ve just documented – attention residue, working memory reduction, blocked flow, the cascade from proactive to reactive thinking. And it does so while making the damage harder to detect - for us, and for the organizations we work in.

More Activity, More Progress or More Debt

AI clearly makes certain things faster. The evidence for this is solid and growing. In controlled settings with well-defined tasks, AI delivers measurable gains. Peng and colleagues (2023, preprint) from Microsoft found that Github Copilot made developers 56% faster on a simple HTTP server task. Noy and Zhang (2023), in a study published in Science, found that ChatGPT reduced professional writing time by 40% and raised quality by 18% among 453 professionals. Brynjolfsson, Li, and Raymond (2023) documented a 14% productivity increase for customer service agents, with the largest gains for novice and low-skilled workers.

The question is whether these improvements translate to improving or worsening the outcomes we care about especially when the work gets complex – and whether we can tell the difference.

Google’s annual DORA reports offer a window into how thousands of technology workers perceive AI’s impact on their work. In their 2024 survey, respondents believed that AI adoption improved documentation quality and code quality, but they also believed it decreased delivery throughput and delivery stability (DORA, 2024). By 2025, the picture had shifted: respondents thought AI improved individual effectiveness, organizational performance, code quality, and product performance, with a small and uncertain improvement in software delivery throughput. But they continued to think AI adoption will worsen software delivery stability (DORA, 2025).

These are perceptions, not measurements – and that matters. But the pattern within those perceptions is telling. Even the people using AI and feeling more effective sense that delivery stability is getting worse. They feel faster. They also feel less stable. This tension – more activity, uncertain progress – is just what I think almost everyone experiences when using it for real work.

And the feeling of faster and better resonates. Anyone using AI tools feels the acceleration. More gets done in a session. More ideas explored, more code written, more tickets touched. But as we’ve seen in the previous section, we have to be very careful about equating the feeling of getting things done quickly with achieving results that matter.

I am not arguing against using AI. I am arguing against using it in ways that don’t achieve the outcomes that matter – and against relying on metrics that make it impossible to tell the difference.

Bounded, well-defined tasks are important to do correctly and quickly. Multiple choice questions testing knowledge or specific problem solving ability, and people’s perceptions of how fast they are working can also be important. AI improves these, and using parallel AI agent approaches may improve them even more. But know that this is not the same thing as solving complex real-world problems.

Some studies are starting to help us learn more about this. The METR study is one example. When you actually measure time to complete tasks in a controlled experiment – not self-reported, not throughput proxies, but observed performance – experienced developers are slower with AI on complex real-world tasks.

This is the pattern to watch for: throughput goes up, quality-adjusted productivity doesn’t - or goes down. Be wary of any metric that counts only tasks completed per unit time. Three agents, three tasks, three-for-one. But a pull-request (PR, a set of code changes that are to be added to existing code) that introduces subtle architectural debt isn’t a completed task – it’s a deferred cost. Three PRs that each solve their ticket but don’t cohere into a consistent system aren’t three completed tasks. They’re a coordination problem and a future burden.

The Invisibility Problem

This would be concerning enough if we could see it happening. We can’t.

Cal Newport defines pseudo-productivity as the “use of visible activity as the primary means of approximating actual productive effort” (Newport, 2024). The concept isn’t peer-reviewed, but it names something that we see reflected in the literature and in our work lives: real productivity in knowledge work is genuinely hard to measure, and activity metrics are always available. The parallel AI agent workflow is a pseudo-productivity machine – it generates enormous volumes of visible activity (lines added, PR’s open, tasks completed). Organizations are particularly vulnerable to this pseudo-productivity bias - mistaking a process or throughput dashboard for true performance measures.

At the individual level, we have additional cognitive blind spots. Sanbonmatsu and colleagues (2013) found that perceived multitasking ability was significantly inflated: the people who multitasked most frequently had the worst performance when multitasking. Finley and colleagues (2014) showed that while people expect multitasking to hurt performance, they have essentially no insight into how much it will actually affect them – the correlation between predicted and actual performance loss was near zero. If we think we’re the exception, the evidence says we almost certainly are not.

The parallel agent pattern adds a second layer of invisibility. Human factors research calls it automation bias – the tendency to over-rely on automated recommendations as a heuristic replacement for vigilant information seeking and processing (Skitka et al, 1999). It manifests as errors of commission (following incorrect AI advice) and errors of omission (failing to notice problems the AI didn’t flag). Goddard and colleagues’ (2012) systematic review of 74 studies found automation bias and automation complacency to be robustly demonstrated in multiple fields (including aviation, medicine and the military).

The parallel agent workflow creates many of the conditions that increase automation bias – cognitive load from multiple contexts, time pressure from simultaneous completions, a firehose of output demanding review, and consistent high level attention demands – that can worsen automation bias. You’re not just missing bugs because you’re distracted. You’re systematically over-trusting the output because your cognitive resources are depleted.

In our own work – 145 Claude Code sessions spanning 556 hours – we saw what becomes visible when you don’t divide your attention. The number one source of friction wasn’t AI capability. It was the wrong approach. In 20 instances, the AI picked the wrong architecture, the wrong pattern, or the wrong solution direction. With a single agent and full attention, we caught these in real time. Run three agents in parallel and you’ve tripled the wrong-approach surface area while dividing your steering bandwidth by three (if not more). The agents aren’t making fewer mistakes. You’re just catching fewer of them.

Simkute and colleagues (2024) arrived at the same conclusion through a different lens – applying Bainbridge’s classic “ironies of automation” framework to generative AI. They identified four mechanisms of productivity loss: the shift from producer to evaluator (which requires different and often more demanding cognitive skills), workflow restructuring around AI outputs, micro-interruptions from AI suggestions, and the paradox that automation makes easy tasks easier while making hard tasks harder. It’s an independent convergence on the insights from cognitive science: the parallel agent pattern doesn’t just add workload. It restructures the nature of our engagement with the work.

The perception gap explains why developers and organizations will keep reaching for parallel agents despite the evidence. The tool works – that’s not in question. The question is whether the way we use it actually improves our ability to deliver effective solutions – or just generates more code and busy activity. Understanding why we can’t see the damage is only half the story. The other half is what the damage costs over time.

The Compounding Cost

The cognitive damage is only the beginning. The real danger of the parallel agent pattern isn’t what it does to your afternoon – it’s what it does to your next six months.

The costs don’t just add up. They compound in three directions: in what your output is worth, in the debt it accumulates, and in the understanding you never build.

The Replaceability Trap

Here is the uncomfortable truth about shallow AI-assisted output: it gives you a very short shelf life.

If current trends in AI code generation continue, the gap between “what a developer orchestrating five agents can produce” and “what an autonomous agent can produce alone” will continue to narrow. If your value as a developer (or knowledge worker) is measured by the volume of AI-generated code you can dispatch and triage, you are in a race against a competitor that gets faster (and usually cheaper) with every model release.

Developers who rely on parallel agents for speed are training themselves for the wrong future. They’re building exactly the skills – dispatching, triaging, skimming – that sit directly in the path of automation, while atrophying the skills – architectural judgement, deep system understanding, creative problem-solving – that remain hardest to automate.

The developers and knowledge workers who will be harder to replace are the ones who understand their systems and domains deeply enough to know when the AI is wrong. And that understanding only comes from sustained engagement, not from monitoring dashboards.

The Technical Debt Spiral

An AI agent can fix a failing test. It can resolve a type error. What is much harder for it to do, and which can have much more serious consequences over time, is understanding whether a series of locally correct changes is producing a globally coherent system.

We saw this firsthand. A developer on our team used AI agents to implement a significant UI redesign. The PR landed with 820 files and 32,324 lines changed. It worked. Every screen rendered correctly. But the AI had built a custom CSS framework – 4,278 lines of component-scoped styles with duplicate design tokens, and unconventional file locations – on top of the CSS framework we already had. When we refactored with an architectural understanding, 4,278 lines became 257. A 94% reduction. Not because the original code was broken, but because it was locally correct and systemically incoherent.

The compounding math is sobering. At two new components per week, the AI-generated approach would have grown to 10,000 to 15,000 lines of custom styles within a year. The architecturally sound approach: 500-800 lines. Each extra line slows every future change, confuses or misguides every new developer (or agent), and compounds maintenance burden quarter over quarter. All this while our developer would become less able to explain or understand the system, and with little growth or deepening of their development skills. When we projected feature velocity over twelve months, the shallow approach produced 33 features, while the deep approach produced 43 – the crossover happening around month six, after which the debt-laden codebase would slow development permanently (we modeled this projection based on observed velocity and refactoring overhead).

CodeScene’s analysis of large codebases quantifies this at industry scale: “unhealthy” code has 15 times more defects, leads to 2x slower development and creates up to 9x more delivery uncertainty than healthy code (CodeScene, 2024). GitClear’s analysis of 211 million changed lines of code between 2020 and 2024 found a tenfold increase in code blocks containing five or more duplicated lines – a signature of AI-generated code that solves the local problem without understanding the existing system (Harding, 2025).

And that duplication doesn’t just add up. It compounds. Cloned code breeds more cloned code. Cloned code makes a simple change in a single area into a change that requires understanding the specific use case of the duplicated code in every area – exploding the cognitive load for human and AI agent alike. And when an AI agent encounters a codebase that already has duplicated patterns, it pattern-matches against what exists and produces more clones of the clones.

Refactoring is hard, and with so much more code, getting harder. Each duplicate increases the codebase size, which increases the probability that the next agent will clone rather than find the canonical implementation. A bug in the original now needs fixing in all N copies – but N keeps growing. And as it grows, local changes creep in, and so all the actual clones can’t be automatically found anymore, and on and on the debt grows.

Our CSS framework example shows the mechanism in miniature. By month six, the custom framework is the dominant pattern in the codebase. The correct framework is buried. Any new agent would match the dominant pattern and add another clone. This is why the GitClear data shows tenfold growth of cloned code over two years, not two or even four-fold (Harding, 2025). The accumulation is exponential, not linear.

This is the area of the article where I expect the most pushback, and for good reasons. The models are getting better. The context windows are getting larger. Harding’s 2025 analysis found that AI-assisted code is becoming more durable – code that persists and is not thrown out within the first month. That’s genuine improvement, and suggests the models are writing better code. But durability and coherence are different things. Our 820-file PR was durable. It worked, it passed all the tests. The problem was the 94% of unnecessary code hiding inside it. Durable incoherence is worse than fragile incoherence, because it persists long enough to become the foundation that future code – and future clones – build on.

The deeper problem is detection. “Just let agents fix it” assumes you or they know what needs fixing. But the more parallel agents you use, the harder it is for you to tell when they are producing worse code. The 820-file PR looked like a triumph – a massive UI redesign, built with a lot of code generated each day. It took a senior developer’s architectural review to see the systemic incoherence. You can’t ask an agent to fix a problem you don’t know exists. And when three parallel agents each produce cloned code in the same sprint, none of them seeing the other’s output, you’ve tripled the clone surface before any review happens. Even with steadily improving models, the parallel agent pattern amplifies technical debt. That debt is hidden from the metrics that organizations actually track.

This hits junior developers hardest. The METR study and the Brynjolfsson article show that experts benefit less from AI and may even be slowed down. Those with less experience benefit the most from AI assistance, and Harding’s data shows enthusiastic adopters accounting for the vast majority of new lines of code added. But the “generate and fix” loop runs on the detection ability the junior developers haven’t built yet. They’re the ones most likely to ship the 820-file PR and celebrate. They’re also the ones who most need the sustained engagement that would develop their ability to see what’s wrong – the very engagement that parallel agents replace with dispatching and skimming. The developers who grow the fastest are the ones who stay in the problem long enough to develop the judgement that makes detection possible. The parallel agent workflow trades that growth for throughput – a trade that looks efficient until you realize you’ve optimized away the learning.

The Moat That Deepens

Every hour spent in shallow orchestration mode is an hour not spent deepening your understanding of the real problem your customers need solved – the patterns in how they work, the friction points they can’t articulate, the elegant solutions that only emerge from sustained, intimate engagement with a problem space.

This understanding is not a nice-to-have. It is the moat. It is your moat.

What happens when a developer cultivates this kind of depth? On our team, a developer had spent weeks deeply engaged with our productivity system – working with AI in deep pairing mode, not just writing code but thinking about how users actually navigate their days, what they reach for, what they ignore. When it came time to build the mobile app, the obvious approach was to make every view responsive. A parallel agent workflow would have done exactly that: hundreds of screen changes, each one locally correct, each one passing its tests. Easy to start, effortful to confirm correct.

But this developer could see something the agents couldn’t. Users didn’t want the desktop shrunk onto their phone. They would struggle to triage the complex reality of their lives and priorities on a tiny screen. What they needed on mobile was calm confidence – a quick glance at what was planned, a quick way to check things off, a way to capture what just came to mind. Not ultimate control at all times - they’d already done that. Confidence.

The entire responsive redesign was the wrong problem. Instead of hundreds of screen changes, the mobile app needed three core screens. Even if the responsive redesign had taken only a day with a massive swarm of AI agents, it would still have been wasted time and effort. It took 3 days to do it right - not because AI made it faster, but because understanding made it smaller.

Products built by developers with this kind of understanding don’t just work – they feelright. They anticipate edge cases because the developer has internalized the user’s world. They cohere architecturally because the developer holds the whole system in mind. They evolve gracefully because the developer understands not just what the system does but why it was built that way.

And this moat deepens as AI improves. When anyone can generate working code by describing what they want, the differentiator shifts from “can you build it?” to “do you understand what should be built, and why?” The developer who has spent months in deep engagement with their codebase and their users has compounding advantages that no model can replicate: context that they understand and feel, judgement refined by thousands of small decisions, intuition built from watching real users encounter real friction.

The shallow approach depreciates. Each model release makes last quarter’s AI-dispatched output easier to reproduce. The deep approach appreciates. Each session of sustained engagement makes the developer’s understanding richer, their architectural judgement sharper, their feel for the problem more nuanced. And AI speeds their ability to deliver, while using an approach that deepens their understanding of the space. Not an approach that makes it shallower.

One compounds down. The other compounds up.

The Disruption No One Sees Coming
If your organization is going all-in on parallel agent architectures, the argument might sound like an individual concern – cognitive science for developers, not a strategic issue. Many engineering leaders see it that way. They have challenging targets to reach: tickets closed, features shipped, specifications fulfilled. Parallel agents promise more throughput per dollar. The cognitive cost to individual developers is, from their perspective, an acceptable trade-off.
They’re not wrong about the short term. Parallel agent architectures will close tickets faster and produce impressive dashboards. For organizations whose business model is executing predefined specifications – large government contractors, enterprise IT shops, outsourcing firms – this may work well enough, for a while.
But we’ve seen this movie before. The entire agile revolution was built on a single uncomfortable discovery: specification fulfillment is not the same as solving the problem. Solving difficult problems in dynamically changing environments requires iteration. The people closest to the problem carry knowledge they can’t articulate until they see the wrong solution. And often for complex problems, people who know the problem carry conflicting requirements and priorities. In these settings, it seems clear that the teams that solve the problem most effectively are the ones who stay close enough to it to discover what should be built, not just execute what was specified.
The parallel agent mode at enterprise scale is waterfall with better tooling. Faster execution of the same fundamental mistake.
The pattern isn’t hypothetical. The FBI spent over $600 million and a decade on two specification-driven attempts to modernize their case management system. Both failed. A much smaller in-house team completed the harder half in eighteen months, under budget (DOJ OIG, 2014; Sutherland, 2014).
Clayton Christensen spent his career studying what happens to organizations that don’t do the work to understand the job to be done – the job the customer is actually hiring their products to do for them (Christensen, 1997). Without that understanding, they optimize for the wrong metrics. The pattern is consistent: incumbents refine their existing approach – in this case, throughput and ticket velocity – while a smaller competitor quietly solves the actual problem better. The incumbents can’t respond. Their management structures, incentive systems, and cultures are built around the model they’ve invested in. By the time they recognize that their perfectly specification-compliant software keeps losing to products that actually solve the customer’s problem, the structural inertia is too great to change.
Consider what this looks like in practice. The mobile app example from the previous section – where a developer’s deep understanding reduced hundreds of screen changes to three core screens – isn’t just a story about better code. It’s a competitive story. An organization dispatching parallel agents would have shipped the responsive design: locally correct, globally wrong, and weeks to months of wasted effort. The team that uncovered the problem through deep engagement shipped the right product in days. Multiply that across every feature decision, and the gap compounds fast.
The deep-pairing team loses nothing. They can also use agent orchestration – spin up parallel agents to stress-test their architecture, generate alternative approaches, surface blind spots in their thinking. Orchestration becomes a tool for deepening understanding, not a substitute for it. The competitive advantage isn’t in refusing to use powerful tools. It’s in using them in the service of understanding rather than replacing it.
I believe that the organizations that grasp this will build better products with smaller teams. They will attract the developers who care about mastery and craft – the ones whose deep engagement is precisely what makes the products great. The organizations that don’t will ship more tickets and wonder why they keep losing customers to teams who spend a fraction of what they do on AI, and are a fraction of their size.

A Better Way: Deep Pair Programming

We’ve spent a lot of time exploring the challenges that come with unthinking adoption of AI agents in our work. But this same science, as well as other fields within cognitive science, help guide us to what works instead.

Every mechanism from the previous sections has a positive mirror. Attention residue punishes context switching – but sustained engagement in one problem lets mental representations deepen rather than degrade. Working memory collapses under divided attention – but when you stay in one problem, expertise and inter-connections compress complexity through chunking, and your effective capacity grows. Flow shatters under task-switching – but its conditions (clear goals, immediate feedback, challenge-skill balance) are naturally preserved when you work together deeply on the same problem. Proactive control – where you maintain goals and prepare for problems before they arise – can be maintained when working with sustained focus.

The research doesn’t just tell us what to avoid. It tells us what to build toward. And what it describes looks a lot like deep pair programming.

The Rhythm

The practical question (and the reason why most gravitate to parallel agents) is: what do you actually do while the agent is working?

This is where most people go wrong. The agent is implementing, you have a minute or two, and the instinct is to start something else. Check another PR. Spin up a second session. The science from the first half of this article tells you exactly what happens next: attention residue, working memory fragmentation, the cascade into reactive control. You know this. But the pull is strong, because waiting feels like wasted time.

It isn’t.

Bernstein, Shore and Lazer (2018) studied the human version of this directly. When groups of three were given a complex problem to solve, those who did not interact did more exploration. When groups interacted continuously, there was more social learning, but less exploration. The optimal pattern was intermittent interaction – alternating between periods of independent thinking and collaborative exchange. This produced better outcomes in both dimensions – the benefits of more exploration and the benefits of shared learning.

This maps directly onto deep AI pairing. While the agent implements, you stay in the problem. You think. You explore ways you might solve the problem. You put down the keyboard and work through the architecture on paper. How should this feature be broken down? What edge cases haven’t we considered? How does this change interact with the rest of the system? What would the user actually do here? What do they really want to do? Is there a simpler approach we haven’t considered?

You’re not idle. You’re exploring new solutions, problems, and approaches based on your understanding of the user’s world. The agent implements, you reason, feel, relate, predict, integrate. Different types of cognitive labor, making the solution stronger and deeper, while your understanding of the system and of your AI partner grows and deepens.

And you review. You watch the code emerge, collecting questions, noticing what you’d change, building your mental model of the solution. When the agent finishes, you’re not starting from zero, or having to unload other problems. You’re loaded with context and ready with informed feedback. The agent adjusts. You go deeper. The cycle repeats. You stay in flow.

You are staying in the same working sphere (Mark, 2005). These activities don’t break flow. They stay within the same cognitive neighborhood. This is the positive version of the science we have discussed: sustained engagement in one problem space lets every cognitive system work at full capacity. Proactive control. Deep connected working memory. Flow. The compound cascade runs in the right direction.

I learned this the hard way. In my first experience with AI coding tools, I thought they had 10x’d me. I vibe coded for a day and a half and loved it. I generated enormous volumes of code, felt incredibly productive, and shipped a major feature. Then I spent two painful weeks rolling it back. The code worked locally but was systemically incoherent, full of edge cases I hadn’t thought through, and built on patterns that conflicted with our existing architecture. Sound familiar? It’s the 820-file PR from the technical debt section, except I did this to myself.

That experience forced me to recalibrate. I stopped expecting 10x. I settled into something more like 1-1.6x – still faster, but honest. And then something unexpected happened. As I disciplined myself to stay in the problem – to use the agent’s implementation time for deep thinking rather than context switching – my velocity started climbing. Not because the AI got faster. Because I got better at steering it.

I now do in half a day what I would have planned for a week. High quality deployments still need additional time for testing on staging, and with users, but even there the deep pairing approach makes me much more effective. I’m not starting from within a labyrinth of code I don’t know, I’m already running fast through known territory as we learn how users actually use and interact with our code, and what would make it even better. A massive improvement that is invisible to those pursuing pseudo-productivity metrics is the tremendous win of all the useless work not done. Not only does the core work compress dramatically when you understand what you are building, you catch wrong approaches before any lines are written, rather than after 820 files.

The velocity comes from the depth. Not despite it.

Deepening How We Work Together

The natural next question isn’t “why work with AI instead of alone?” Almost nobody is asking that, even though there are times when I think we should consider that for our own learning and development. We will explore this in another article in the series. The more common question is: “why not let the AI work alone?” If models keep improving, why not dispatch the work, review the output, and move on?

Because at some point, you have to engage with what was produced. You have to understand it well enough to debug it at 2am, explain it to a colleague, evolve it when requirements change, support users when it breaks. Ah, you say, but AI will also make all of this easier, and I’ll probably just use it to solve these problems for me too.

For any of us who have worked deeply with AI tools today, you will have seen it solve problems in unusual ways. The classic is fixing broken tests by deleting them. More commonly I see it overfitting and thrashing – adding a lot of workarounds to existing code to fix tests that may or may not still be relevant (overfitting), then having to fix other tests that fail because of the new workarounds, and adding more workarounds (thrashing).

These are today’s limitations, and they will improve. But the more insidious and impactful problems are the ones that don’t improve with better models; goal drift, loss of system coherence, and the slow erosion of your ability to understand, explain, and direct the system you’re accountable for.

If you’re accountable for the outcome – and for any work that matters, someone is – then the depth of your understanding at the point of engagement determines everything important downstream. This is true across knowledge work domains. Goh and colleagues (2024) found that AI alone produced better diagnostic answers than physicians working with AI. And a meta-analysis of 106 experimental studies confirmed the broader pattern: in tasks where AI alone outperformed humans, adding a human to the loop often made things worse (Vaccaro et al., 2024). There are tasks and domains where the right move is to let the AI work and stay out of the way.

But the same meta-analysis found that when humans outperformed AI, the combination improved performance. When you bring real understanding or expertise to the work – when you know the space – you know how to let the AI help. When you don’t, you make things worse. The question isn’t whether humans should always be in the loop. It’s whether, when you are in the loop, you bring enough understanding to improve the outcome rather than degrade it.

Furthermore, most of the time the generated answer isn’t the end of the work. It’s another beginning. The Goh study sounds like an argument for removing the physician – until you remember that someone has to act on the diagnosis, explain it to the patient, adjust when complications arise, integrate the diagnosis with everything else they know about this particular person’s life and values and fears, and be accountable when something goes wrong.

And we already know what happens when people try to exercise judgement on work they didn’t help create. The Invisibility Problem laid out the evidence: Goddard’s systematic review of 74 studies showed automation bias is robustly demonstrated across many work domains. The parallel agent workflow creates exactly the conditions that worsen it – cognitive load, time pressure, a firehose of output. “I’ll just review it” is the plan. Automation bias is what actually happens. You’re not just missing problems because you’re distracted. You’re systematically over-trusting output you don’t have the context to evaluate.

There’s a deeper asymmetry here. A reviewer who swoops in after the fact gets a snapshot. A deep pair who shaped the work from the start has trajectory – a compounding understanding of the system, the users, and the space between what was specified, what was needed and what was possible. Review doesn’t compound. Engagement does. And over time, that gap determines who can steer the system and who is just signing off on it.

This connects directly to the jagged frontier Dell’Acqua described – AI is excellent at some tasks, wrong at others – and unless you are expert enough users can’t tell which side of the line they’re on. Vaccaro’s meta-analysis confirmed this at scale: across 106 studies, the value of human involvement depended on which side you were on. On one side, the human improved the outcomes. On the other, they degraded them. And humans needed to do better than AI alone, in order to consistently get benefit from working with AI.

But the frontier isn’t static. It moves with every model release. What was outside AI’s capabilities six months ago may be inside them now. What seems safely inside today may have subtle failure modes that emerge only at scale. The only way to track where the boundary actually is – to develop real calibration rather than false confidence – is to stay close enough to the work to see the AI succeed and fail in real time. Deep pairing builds that calibration with every session. Parallel agents degrade it, because you’re too far from the work to notice when you’ve crossed to the wrong side.

The question isn’t whether you can dispatch the work. You can. The question is whether the person who’s accountable for the outcome has the understanding to fulfill that accountability – and whether they can see the frontier clearly enough to know when dispatching is safe and when it isn’t.

So the question becomes: how do we work with AI most effectively?

Research on collective intelligence suggested that interaction quality predicts group performance above and beyond individual ability (Woolley et al., 2010). But this field is in flux. Multiple studies have challenged the foundational findings – Bates and Gupta (2017) found individual IQ accounted for ~80% of variance in group performance, and Rowe, Hattie and Munro (2024) found that group intelligence may largely reflect individual crystallized and fluid intelligence rather than an emergent property of the group interaction. Whether “collective intelligence” is a real construct remains an open question.

But specific findings about how people work together more productively hold up independently of the debate. Bernstein, Shore and Lazer (2018) showed that intermittent interaction outperforms both constant and no interaction – groups that alternated between independent thinking and collaborative exchange explored more solutions and shared learning more effectively. That’s about the pattern of interaction, not emergent intelligence. And it’s exactly the rhythm of deep pair programming.

Three Trajectories

The abstract argument is one thing. Let me make it concrete with three trajectories I’ve watched play out – including in my own work.

Trajectory 1: High output, little understanding. A developer on our team has spent months using AI to generate code at an impressive rate. He hasn’t deepened his understanding of our development framework – Rails, which has powerful conventions and idioms that enable very useful “cognitive compression” (simplifying complex things into easy to understand concepts or conventions) and which when understood help to make the system understandable and concise. He can’t explain the code he delivers. He doesn’t practice test-driven development, and if he did I suspect I would just get hundreds of tests that he also did not understand. Every pull request requires me to pore over it looking for the edge cases that are always there.

The result: he’s effectively a prototyper, not a producer. His ability to contribute meaningfully has decreased, not increased, because the gap between what he produces and what production requires has widened. Deploying his code quickly has produced instability, improvements yes but an inconsistent user experience and, with the decrease in system coherence and understandability, painful public facing issues that are harder to fix and maintain.

This is the expected results of the parallel agent failure mode. He is not a bad developer, he is highly motivated and wants to see results for our users and our product and is passionate about improving and adding features. But the most appealing way, the pseudo-productivity way, has resulted in all out adoption of AI without an engagement pattern that makes it productive - either for our product, our team, or their development.

Most critical, he can’t see where the jagged frontier is. He can’t tell which of his outputs are good and which are subtly wrong, because he hasn’t built the understanding which makes detection possible, and he’s using a mode that effectively stops him from learning. Beyond the Dell’Acqua study and the Vaccaro meta-analysis discussed above, Bienefeld and colleagues (2023) found a version of this pattern in the clinical setting: using AI as a knowledge partner improved hypothesis generation but only in higher-performing teams. The tool amplifies what you bring to it.

On bounded, well-defined tasks, the pattern reverses – Brynjolfsson and colleagues found that novice workers benefited most from AI, and the METR study showed experienced developers were actually slower. For that kind of work, AI is a great equalizer. But for the complex, judgement-intensive work where detection ability and system understanding determine the outcome, what you bring to the collaboration determines what you get from it. In this situation, the lines added increased, and the debt compounded.

Trajectory 2: Fragmented attention, fast decay. I see the same pattern emerge in myself the moment I switch to multiple parallel sessions. The cascade from the science section plays out in real time: I start skimming where I was reading, I miss edge cases I would have caught, I lose the thread of the architectural reasoning. What surprises me most is how quickly it happens – once you are aware of it, you can detect it happening not over hours, but within minutes of the first switch. One second agent, one additional tab, one additional notification and the quality of your engagement drops in a way you can feel. The research says the switch itself consumes the cognitive resources you need for the next task. It feels exactly like that: a palpable loss of capacity that no amount of discipline compensates for once the switch is made. Your working memory has a hard ceiling.

Trajectory 3: Deep pairing, compounding returns. A part of my current practice (which includes deep pairing, solo development, deep contextual inquiry with users, and aspirationally more human pairing). One agent, full attention, intermittent rhythm. What I want to emphasize isn’t the practice (described in “The Rhythm”) but the outcome: each week, my understanding of the system, and the users it serves is deeper than the week before. The architectural decision I made three months ago still holds, because I understood why I was making them. The code I wrote last month is easy to modify because I remember the reasoning behind it. My velocity now – doing in half a day what I would have planned for a week – comes not from AI speed but from the accumulated understanding that compresses the work. And my feel for where the line is sharpens constantly - I know where the AI I’m working with excels and where it reliably goes wrong, and that calibration gets tested with every new model release, and gets more precise with every session.

These aren’t exceptional cases. They’re the trajectories the evidence predicts. Trajectory 1 is what happens when detection ability hasn’t been built through sustained engagement – automation bias fills the gap (Goddard et al., 2012) and the “generate and fix” loop runs afoul because of the jagged frontier and the judgement they haven’t developed. Trajectory 2 is what Leroy’s attention residue (2009) and Liefooghe’s working memory impairment (2008) predict the moment you fragment your focus. Trajectory 3 is what happens when the conditions for effective engagement are met: sustained focus on a single problem, intermittent rhythm between independent thinking and collaborative exchange (Bernstein et al., 2018), complementary capabilities distributed across two minds (Flor & Hutchins, 1991).

The difference between Trajectory 1 and Trajectory 3 isn’t talent or work ethic. It’s the engagement pattern. One compounds understanding. The other consumes it.

What Compounds

Each session of independent work or deep AI collaboration leaves you with more than code or a feature. It leaves you with understanding.

You can debug the code at 2am more quickly and effectively (with or without AI), because you watched it emerge and shaped it. You catch wrong approaches early because you’ve been thinking about the right approach the whole time. Your mental model of the system gets richer with each session, not more fragmented.

Over time you develop what Wegner (1987) called transactive memory - a learned sense of who knows what, what to delegate, and when to override. In the context of deep AI pairing, this means learning where the AI reliably excels, where it consistently goes wrong, when to trust its suggestions, and when your own judgement is more reliable. This calibration develops through sustained interaction – watching the AI succeed and fail on real problems, testing your predictions against its outputs, building a feel for where the frontier actually is. Each deep pairing session builds this calibration.

But deep pairing creates its own risk: cognitive offloading. The AI appears to remember everything and excel at everything, and when your partner seems that capable, you stop encoding things yourself. This is the Zoom transcript problem – the meeting is recorded, transcribed, and summarized, so nobody takes notes, nobody processes what was said, nobody follows up. The ubiquity and ease disintermediate the actual working process. With AI, the risk is subtler: you assume it holds your architectural decisions, your edge cases, your reasoning. It may. But if you don’t encode them too, you lose the understanding that makes you an effective partner – the very understanding that determines whether your involvement helps or hurts.

This is why independent work – without AI – remains essential for developers who pair deeply. Solo thinking forces encoding. When you work through a problem without the AI’s scaffolding, you hold the abstractions yourself, you notice what you don’t actually understand, you build the mental models that make the next pairing session productive. Deep pairing and independent work aren’t alternatives. They’re complementary. The pairing builds calibration and velocity. The solo work builds the foundation that makes the pairing productive. And it deepens your moat.

Not everything that compounds is technical. Deep pairing and independent work also build something harder to measure and arguably more important: your understanding of the problem space. The patterns in how users work, the friction points they can’t articulate, the moments where they hesitate or work around something instead of through it.

This is tacit knowledge – the understanding that emerges from rich engagement with the problem, from watching real people encounter real friction, from the creative leaps that come from being immersed long enough for the non-obvious connections to surface. You have ready access to this through a lifetime of lived experiential and emotive learning – which makes it much more effortless, interesting and meaningful for you. AI doesn’t. It takes significant effort to set up systems to get AI to watch a user’s face when a feature confuses them, harder still to have it understand the rhythm of how someone moves through a workflow, or to notice that the reason people aren’t using a feature is that it solves the wrong problem.

The developer in Trajectory 1 has been doing a lot of prototyping, but has missed out on so much learning, and has made it harder to get their code to production. The developer in Trajectory 3 sharpens with every session. Over time, the gap compounds dramatically. One developer’s architectural judgement improves, their feel for the codebase becomes intuitive, their understanding of the user’s problem deepens. The other has added more lines of code, but can’t explain why the system is built the way it is, can’t articulate where the next bug will surface, is less able to effectively direct their AI agents, and can’t see the elegant refactoring that would simplify the next six months of work.

The compound effect connects directly to the moat. The understanding that accumulates through deep engagement is precisely what makes a developer – and their products – irreplaceable. When the next model can generate everything a parallel agent workflow produces today, the developer who understands deeply still has something a model doesn’t: judgement born from sustained engagement with the problem, and the people it serves.

There is one final compounding benefit. The practice of deep pairing – staying in the problem, building shared context, learning what your partner knows and doesn’t – prepares you to pair more effectively with human experts too. And on most important problems, a human expert who knows a specific part of the problem space will see things that neither you nor the AI can.

AI’s broad general knowledge makes it tempting to skip the human conversation – you will feel like you already have an expert partner. You and the AI won’t be able to tell where it goes from helping to harming. The human expert can, and your practiced ability to stay in the problem with them, to build shared transactive memory, will amplify the benefit you get from that collaboration. Those who trained themselves to dispatch and switch will find this kind of sustained partnership much harder to do.

What This Feels Like

This approach takes discipline. The temptation to tab over and start a second task while the agent works is real – it feels like wasted time to sit and think while the machine thinks and types.

Embrace this time! Use it to stay in the problem space. While it’s tempting to think the AI is just going to solve it for you, your thinking during this time – how should it be solved, what issues or edge cases need to be considered, how might different approaches fit with the overall architecture, how will you test or measure if it actually works – has compounding benefits. You are better able to understand and redirect the output of the AI. You are cognitively prepared, so reviewing its work takes less effort. You’ve sustained the conditions for flow (Csikszentmihalyi, 1990): clear goals, immediate feedback and a challenge-skill balance where you take the time needed to think rather than being driven by the speed of the AI. And you deepen your understanding of the system and increase the intrinsic reward you feel from contributing to this hard, important, and now more interesting problem.

What deep pair programming actually feels like, when it’s working: you’re already two steps further by the time the AI completes its work. You steer, it adjusts, you go deeper. Hours disappear. You understand everything that was built, and can easily review and sign off on it, because you were there for all of it.

There’s a human dimension here that matters independently of any productivity argument. Independent work and deep pairing produces mastery, craft, growth – the genuine satisfaction of solving hard problems well and becoming better at your work. Dispatch orchestration produces ticket routing. Even if the outputs were identical, these are different kinds of work lives.

The developers in Trajectory 1 have produced lots of code. But they can’t explain it, and didn’t learn from it, and can derive satisfaction only from what they have delivered, not how it was built. If different approaches are required, or issues surface that are not obvious in the visible parts of the system - they are starting from near-zero – and should be nervous about how the system will behave in the real, messy world. The developers in Trajectory 3 are sharper, deeper than they were last quarter. They know it, and feel confident in the depth of their system, their understanding of it, and the changes that might be required in the future. They’ve already thought of many of them.

The discipline is simple to state and hard to maintain: stay in one problem, deeply, until it’s solved.

Solving The Paradox

I want to be clear about what I’m arguing for and what I’m not.

This isn’t an argument against automation. Where AI alone is better and you can verify the outcome – migrations, formatting, boilerplate, well-specified implementations with clear, comprehensive tests – let it work. And this isn’t an argument for humans-in-the-loop everywhere either. Vaccaro’s meta-analysis found that in tasks where AI outperformed humans, adding a human to the loop made things worse. Goh’s study also found that for diagnostic accuracy that had a standardized evaluation rubric, AI alone was better than human-AI combination. For well-defined tasks with clear acceptance criteria and verifiable outputs, full automation isn’t just acceptable – it’s the right call.

This is an argument about what to do when human judgement, understanding, and accountability are still needed – and when the jagged frontier makes it hard to tell where AI’s capabilities end. That’s most of the work that matters right now and, I think, in the future. The Vaccaro finding cuts precisely here: when humans brought real understanding to the collaboration, the combination improved performance. When they didn’t, it made things worse. The depth of your engagement isn’t just a nice-to-have. It determines whether your involvement helps or hurts.

Think of aviation. Modern aircraft are highly automated, and for good reason – automated systems handle routine flight better than human pilots. But when automation fails or encounters something outside its parameters, the pilot needs a deep understanding of the aircraft systems to take over safely. The pilots who handle these emergencies are the ones who maintained deep expertise through the automation era – not the ones who spent years passively monitoring autopilot. Where automation works, let it work. Where humans must intervene – because the problem is novel, the frontier is jagged, or accountability demands it – they need the depth that only sustained engagement builds.

The question isn’t parallel agents, deep pairing or independent work. It’s this: for the work where your involvement matters, which trajectory are you on? Are you building the understanding and skill that makes your involvement valuable – or are you monitoring dashboards while your ability to contribute erodes?

The practical heuristic: Do independent work at least a few days a month (decide up front). On other days, start every task together in deep pairing mode. Load the context collaboratively. Think through the approach. Identify what’s genuinely automatable versus what might have hidden complexity. Then decide explicitly whether to dispatch, to pair deeply, or to seek another expert. This initial collaborative assessment is itself a form of deep engagement – and it’s the most reliable way to see where the frontier is before you’ve already crossed it.

The goalposts will move. What counts as “safely automatable” will expand as AI improves. Work that requires deep pairing today may be safely dispatchable next year. But the frontier of genuinely hard problems – the ones that require uncovering tacit knowledge, integrating competing requirements, discovering what should be built rather than executing what was specified – those will continue to need human judgement. And the pattern of deep engagement prepares you for that frontier wherever it lands, because it allows you to see the boundary as it moves.

And even in a future where AI handles far more autonomously, in many important areas accountability won’t be fully delegated. Parallel dispatching leaves you signing off on work you can’t evaluate, and most quickly prepares you to be replaced. Independent work and deep pairing build the understanding needed in the moments that matter most – when knowing how to fly the plane and how the automated system flies the plane allows you to correct what it cannot.

Industry won’t stop building or promoting parallel agent architectures. Throughput is easy to measure and quality is hard. “We shipped 98% more PRs” is a much easier headline than “our developers understand their systems deeply enough to build something competitors can’t replicate”. And the developers using these tools will continue to report that they feel more productive, because the perception gap isn’t a bug we can patch – it’s a structural feature of how human cognition works.

So the question isn’t whether parallel agents will be adopted widely. They will. The question is what you choose to optimize for.

One path optimizes for throughput, and it produces output that depreciates with every model release. The other path optimizes for depth and appreciates over time – deepening your understanding of the system and the problem you are truly solving; deepening your skill in using AI and navigating the jagged frontier well; deepening your craft and the genuine satisfaction of solving hard problems well. The best developers know the difference – and will gravitate to the projects and organizations that offer the deeper path.

AI is an amplifier. Understanding, or the lack of it, is what gets amplified.

Hold me to account. My prediction, from the research and my experience: the deep approach will feel slower but will be faster over time. The velocity will come from the depth. And six months from now, you’ll have a system that you understand, with a deeper understanding of the real problem you are solving, and of how AI can help you. Or you will be faster, busier, and more cognitively overloaded orchestrating your increasingly capable agents and you will understand less of what they do, what the errors are going to be, and what the real problem you should actually be solving is.

It will feel less productive. It will be more productive. That’s the real paradox.

Next in the series:

[[capability-curve]] The Capability Curve: With Increasing AI Capability Will Human Coders Still Be Needed, a steel man critique of the Parallel Agent Paradox

[[productive-struggle-paradox]] The Productive Struggle Paradox: Why the Slowest Way to Use AI Is the Fastest Way to Learn and Grow

[[beyond-flow]] Beyond Flow: The Full Science of Sustained Deep Performance in an Age of AI aka Does Flow Actually Matter for Performance

[[same-project-different-minds]] Same Project, Different Minds: Where the Bright Line Actually Falls in Context Switching

References

Peer-Reviewed Research

Bates, T.C. & Gupta, S. (2017). “Smart groups of smart people: Evidence for IQ as the origin of collective intelligence in the performance of human groups.” Intelligence, 60, 46-56.
Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” arXiv:2507.09089.
Bernstein, E., Shore, J., & Lazer, D. (2018). “How intermittent breaks in interaction improve collective intelligence.” Proceedings of the National Academy of Sciences, 115(35), 8734-8739.
Bienefeld, N., Kolbe, M., Camen, G., Huser, D., & Buehler, P.K. (2023). “Human-AI teaming: leveraging transactive memory and speaking up for enhanced team effectiveness.” Frontiers in Psychology, 14, 1208019.
Braver, T.S. (2012). “The variable nature of cognitive control: a dual mechanisms framework.” Trends in Cognitive Sciences, 16(2), 106-113.
Brynjolfsson, E., Li, D., & Raymond, L.R. (2023). “Generative AI at Work.” NBER Working Paper 31161.
Cowan, N. (2001). “The magical number 4 in short-term memory: A reconsideration of mental storage capacity.” Behavioral and Brain Sciences, 24(1), 87-114.
Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row.
Czerwinski, M., Horvitz, E., & Wilhite, S. (2004). “A diary study of task switching and interruptions.” Proceedings of the ACM CHI Conference on Human Factors in Computing Systems.
Dell’Acqua, F., McFowland, E., Mollick, E.R., Lifshitz-Assaf, H., Kellogg, K., Rajendran, S., Krayer, L., Candelon, F., & Lakhani, K.R. (2023). “Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality.” Harvard Business School Technology & Operations Mgt. Unit Working Paper No. 24-013.
Finley, J.R., Benjamin, A.S., & McCarley, J.S. (2014). “Metacognition of multitasking: How well do we predict the costs of divided attention?” Journal of Experimental Psychology: Applied, 20(2), 158-165.
Flor, N.V. & Hutchins, E.L. (1991). “Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance.” Empirical Studies of Programmers: Fourth Workshop, Ablex Publishing.
Goddard, K., Roudsari, A., & Wyatt, J.C. (2012). “Automation bias: a systematic review of frequency, effect mediators, and mitigators.” Journal of the American Medical Informatics Association, 19(1), 121-127.
Goh, E., Gallo, R., Hom, J., Strong, E., et al. (2024). “Large Language Model Influence on Diagnostic Reasoning: A Randomized Clinical Trial.” JAMA Network Open, 7(10), e2440969.
Harris, D.J., Allen, K.L., Vine, S.J., & Wilson, M.R. (2021). “A systematic review and meta-analysis of the relationship between flow states and performance.” International Review of Sport and Exercise Psychology, 16(1).
Hyman, I.E., Boss, S.M., Wise, B.M., McKenzie, K.E., & Caggiano, J.M. (2010). “Did you see the unicycling clown? Inattentional blindness while walking and talking on a cell phone.” Applied Cognitive Psychology, 24(5), 597-607.
Leroy, S. (2009). “Why is it so hard to do my work? The challenge of attention residue when switching between work tasks.” Organizational Behavior and Human Decision Processes, 109, 168-181.
Liefooghe, B., Barrouillet, P., Vandierendonck, A., & Camos, V. (2008). “Working memory costs of task switching.” Journal of Experimental Psychology: Learning, Memory, and Cognition, 34(3), 478-494.
Mark, G., Gonzalez, V., & Harris, J. (2005). “No Task Left Behind? Examining the Nature of Fragmented Work.” Proceedings of the ACM CHI Conference on Human Factors in Computing Systems, 321-330.
Mark, G., Gudith, D., & Klocke, U. (2008). “The cost of interrupted work: More speed and stress.” Proceedings of the ACM CHI Conference on Human Factors in Computing Systems, 107-110.
Miller, G. (1956). “The Magical Number Seven, Plus or Minus Two.” Psychological Review, 63(2), 81-97.
Newport, C. (2024). Slow Productivity: The Lost Art of Accomplishment Without Burnout. Portfolio/Penguin.
Noy, S. & Zhang, W. (2023). “Experimental evidence on the productivity effects of generative artificial intelligence.” Science, 381(6654), 187-192.
Ophir, E., Nass, C., & Wagner, A.D. (2009). “Cognitive control in media multitaskers.” Proceedings of the National Academy of Sciences, 106(37), 15583-15587.
Parnin, C. & DeLine, R. (2010). “Evaluating cues for resuming interrupted programming tasks.” Proceedings of the ACM CHI Conference on Human Factors in Computing Systems, 93-102.
Parnin, C. & Rugaber, S. (2011). “Resumption strategies for interrupted programming tasks.” Software Quality Journal, 19(1), 5-34.
Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” arXiv:2302.06590.
Pluut, H., Darouei, M., & Zeijen, M.E.L. (2024). “Why and when does multitasking impair flow and subjective performance?” Frontiers in Psychology, 15, 1384453.
Rowe, L.I., Hattie, J., & Munro, J. (2024). “High-performing teams: Is collective intelligence the answer?” PLOS ONE, 19(8), e0307945.
Rubinstein, J.S., Meyer, D.E., & Evans, J.E. (2001). “Executive control of cognitive processes in task switching.” Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763-797.
Sanbonmatsu, D.M., Strayer, D.L., Medeiros-Ward, N., Watson, J.M., & Chambers, C. (2013). “Who Multi-Tasks and Why? Multi-Tasking Ability, Perceived Multi-Tasking Ability, Impulsivity, and Sensation Seeking.” PLoS ONE, 8(1), e54402.
Simkute, A., Tankelevitch, L., Kewenig, V., Scott, A.E., Sellen, A., & Rintel, S. (2024). “Ironies of Generative AI: Understanding and Mitigating Productivity Loss in Human-AI Interaction.” International Journal of Human–Computer Interaction, 1-22.
Skitka, L.J., Mosier, K.L., & Burdick, M. (1999). “Does automation bias decision-making?” International Journal of Human-Computer Studies, 51(5), 991-1006.
Vaccaro, M., Almaatouq, A., & Malone, T. (2024). “When combinations of humans and AI are useful: A systematic review and meta-analysis.” Nature Human Behaviour, 8(12), 2293-2303.
Wegner, D.M. (1987). “Transactive Memory: A Contemporary Analysis of the Group Mind.” In B. Mullen & G.R. Goethals (Eds.), Theories of Group Behavior. Springer.
Wiradhany, W. & Nieuwenstein, M.R. (2017). “Cognitive control in media multitaskers: Two replication studies and a meta-analysis.” Attention, Perception, & Psychophysics, 79(8), 2620-2641.
Woolley, A.W., Chabris, C.F., Pentland, A., Hashmi, N., & Malone, T.W. (2010). “Evidence for a Collective Intelligence Factor in the Performance of Human Groups.” Science, 330(6004), 686-688.

Industry Research & Books

Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
Christensen, C.M. (1997). The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business Review Press.
DOJ Office of Inspector General (2014). Audit of the Status of the Federal Bureau of Investigation’s Sentinel Program. Audit Report 14-31.
Google DORA Report (2024, 2025). Accelerate State of DevOps.
CodeScene (2024). Code health analysis: unhealthy code metrics.
Harding, W. (2025). “AI Copilot Code Quality: Evaluating 2024’s Increased Defect Rate via Code Quality Metrics.” GitClear.
Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business.

Narath

Discussion about this post

Ready for more?