TL;DR: AI gave small teams infinite velocity but broke their processes. The data on cognitive debt, brain fry, and what surviving teams do differently.

A three-person team. Around 50 pull requests a day. Four autonomous agents running in parallel. A content engine that publishes every few hours without human intervention. From the outside, this looks like the AI productivity dream. From the inside, the process breaks every week because a new capability just invalidated the workflow you spent two days stabilising. If this sounds familiar, the data now confirms you are not alone, and the fix is not more AI.

The productivity narrative around AI coding agents in 2026 is almost entirely about capability: what the tools can do, how fast they generate code, how many tasks they can run in parallel. What almost nobody talks about is what happens to the humans operating those tools at full throttle, the decision fatigue, the process churn, the review backlog, and the unsettling feeling that you are moving faster than you can think.

This article is about that gap, and it is written by someone who has been studying it for over a decade. My published research on information overload in intelligent agent systems (Costa & Macedo, AAMAS 2014) proposed computational models of selective attention that allow agents to autonomously filter information and manage cognitive load. A decade later, the problem I studied in theory is the problem my team lives every day.


The Productivity Paradox and the Review Bottleneck

The promise was a step change in output. The data says otherwise.

Faros AI analysed engineering metrics across organisations adopting AI coding tools (S1). High-adoption teams merged 98% more pull requests, but PR review time rose 91%. Net throughput barely moved, the gains in production were almost entirely consumed by the review bottleneck.

A METR randomized controlled trial found that experienced open-source developers took 19% longer on real tasks when allowed to use AI tools, even though they estimated afterwards that AI had made them 20% faster (S2). The overhead of prompting, reviewing AI output, correcting hallucinations, and managing context exceeded the time the AI saved on writing code.

This does not mean AI tools are useless. It means the bottleneck moved. Production is no longer the constraint. Comprehension is.

Thoughtworks Technology Radar Vol. 34 (April 2026) (S4) introduced the term that captures this shift: cognitive debt, the widening gap between how much code exists in a codebase and how much any human actually understands. When AI generates code faster than humans can review it, the codebase grows in size but shrinks in understanding. That understanding debt compounds with every merged PR that nobody fully reviewed.


AI Brain Fry Is a Clinical Finding, Not a Meme

BCG surveyed 1,488 US workers and published the results in March 2026.

BCG named the phenomenon "AI brain fry" (S3). Workers whose AI use required high oversight expended 14% more mental effort, and reported:

  • 39% more major errors in their work
  • markedly higher intent to leave their job
  • 19% more information overload under high AI oversight

Workers described the experience as "fog," "buzzing," and needing to physically walk away from the screen. The condition is worst among people who use AI tools the most intensively, not the casual users, but the power users. The people who are supposed to be benefiting the most are the ones most likely to burn out.

This is not a failure of the technology. It is a failure of the operating model. AI reduces the cost of production but increases the cost of supervision. The supervision cost falls entirely on the human.


The Slot Machine Problem

Axios published a piece on April 4, 2026 with a headline that made every AI power user uncomfortable: They operate like slot machines: AI agents are scrambling power users' brains (S5).

Andrej Karpathy, one of the most respected AI researchers alive, admitted to being in a "state of AI psychosis," spending 16 hours a day issuing commands to agent swarms. He described feeling "extremely nervous" when tokens went unused near month-end. Axios compared this pattern directly to gambling behaviour.

Tim Dettmers noted that peak productivity with AI agents requires running as many agents as possible in parallel, which demands near-constant context switching. The cognitive load is not reduced by AI, it is transformed from writing code to managing agents, and the second task has no natural stopping point.

Commentators dubbed the period a great productivity panic.

The paradox is real: capability expansion creates compulsion, not freedom. When you can automate anything, you feel compelled to automate everything. When the agents run overnight, you feel guilty for sleeping. When a new skill or integration appears, you feel behind for not having adopted it yesterday.


Automation Without Standards Just Moves Faster

That idea, automation without standards simply produces faster churn, recurs across analyses of AI-accelerated delivery.

The finding is consistent across every analysis: AI does not correct broken processes. It amplifies them. A team that ships without clear review standards will ship broken code faster. A team that has no documentation will generate more undocumented code. A team that has no governance will deploy more ungoverned agents.

This is the stabilisation problem that every AI-accelerated team encounters:

  1. You adopt AI tools and your output triples
  2. You realise your process cannot handle triple the output
  3. You build a new process to handle the volume
  4. A new AI capability arrives that changes what is possible
  5. Your process is outdated before it stabilised
  6. Repeat from step 1

The result is not faster delivery. It is faster churn. The team is not shipping more value, it is shipping more change. And change, without stabilisation, is just work.


This Is Not a New Problem, It Is an Old Problem at New Scale

In 2013, I co-authored research on emotion-based recommender systems for overcoming information overload (Costa & Macedo, PAAMS 2013) (S7). The core finding was that intelligent agents cannot simply deliver all available information to humans, they must implement selective attention, considering not just relevance but the user's cognitive and emotional state.

In 2014, at AAMAS (the top venue for autonomous agents research), I presented a computational model of selective attention for intelligent agents (S6) based on the principle that uncertain, surprising, and motive-congruent information demands attention, while everything else should be filtered.

The irony is vivid. A decade ago, I was building BDI (Belief-Desire-Intention) agents that could autonomously decide what information to show a human and what to suppress. Today, I run a team where AI agents generate 50 pull requests a day, and the information overload problem I studied in theory is the operational reality I manage every morning.

The BCG brain-fry data, the Thoughtworks cognitive-debt concept, and the Axios slot-machine comparison are all describing the same phenomenon my research identified in 2013: when agents produce faster than humans can absorb, the system needs selective attention, not more output.

The agents we use today are missing this. They maximise production. They do not manage human cognitive load. That is the engineering gap.


The 3-Person Team Is Real But Fragile

The pattern exists. Public accounts describe engineers rebuilding entire multi-agent platforms in under two weeks, directing many parallel Claude Code agents from a laptop and phone. Multiple teams report enterprise-scale output from three-person squads augmented by AI agents.

But those same accounts describe having to rebuild version one entirely because it was too tightly coupled. The speed of creation exceeded the quality of architecture. This is not an exception, it is the pattern.

Small teams can produce at enormous scale with AI agents. They cannot maintain at that scale without process infrastructure they have not built yet. The production was instant. The maintenance debt is forever.


What the Teams That Survive Are Doing Differently

Thoughtworks Radar Vol. 34 offers the most credible prescription: go back to fundamentals as a counterweight to AI-generated complexity.

1. Measure Comprehension, Not Throughput

Stop counting PRs merged per day. Start measuring: - Iteration cycles per task, how many times does a piece of work get reworked? - Post-merge rework rate, how many PRs require follow-up fixes within 7 days? - Time to understand, how long does it take a new team member to understand a module?

If your throughput is high but your rework rate is rising, you are not productive, you are busy.

2. Institute Process Freeze Periods

Not everything needs to be automated this week. Set explicit periods where the process is frozen, no new tools, no new integrations, no new workflows. Use the freeze to let the current process stabilise, identify what is working, and document it before the next change.

3. Pair on Review, Not on Writing

The bottleneck is not writing code. It is reviewing code. AI writes; humans review. Pair programming in 2026 means two humans reviewing AI output together, catching the things neither would catch alone.

4. Document Before You Automate

Every automation should start with documentation: what does this workflow do, why does it exist, what are the inputs and outputs, what happens when it fails? If you cannot document it, you should not automate it.

5. Accept That Slower Is Sometimes Faster

The METR data shows developers are sometimes slower with AI tools. This is not a bug, it is the cost of quality. An engineer who spends 20 minutes reviewing AI output carefully is more valuable than one who approves 10 PRs in 20 minutes without understanding them.


The Real Question for Engineering Leaders

The question is not how fast can we move with AI? Your team already answered that, fast. Very fast. Possibly too fast.

The question is: at what speed can your team move while still understanding what it ships?

That speed is your sustainable velocity. Everything above it is cognitive debt accruing at interest.


Frequently Asked Questions

Is AI actually making developers less productive?

Not less productive, differently productive. AI dramatically increases output volume but shifts the bottleneck from production to comprehension and review. Net productivity depends on whether the team has processes to handle the review burden. Without those processes, the 19% slower finding from METR is not surprising.

How do you handle 50 PRs a day with 3 engineers?

Automated CI gates (tests must pass), automated linting, AI-assisted review comments, and selective auto-merge for low-risk changes (dependency updates, formatting). Human review is reserved for architectural changes, security-sensitive code, and anything touching production data.

What is cognitive debt and how do you measure it?

Cognitive debt is the gap between how much code exists and how much anyone understands. Measure it through: time to onboard new team members, post-merge rework rate, and the number of modules where only a single teammate can explain what the code does.

Should we slow down our AI agent usage?

Not slow down, structure. The issue is not speed; it is ungoverned speed. Set review gates, documentation requirements, and process freeze periods. Use AI for production; use humans for comprehension and decision-making.

How do I know if my team has AI brain fry?

Watch for: rising error rates despite stable or increasing output, team members describing fog or decision paralysis, increasing time spent reviewing rather than creating, and, the clearest signal, people saying they need to step away from the screen more often than before AI adoption.


Further Reading

  • The Agentic AI Adoption Framework European SMEs Need in 2026
  • How to Build an AI Security Posture for Your Engineering Organisation
  • Every AI Coding Agent CLI in April 2026 Compared
  • Shadow AI in Engineering Teams: How to Detect It and Decide What to Do

Get Ahead of the Stabilisation Problem

If your team is moving fast but feels like it is not moving forward, the issue is not capability, it is governance. The processes, documentation, and review structures that turn velocity into value are not optional add-ons. They are the chassis without which the engine eventually crashes.

Start with an AI Readiness Assessment to identify where your governance, process, and team capability gaps are. The process maturity dimension is specifically designed to diagnose the stabilisation problem.

If your team needs structured help, building review processes, writing agent governance docs, or designing a sustainable operating model for AI-accelerated development, explore our Fractional CAIO retainer. This is exactly the problem it was built to solve.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.