UC Berkeley Study: AI Power Users Are Burning Out First, 62% Report Unsustainable Workloads

[data_rachel]

I need to share something that hit me hard this week. UC Berkeley’s Haas School of Business just published an eight-month study that tracked 200 employees at a U.S. tech company, and the findings confirm what I’ve been seeing in my own org for the past six months: the people who embrace AI the most are burning out the fastest.

The researchers, led by Associate Professor Aruna Ranganathan and Xingqi Maggie Ye, spent eight months doing twice-weekly in-person observations, tracking communication channels, and conducting 40+ in-depth interviews across engineering, product, design, research, and operations. This wasn’t a survey monkey questionnaire. This was rigorous ethnographic research inside a real company.

The Core Finding: “Workload Creep”

Here’s the devastating punchline: AI tools didn’t reduce work. They consistently intensified it. Employees worked at a faster pace, took on a broader scope of tasks, and extended work into more hours of the day – often without being asked to do so.

The researchers identified a phenomenon they call “workload creep.” When individual tasks were completed faster with AI, the time saved was NOT reclaimed by employees for rest or deep thinking. Instead, it was immediately filled with more work – often of a different nature than the employee’s core role. Product managers started writing code. Researchers took on engineering tasks. The boundaries of everyone’s jobs expanded.

The Burnout Numbers Are Stark

By month six of the study:

• 62% of associates and 61% of entry-level workers reported burnout
• Only 38% of C-suite leaders reported the same
• Reports of anxiety, decision paralysis, and cognitive fatigue spiked across the board

Let that sink in. The people doing the most hands-on work with AI tools – your ICs, your junior and mid-level engineers, your associates – are burning out at nearly double the rate of your executives. And the executives are the ones making the decisions about how aggressively to adopt AI.

What I’m Seeing in My Own Org

I lead an engineering org that’s grown from 25 to 80+ engineers in the past 18 months. We adopted AI coding assistants aggressively starting mid-2025. And here’s what I’ve observed that perfectly mirrors the Berkeley study:

1. Sprint velocity went up, but so did scope. When teams shipped features 30% faster, product immediately backfilled with 30% more work. The treadmill got faster, not shorter.

2. Context switching exploded. Engineers who used to deep-focus on one domain started “helping out” across codebases because AI made unfamiliar code more approachable. Good in theory. Exhausting in practice.

3. The invisible labor of AI supervision. Nobody accounts for the time spent reviewing AI-generated code, debugging subtle AI-introduced bugs, or the cognitive load of constantly evaluating whether AI output is correct. My senior engineers report spending 40-60 minutes per day just validating AI suggestions.

4. Work bleeding into personal time. Several team members told me in 1:1s that because AI makes it “easy” to knock out a quick fix at 9pm, they find themselves doing it. The activation energy for work dropped to near zero, and the boundary between work and life dissolved.

The “Intensification Trap”

The HBR article frames this as an “intensification trap,” and I think that’s exactly right. A DHR Global survey of 1,500 corporate professionals found 83% experiencing burnout, with overwhelming workloads and excessive hours as the top culprits.

Here’s the mechanism: AI makes you individually faster. Management sees the increased output. Management raises expectations. You now need AI just to keep up with the new baseline. And the productivity “gains” get captured by the organization, not the individual.

This is not a technology problem. This is a management problem. We are letting the efficiency gains of AI tools flow entirely to organizational output rather than worker wellbeing.

The Berkeley Researchers’ Recommendation

The researchers propose companies need an “AI practice” – intentional norms around AI use that include:

• Structured pauses before decisions (don’t just ship because AI made it fast)
• Sequenced work rather than parallel everything
• Protected human connection time (meetings without AI, pair programming between humans)
• Explicit boundaries around when AI-enabled work should and shouldn’t happen

My Question to This Community

How are your organizations handling this? Have you seen the same “workload creep” pattern? Are engineering leaders talking about this, or are we all just celebrating the velocity numbers while our teams quietly burn?

I’m particularly interested in hearing from other VPs and directors who are caught in the middle – you see the burnout in your teams but you’re also getting pressure from above to “leverage AI for productivity gains.”

What’s your framework for protecting your people while still delivering results?

[eng_director_luis]

This study validates exactly what I’ve been trying to articulate to our leadership team for months. As someone managing 40+ engineers at a Fortune 500 financial services company, I’ve seen the “workload creep” phenomenon play out in a particularly insidious way.

What I want to push back on slightly is the framing that this is only a management problem. I think it’s also a cultural problem that engineers are complicit in.

Here’s what I mean: at my company, nobody told our senior engineers to start reviewing code in adjacent teams’ repos just because AI made the code more readable. Nobody mandated that our platform team start building features that were previously on the product team’s roadmap. The engineers themselves expanded their scope because the AI tools made it feel possible and, frankly, because high-performers have a hard time saying “that’s not my job.”

The Berkeley study mentions that “employees worked at a faster pace and extended work into more hours of the day, often without being asked to do so.” That last part is critical. We have a self-selection problem: the most ambitious, most capable people are the ones who adopt AI most aggressively, and they’re also the ones least likely to set boundaries.

What’s worked for us (partially):

1. Explicit “AI-free” blocks on the calendar. Every Tuesday and Thursday afternoon is designated for human-to-human pair programming, design reviews, and architecture discussions. No AI tools allowed. It felt silly at first, but teams report these are now their most productive sessions for complex decisions.

2. Sprint capacity budgets that account for AI overhead. We reduced story point expectations by 15% specifically to account for the cognitive overhead of AI supervision, code review, and debugging. Leadership pushed back initially, but incident rates dropped 22% in the first quarter.

3. “AI Impact” line items in retros. Every sprint retro has a dedicated section where the team discusses how AI affected their workload – both positively and negatively. This makes the invisible labor visible.

But I’ll be honest: we’re still losing the broader war. When quarterly business reviews come around, the board sees “engineering velocity up 40%” and asks why we’re not doing more. The subtlety of “yes but our people are burning out” doesn’t translate well to a PowerPoint slide.

The 62% vs. 38% burnout gap between ICs and C-suite is the most damning number in this study. It proves what many of us have suspected: the people making decisions about AI adoption are not the ones bearing the costs.

[cto_michelle]

I’m going to offer a somewhat contrarian take here. While I deeply respect the Berkeley research methodology, I think we need to be careful about conflating AI-induced burnout with burnout that happens to coincide with AI adoption.

At my company, we’re scaling from 50 to 120 engineers. That’s a period of intense growth, organizational restructuring, and shifting responsibilities regardless of AI. The Berkeley study tracked a 200-person tech company over eight months – that’s almost certainly a company undergoing significant change. Were the role expansions (PMs writing code, researchers doing engineering tasks) really caused by AI, or was AI the tool that made an already-happening organizational shift more visible?

I’ve watched my teams go through three technology transitions in my career: cloud migration, microservices adoption, and now AI tools. Every single one produced an initial period where people took on more scope, felt overwhelmed, and experienced what we’d now call burnout. Then the organization adjusted. New norms emerged. Things stabilized.

My concern with the “AI practice” recommendations is that they might inadvertently slow adoption to the point where companies lose competitive advantage. “Structured pauses before decisions” and “sequenced work rather than parallel everything” sound reasonable in a research paper, but in a market where your competitors are shipping 3x faster, those pauses can be existential.

That said, I am not dismissing the burnout data. The 83% figure from the DHR Global survey is alarming. What I’m suggesting is that the prescription should be more nuanced than “slow down and add human-only time.”

What if the real solution is better AI tooling that reduces the supervision overhead? If senior engineers are spending 40-60 minutes per day validating AI suggestions, that’s a tooling failure, not a management failure. Better confidence scoring, better test generation, better code review automation – these would address the root cause rather than the symptoms.

I realize I might get pushback for this, but I think some of the burnout is a transition cost, not a permanent condition. The question is whether we’re willing to invest in making the transition smoother rather than just slowing it down.

[product_david]

I appreciate the contrarian take, but I have to push back on the “it’s just a transition cost” framing. As someone who works with production ML systems daily, I’ve seen enough data to know that this pattern is structurally different from previous technology transitions.

The key difference between AI and previous transitions (cloud, microservices) is this: cloud and microservices changed what engineers build. AI changes how fast they’re expected to produce. That’s a fundamentally different kind of pressure. You can learn Kubernetes and then the cognitive load stabilizes. But AI-assisted coding creates an ever-accelerating treadmill because the baseline keeps moving up.

Here’s a data point from my team: we tracked PR velocity, review times, and self-reported cognitive load over 6 months. PR submissions increased 45%. But the ratio of “meaningful PRs” (those that survived code review without major revisions) only increased 12%. The remaining 33% increase was essentially noise – AI-generated PRs that required significant human review effort to evaluate. We were generating more output but not proportionally more value. And the cognitive cost of evaluating all that output was enormous.

The suggestion that “better AI tooling” will fix this misses the systemic issue. Better confidence scoring doesn’t solve the problem of a PM who now expects you to handle three projects instead of two because “AI handles the boilerplate.” Better test generation doesn’t stop your manager from expanding your scope because you “seem less busy.”

I keep coming back to the Berkeley researchers’ core insight: the time savings are captured by the organization, not the individual. Until that power dynamic changes, no amount of tooling improvement will prevent burnout. The tools could be perfect and the workload would still expand to consume every freed hour.

What would actually help: engineering leaders who have the courage to say “we’re going to maintain the same output expectations and give the productivity gains back to our people as reduced hours, deeper focus time, or professional development.” I’ve seen exactly zero companies do this.

[alex_dev]

This thread is hitting close to home for me. I’m a senior full-stack engineer, 7 years in, and I’m one of those “AI power users” the Berkeley study describes. I adopted Copilot on day one, moved to Claude Code and Cursor early, and I’m probably in the top 10% of AI usage on my team.

And yes, I’m burning out. But not for the reasons you might think.

The burnout isn’t from the AI tools themselves. The burnout is from the expectations gap that AI created. Before AI, if I said “that feature will take two sprints,” nobody questioned it. Now, if I give the same estimate, I get “but can’t you use AI to speed it up?” Every. Single. Time. The estimation process itself became adversarial.

Here’s the thing that the Berkeley study touches on but doesn’t fully explore: AI changed the perception of what’s reasonable to ask of an individual contributor. My manager now assumes that anything involving boilerplate, testing, or documentation can be done “in the background” by AI while I focus on the hard stuff. In practice, that means I’m now responsible for the hard stuff AND supervising the AI on the easy stuff. My job didn’t get easier; it doubled.

The “work bleeding into personal time” point in the original post is devastatingly accurate. I caught myself at 10:30pm last Tuesday running Claude Code to “quickly” scaffold a test suite because the AI made it feel like a 15-minute task. It took 90 minutes of debugging AI-generated tests that looked correct but had subtle logic errors. And then I was up until midnight. The activation energy for work is now zero, and that’s actually terrible for boundaries.

Where I disagree with some of the solutions proposed: “AI-free blocks” feel paternalistic and miss the point. The problem isn’t the tool; it’s the organizational response to the tool. My company doesn’t need to limit when I use AI. It needs to stop assuming that AI makes my capacity infinite.

What I’d actually want:

• Story point budgets that haven’t changed since pre-AI days
• A PM who understands that “AI can help with X” doesn’t mean “X now takes zero effort”
• Performance reviews that don’t penalize me for shipping at pre-AI velocity while doing higher quality work
• An honest conversation about whether AI is making us better or just making us faster at being exhausted