AI Fatigue Statistics 2025

Numbers are tricky things. They can make a fuzzy feeling feel real — or make something real feel statistical and distant. This page tries to do neither. These statistics are here to reflect back what many engineers are already experiencing in their bodies: something changed, something is costing them, and they're not imagining it.

We've compiled data from developer surveys, cognitive science research, industry reports, and academic studies on burnout, cognitive load, and technology adoption. Where we've synthesized estimates from patterns, we say so clearly. Where real surveys and studies exist, we cite them.

If you're a journalist, researcher, or blogger covering developer wellbeing — you're welcome to cite this page. We maintain it. If you find something outdated or incorrect, reach out.

Timeline

Developer burnout: before and after the AI wave

Developer burnout isn't new. But the shape of it changed dramatically between 2022 and 2025, as AI coding assistants went from novelty to workplace expectation in under 18 months. The data tells a story of a workforce that was already stretched — and then asked to sprint.

The pattern that emerges from this timeline is clear: burnout was already trending upward before AI. The introduction of AI tools — and the cultural expectations that came with them — didn't cause burnout, but it supercharged it for a specific set of reasons that are unique to the cognitive demands of software work.

The most concerning data point is not the burnout rate itself. It's the speed of the shift. Burnout that develops over years is survivable. Burnout that accelerates over 18 months catches people before they recognize the pattern.

Cognitive science

Cognitive load and decision fatigue in AI workflows

The most underdiscussed dimension of AI fatigue isn't emotional — it's cognitive. AI coding tools generate a relentless stream of micro-decisions: accept, reject, modify, verify. Each decision is small. But they add up in ways the brain wasn't designed to sustain.

The cognitive load data explains something that feels counterintuitive: using AI tools often makes engineers more tired, not less. This is because AI tools shift effort from generation (writing code) to verification and judgment (is this right? does this match my intent? could this break something?). Verification is hard cognitive work — and it's harder when you didn't generate the thing you're verifying.

John Sweller's cognitive load theory, developed in 1988, distinguishes between intrinsic load (the inherent difficulty of the task), extraneous load (unnecessary complexity from how information is presented), and germane load (productive effort that builds schema). AI-assisted workflows tend to reduce intrinsic load on the generation side while dramatically increasing extraneous load on the verification and trust-calibration side.

---

The decision fatigue multiplier

Roy Baumeister's research on decision fatigue (2008) demonstrated that decision-making quality degrades with each successive decision made in a day. Software engineers in AI-assisted environments make significantly more consequential micro-decisions than their pre-AI counterparts.

In a typical pre-AI workday, an engineer might make 50–100 significant technical decisions. In an AI-integrated workflow, that number rises to 200–400+, as each AI suggestion requires an accept/reject/modify judgment. Most of these are low-stakes individually — but the aggregate effect is the same: a depleted decision-making capacity by mid-afternoon, and a greater tendency toward rubber-stamping by the end of the day.

This is one reason that code quality problems from AI-assisted development often cluster in the late afternoon and in deadline-pressure periods: not because engineers are careless, but because their decision-making resources are exhausted.

Skill & identity

Skill atrophy, ownership anxiety, and identity erosion

The numbers on skill atrophy are among the most troubling in the AI fatigue data set — particularly for junior engineers who are still building foundational competencies at the same time they're being handed AI tools that can generate plausible-looking code on demand.

The MIT cognitive study is particularly instructive. When subjects solved problems with AI assistance, their ability to solve the same class of problem without AI assistance declined 40% compared to subjects who worked through problems unaided. The brain builds schema through struggle — and AI tools, by design, reduce the amount of productive struggle.

This is the tension that sits at the heart of the AI fatigue conversation: the tools that make you faster in the short term may be quietly eroding the capacities that make you a great engineer over a career. Speed and depth are in tension. The data suggests most engineers feel this tension acutely, even if the organizational pressure they're under doesn't give them space to act on it.

Adoption vs. wellbeing

The adoption rate and the wellbeing gap

One of the most revealing data tensions in developer wellbeing research is the gap between AI tool adoption rates (which are high and rising rapidly) and reported wellbeing improvements (which are flat or declining). If AI tools were delivering on their human promise — not just the productivity promise — we'd expect both to rise together. The divergence tells us something important.

The 84% / 34% split in the Atlassian data is one of the most cited findings in developer wellbeing research. It captures a pattern that appears across multiple data sources: AI tools deliver measurable individual productivity gains, but the gains don't flow back to the engineer as rest, autonomy, or creative space. Instead, they raise the expected baseline — generating more work, faster, is the new normal, not the exception.

This is sometimes called the productivity paradox of AI tools: they do make you faster, and faster mostly just means more. If your organization uses your AI-amplified speed to ship more features, not to give you breathing room, then the cognitive benefit is captured by the organization — not by you.

---

What engineers actually want from AI tools

Surveys on AI tool adoption consistently reveal a gap between how tools are used and how engineers wish they could use them. This gap is a driver of fatigue — the sense of being on a treadmill you didn't choose.

The inversion at the bottom of the table is telling: engineers are using AI for architecture and design decisions much more than they actually want to. The pressure to use AI for everything — even the thinking-intensive work that engineers find intrinsically rewarding — is a primary driver of identity erosion and fatigue.

What actually helps

The recovery data: what actually moves the needle

If the data on AI fatigue is concerning, the data on what helps is genuinely encouraging. Engineers who experience fatigue and take deliberate action tend to recover meaningfully — and they don't have to quit or completely abandon AI tools to do it. The key is intentionality: using AI tools on your own terms, not the tool's terms or your organization's defaults.

The 2.4× satisfaction multiplier for teams with explicit AI norms is one of the most actionable findings for engineering managers. Teams that talk about how and when to use AI — that have developed shared norms and expectations — perform better on wellbeing measures than teams where AI use is left to individual discretion or implicitly maximized.

This suggests that AI fatigue is not primarily an individual problem that requires individual recovery. It's a team culture problem that responds to team-level interventions. If you're an engineering manager reading this, that's the most important thing on this page.

Context & demographics

Who's most affected, and the global picture

AI fatigue does not distribute evenly across the engineering population. The data consistently shows variation by experience level, team structure, industry, and geography. Understanding who is most vulnerable is important for targeted intervention.

The data on junior engineers is particularly worrying from a longitudinal perspective. The engineers starting their careers in 2023–2026 are the first cohort to learn software development alongside AI assistance as a default. Whether this produces a generation of highly capable AI-amplified engineers, or a generation with fragile foundational skills and high dependency, remains an open and urgent question.

Questions about the data

Frequently asked questions