AI coding tools were supposed to mean developers work less. On a recent webinar recorded with LeadDev, senior engineering manager Vernon put words to something a lot of teams are quietly noticing instead: 

“It’s concerning because it’s the opposite of what was promised. We were supposed to be working less.”

The dopamine loop nobody put in the pitch deck

GitKraken’s VP of Engineering, Stasia Zamyshlyaeva, described who tends to hit this hardest on the panel: “usually this is true product engineers who know what customers need and they build. They get into this dopamine kind of excitement when they can’t stop working, because they’re doing something and they see the outcome right away, and they want to do more, and they want to do more.”

That’s not a discipline problem. It’s the tooling working exactly as designed, fast feedback, visible results, more capability than ever to act on an idea the moment it occurs to you. The loop that makes agentic coding feel great is the same loop that makes it hard to stop.

Why context switching got harder, not easier

Vernon connected this to something less talked about than raw output: cognitive load. “You’re doing much more in switching context much faster than before, because now you have a team of agents, and then looking into the outcome of each of them, editing, following up on all that, reviewing the code, and a lot of PRs to review every day.”

Does AI reduce a developer’s workload or just change it?

Based on what the panel described, it changes it more than it reduces it. Typing code by hand goes down. Reviewing, redirecting, and stitching together output from several agents running in parallel goes up, and that kind of task-switching carries its own fatigue, even when the total line count shipped looks like a productivity win on paper.

The signals worth watching before it becomes a resignation

Vernon pointed to concrete, observable signals leadership can watch for: commits landing at unusual hours, pull requests submitted late at night, usage that spikes and stays high for hours without a break. None of these prove burnout on their own. Treated as a leading indicator, the way you’d treat an early signal for velocity or quality, they’re worth a look.

That’s a meaningfully different use of the same data a security or productivity dashboard might already show you. The goal isn’t to flag an individual for working late. It’s to notice a pattern across a team early enough to do something about it before it shows up as a resignation letter.

Why the standard employee survey won’t catch it

Jennifer, a freelance journalist who covers developer experience, raised the harder problem underneath the data: “you can’t measure this if you don’t have psychological safety. We are not in a psychologically safe time right now. People do not feel secure about their jobs, so you are not going to get the right response for a leading or lagging indicator of burnout in a human survey if you’ve not made it safe.”

A quarterly survey that isn’t genuinely anonymous, or that lands in a climate where people are worried about job security, won’t tell you the truth. It’ll tell you what people think is safe to say.

What leaders can actually do about it

The panel didn’t leave this as an unsolvable problem. A few things came up as concrete, doable steps.

Build in the discipline yourself. Vernon was direct that this has to be structural, not aspirational: “we are going to have to start building in a level of discipline around making sure that we take breaks and getting away from our machines.” Off-hours need to be a norm the team sets, not an individual willpower exercise.

Talk to people directly, not just about them. Zamyshlyaeva described the actual conversation worth having with someone deep in that loop: “you will be delivering so much more if you’re in a good mental state, so let’s be in this together.”

Keep wellbeing metrics at the team level, never the individual. Jennifer’s closing point on this was blunt: “not to measure at the individual level, because it’s not about the staff at that point. You’re doing something wrong as a manager, too. That could go sideways pretty quickly.” Aggregate signals inform how a team is managed. They aren’t a tool for watching one person.

Sustainable output is the only kind that actually shows up as ROI

This connects to a harder question leadership is already asking: what’s the real return on AI investment. We covered the framework for answering that in An 80% AI Adoption Rate Is Like an 80% Gym Membership Rate. A team producing a short-term spike followed by burnout and attrition doesn’t clear that bar, no matter how good the velocity chart looks in the quarter it happened.

FAQ

Can AI coding agents increase developer burnout? Yes, according to engineering leaders on a recent GitKraken and LeadDev panel. The fast feedback loop of agentic coding, seeing results immediately and wanting to keep going, can drive developers to work longer hours than before, the opposite of AI’s promise to reduce workload.

What are early warning signs of AI-related developer burnout? Commits or pull requests landing at unusual hours, and AI tool usage that spikes and stays elevated for extended periods without a break, were both cited as leading indicators worth watching at a team level.

Should companies track individual developer activity to prevent burnout? Engineering leaders on the panel advised against it. Wellbeing signals should be tracked in aggregate, at the team or organization level, not tied to individual developers, since a concerning pattern usually points to a management or workload problem rather than an individual one.

Why don’t standard employee engagement surveys catch AI-related burnout? Surveys only produce honest answers when respondents feel psychologically safe. In a period where job security concerns are widespread, developers may not answer candidly unless a survey is genuinely anonymous and trust in that anonymity has been established.