"AI Brain Fry" Causes 33% More Decision Fatigue and 39% More Major Mistakes—Simon Willison Called Out His Own Burnout. Who Designs the Recovery?

General
1

I have been thinking about this a lot since reading the BCG/Harvard study published in HBR last month, and then watching Simon Willison—literally one of AI’s most enthusiastic advocates—publicly call out his own burnout in April.

Let me put the numbers on the table first.

The BCG/Harvard Study: “AI Brain Fry” Is Now a Named Condition

Boston Consulting Group researchers surveyed roughly 1,500 workers and found a pattern they called “AI brain fry”: mental fatigue from excessive use or oversight of AI tools beyond cognitive capacity. Workers describe it as a “buzzing” feeling, mental fog, difficulty focusing, slower decisions, headaches.

The data:

  • 33% increase in decision fatigue among workers experiencing brain fry
  • 39% more major errors compared to unaffected peers
  • 11% more minor errors on top of that
  • 12% more mental fatigue from high-oversight AI use specifically
  • 19% more information overload when managing multiple AI tools
  • Productivity peaks at 1-3 AI tools, then declines at 4+

That last point hit me. My team is currently juggling Cursor, Claude Code, Copilot, various internal AI tools, plus AI-assisted monitoring. That is well past 4.

Simon Willison: The Canary in the Coal Mine

Simon Willison—Django co-creator, one of the most prolific AI tool advocates in our industry—said in February 2026 that “nearly every software engineer I talked to was experiencing some degree of mental health crisis.” He described using AI coding agents as mentally exhausting even as they make work faster. His exact words: he can fire up four agents in parallel and be “wiped out for the day by 11 a.m.”

He also introduced the concept of “cognitive debt”—when we lose track of how code written by our agents works, we take on cognitive debt. The core of our application becomes a black box we cannot confidently reason about, which slows planning and compounds like technical debt.

If the person who evangelizes these tools more than anyone is saying this, the rest of us need to pay attention.

What I Am Seeing in My Organization

I lead engineering at a 200-person EdTech company. Here is what I have noticed since we accelerated AI tool adoption 8 months ago:

  1. The “always on” illusion. AI removed the natural pauses. Writing code used to have built-in think time—waiting for compilation, reading docs, sketching on a whiteboard. Now it is one prompt away from the next task. There is no recovery built into the workflow.

  2. Supervision is the new bottleneck. The BCG study found that the most mentally taxing part is not using AI tools—it is supervising them. My senior engineers are spending their cognitive budget reviewing AI output instead of designing systems. They are more tired, not less.

  3. Weekend commits are up 40%. Not because I asked for it. The research backs this up—96% of heavy AI tool users report working evenings and weekends. AI made it possible to be productive at midnight, so now people are productive at midnight.

  4. Context-switching across 6 parallel streams. One engineer told me she manages her own code, two Cursor sessions, a Claude Code task, a PR review of AI-generated code, and monitoring dashboards—simultaneously. That is 6 cognitive threads. The neuroscience is clear: each context switch costs 15-25 minutes of refocusing time.

The Leadership Question Nobody Is Answering

Here is what frustrates me: the industry conversation is still stuck on “are AI tools making us more productive?” The answer is obviously yes at the task level and obviously complicated at the human level.

The real question is: who is responsible for designing sustainable AI workflows?

  • Is it the individual engineer? (“Just take breaks.”)
  • Is it the team lead? (“Set boundaries.”)
  • Is it engineering leadership? (“Design the system.”)
  • Is it the tool vendors? (“Build in friction.”)

I think it is squarely on us—engineering leaders. We chose the tools. We set the expectations. We measure the output. If our people are burning out, that is a systems design failure, not an individual discipline failure.

What I Am Experimenting With

I do not have answers yet, but here is what we are trying:

  1. “AI-free blocks”: 2-hour windows where engineers work without AI assistance. Forces slower, deeper thinking.
  2. Agent limits: No more than 2 concurrent AI sessions. If you are supervising 4 agents, you are supervising none of them well.
  3. Review rotation caps: No engineer reviews more than 3 AI-generated PRs per day. The cognitive load of verifying code you did not write is real.
  4. Cognitive load retrospectives: Added “how mentally drained are you?” to sprint retros. Tracking it like we track velocity.

Early signs are mixed. Engineers initially resist the AI-free blocks (“you are slowing me down”), but after two weeks most say their afternoon productivity is higher.

The Uncomfortable Parallel

Goldman Sachs published their own uncomfortable conclusion: “We still do not find a meaningful relationship between productivity and AI adoption at the economy-wide level.”

Maybe the reason is that we are measuring machine throughput while paying the cost in human cognition. The gains at the task level are being eaten by the losses at the human level.

I would love to hear from other leaders: Are you seeing the same patterns? Are you measuring cognitive load at all? Or are we all just watching the velocity charts go up while our people quietly burn out?

2

Keisha, thank you for putting real numbers behind what many of us have been feeling but could not articulate to our leadership teams.

I manage 40+ engineers at a Fortune 500 financial services company, and I want to push back on one thing and strongly agree on another.

Where I Push Back: “AI-Free Blocks” May Be the Wrong Frame

I experimented with AI-free blocks for three weeks. My team hated them—not because they are addicted to the tools, but because the framing felt paternalistic. “We are taking away your tools for your own good” does not land well with senior engineers.

What worked better for us was “deep work blocks”: 2-hour windows where the goal is sustained focus on a single problem, and engineers choose their own tools. Some use AI. Some do not. The point is single-threaded focus, not tool restriction.

The BCG study says productivity peaks at 1-3 tools. I think the real insight is not about tool count—it is about cognitive thread count. One AI tool used for 3 parallel tasks is worse than 3 AI tools used for 1 sequential task.

Where I Strongly Agree: Supervision Is Destroying Senior Engineers

This is the crisis nobody talks about. My best architects—people with 15+ years of experience who should be designing the next generation of systems—are spending 60-70% of their time reviewing AI-generated code from junior engineers and agents.

They did not sign up for this. They are not doing architecture. They are doing quality assurance for machines. And because the code looks clean (AI is excellent at formatting), the reviews require deeper cognitive effort to find the subtle logic errors.

I lost two senior engineers in Q1. Both cited “the work changed and nobody asked me” in their exit interviews. One said: “I used to design systems. Now I babysit agents.”

What Financial Services Teaches About This

In banking, we have regulatory concepts like “maker-checker” workflows and “four-eyes principle.” These exist because humans make more errors under time pressure and fatigue. The regulators understood this decades ago.

We are applying none of that institutional knowledge to AI workflows. We let engineers self-regulate their cognitive load. We let them be both the maker (prompting the AI) and the checker (reviewing the output) simultaneously. In financial services, that would be a compliance violation.

My proposal to leadership next quarter: formal cognitive load budgets. Every engineer gets a daily “cognitive token” allocation. AI supervision burns tokens at 2x the rate of direct work. When you are out of tokens, you switch to documentation, planning, or mentoring. Not more code.

It sounds bureaucratic. But so did incident management before PagerDuty. Sometimes the right answer is structured rest, not just telling people to take breaks.

3

I want to bring a different angle here because I think this conversation is missing the design perspective entirely.

The Tools Themselves Are Designed to Maximize Engagement, Not Sustainability

I have spent 12 years in design. I know what dark patterns look like. And honestly? The current generation of AI coding tools exhibits several engagement-maximizing patterns that work directly against cognitive sustainability:

  • Instant gratification loops. Prompt, get code, prompt again. No friction. No pause. This is the same dopamine loop that makes social media addictive, except now it is in your IDE.
  • Infinite scroll equivalents. Claude Code and Cursor will keep generating. They never say “maybe you should stop and think about this for 10 minutes.” The tool has no concept of “enough.”
  • Loss aversion in context windows. Engineers tell me they feel anxious about “losing” a good conversation context. So they keep going instead of taking breaks. The context window creates artificial urgency.

When Keisha asks “is it the tool vendors?”, my answer is partially yes. These tools are designed by companies whose business model depends on usage volume. More prompts = more API calls = more revenue. There is zero incentive to build in cognitive friction.

What “Designing Rest” Actually Looks Like

From a UX perspective, sustainable AI workflows need what we call “deliberate friction”:

  1. Completion signals. The tool should tell you when a task unit is done and suggest a pause. “You have been in this session for 90 minutes. Your last 3 prompts had diminishing returns. Good time for a break?”
  2. Single-task modes. A “focus mode” that disables parallel agent sessions. One conversation, one problem, full attention.
  3. Cognitive load indicators. Like a battery meter for your brain. Track prompt velocity, context switches, and session duration. Surface it visually.
  4. Cool-down periods. After extended sessions, a 5-minute enforced pause before starting a new task. Yes, engineers will hate it. They also hated seatbelts.

None of the major AI coding tools have any of these features. Not one. Because building them would reduce engagement metrics.

The Startup Founder Perspective

When I was running my startup, I burned out hard. Not because the work was too much—because there were no natural stopping points. AI coding is the same trap at industrial scale. The work expands to fill every available cognitive cycle because the tools never say “stop.”

The Simon Willison point really resonates. He is one of the most disciplined, experienced developers alive, and even he cannot self-regulate against tools optimized for continuous engagement. That should terrify every engineering leader in this thread.