Why Dev Teams Burn Out in the AI Era
8 min read Deutsch
Developers are shipping more code than ever.
They are also more anxious, more tired, and more unsure about the value of their own craft than at any point I have seen in engineering teams.
AI did not create all of this.
It exposed what weak leadership had been hiding.
A team with unclear priorities, bad estimation, shallow management, and no room for recovery will not become healthy because everyone gets Cursor. It will become faster for a while. Then it will crack faster.
Here is what I see in dev teams right now, and what technical leadership has to do about it.
AI did not remove pressure. It changed the shape of it.
Most leadership teams talk about AI as if it only changes output.
More code. Faster tickets. Shorter delivery cycles. Fewer blockers. Better margins.
That is the spreadsheet version.
The human version is different. AI added three kinds of pressure to the developer’s day, and most companies pretend they do not exist.
1. Identity pressure
Developers spent years building a craft.
They learned languages, patterns, frameworks, debugging, architecture, testing, naming, refactoring, tradeoffs. They built taste, judgment, and confidence from solving hard problems with their own hands.
Now a model writes a large chunk of the code.
Not all of it. Not the hard parts. Not the judgment.
But enough to make people ask uncomfortable questions.
What is my skill worth now? Am I still good, or just slower than the tool? Did I spend ten years getting good at something that is being repriced in public?
Most developers will not say it exactly like that. They will joke about becoming obsolete, get annoyed at AI demos, or quietly stop mentoring juniors because they are no longer sure what advice still holds.
That is identity pressure.
And it is real.
2. Output pressure
Leadership saw the demos.
A prompt goes in. Code comes out. The backlog is supposed to melt.
Then expectations shift.
Sprint capacity goes up. Estimates get challenged harder. “Why is this still not done?” appears more often. A feature that used to be two weeks is now expected in one because “AI should help with that.”
This is where teams start to burn.
AI can speed up boilerplate, tests, migrations, first-pass implementations, documentation, code search, and refactoring suggestions.
But leadership often jumps from “AI speeds up some tasks” to “AI speeds up the whole team.”
That is not how software delivery works.
The bottleneck is often understanding the problem, making the right tradeoff, coordinating with product, reviewing edge cases, integrating with old systems, handling unclear ownership, and not breaking production.
AI helps with some of that.
It does not remove it.
3. Verification pressure
This is the one almost nobody talks about.
AI writes plausible code.
Plausible is not the same as correct.
The developer now has to read, verify, test, adjust, and often reverse-engineer code they did not write. In many cases, that is harder than writing the code from scratch.
Writing code is active.
Reviewing AI code is suspicious reading.
You are constantly asking: is this right, is this almost right, is this hiding a bad assumption, is this using an API that does not exist anymore, did it miss the business rule, did it pass the test for the wrong reason?
That work is cognitively expensive.
And in many teams, it is invisible. Planning still treats AI-assisted work as “faster implementation.” Standups still celebrate finished tickets. Leadership still asks for velocity.
Nobody updates the productivity model to include verification.
So the developer feels slower while producing more.
That is a nasty combination.
Burnout is not caused by hard work alone
People can work hard for a long time when three things are intact: autonomy, mastery, and meaning.
AI pressure attacks all three.
Autonomy drops when tool adoption becomes a mandate. Mastery drops when the work feels like babysitting machine output. Meaning drops when leadership talks about developers as throughput multipliers instead of people with judgment.
That is how you get burnout.
Not from one busy sprint. From the repeated feeling that the work is getting faster, noisier, less trusted, and less yours.
My psychology background made me pay attention to this. People do not behave well in systems where they feel pushed, reduced, or stripped of agency. Motivation is not a nice extra. It is part of the operating system.
What bad leadership does
Bad leadership treats AI adoption as a productivity rollout.
The moves are predictable:
- mandate AI tools across the team
- measure output in PR count, tickets, or lines of code
- call skepticism “resistance to change”
- compare teams against public benchmarks
- reward speed before correctness
- ignore the review burden
- expect juniors to learn from tools instead of people
Each of these makes the problem worse.
A mandate turns adoption into a loyalty test. Bad metrics reward volume over judgment. Benchmarks create theater.
The junior problem is especially dangerous. If juniors learn primarily from AI output, they may ship faster for a while without building the mental models that make senior engineers valuable later.
That is not enablement.
That is debt.
What good leadership does instead
There is no magic framework here.
But the healthy teams I have seen do a few things differently.
1. They redefine productivity
The metric is not how much code was produced.
The metric is how much correct, reviewed, maintainable code reached production and stayed there.
AI makes output cheap. When output becomes cheap, judgment becomes more valuable. The leader’s job is to make that explicit.
A good productivity conversation asks:
Did the feature solve the user problem? Did we understand the tradeoffs? Did we review the risky parts? Did we remove complexity or add it? Will the next engineer understand this in six months?
That is productivity.
Not token-generated volume.
2. They give engineers control over tooling
Forcing developers to use AI tools is a good way to get fake adoption.
They will use the tool just enough to look compliant. They will not build real habits around it, teach each other what works, or trust leadership.
Give teams a clear expectation instead:
We expect you to learn where AI helps your work and where it makes it worse. We expect you to share patterns. We expect you to be honest about failure modes. We do not expect blind usage.
That changes the atmosphere.
Developers are not children. Treat them like professionals and you get professional judgment back.
3. They make verification visible
Reviewing AI output is work.
Testing AI-generated code is work.
Throwing away a bad AI suggestion is work.
Discussing whether a generated abstraction should exist is work.
If this work stays invisible, your planning is fiction.
Make it visible in standups, estimation, and retros. A ticket assisted by AI may have less typing and more review. Otherwise the team carries the extra cognitive load while leadership celebrates fake efficiency.
4. They protect the craft
This is where most companies will get it wrong.
They will think the future developer is just a prompt operator.
That is nonsense.
The future developer needs more judgment, not less. More architectural taste. More product understanding. More debugging ability. More security awareness. More ability to read code and detect subtle wrongness.
So leaders need to protect the parts of engineering where those skills are built.
Pair programming still matters. Code reviews still matter. Design discussions still matter. Postmortems still matter. Letting juniors struggle productively still matters.
If AI removes every struggle, it also removes a lot of learning.
The goal is not to make developers dependent on the tool.
The goal is to make good developers stronger.
5. They talk about identity in one-on-ones
This is uncomfortable for many engineering managers.
Too bad.
In the AI era, “How do you feel about the work?” is not a soft question. It is a retention question.
You need to know who feels threatened. Who feels excited but overloaded. Who is quietly ashamed that the tool helps them. Who refuses to use it because it makes them feel less competent. Who is using it too much and losing confidence in their own judgment.
These are not therapy sessions.
They are leadership conversations.
A good manager does not need to solve someone’s entire relationship with work. But they do need to notice when a strong engineer starts detaching from the craft.
Because that is usually where resignation starts.
Why this is a CTO problem, not an HR problem
HR cannot fix this.
Not because HR is useless. Because this is not mainly a benefits problem, a workshop problem, or an internal communications problem.
It is a technical leadership problem.
The person fixing it needs to understand what AI can actually do. They need to know what good code looks like. They need to know when a vendor metric is bullshit. They need to know why a team is slower after adding a tool that was supposed to make them faster.
And they need enough psychological understanding to see the human cost before it turns into churn.
That overlap is rare.
Most companies have technical leaders who understand systems but avoid people. Or people leaders who understand motivation but cannot challenge a bad engineering narrative.
In the AI era, that split becomes expensive.
The real risk is not that developers become obsolete
Some tasks will disappear. Some roles will change. Some people will refuse to adapt and get left behind.
That part is real.
But the bigger near-term risk is that companies burn out their best engineers by pretending AI made software simple.
It did not.
It made some parts faster. It made some parts weirder. It made verification more important. It made judgment more valuable. It made leadership harder.
If your dev team is faster on paper and quietly cracking underneath, that is a solvable problem.
But it will not be solved by another productivity tool.
It will be solved by leadership that understands both the code and the humans writing it.