You're operating heavy machinery: burnout risk in AI-augmented engineering teams
The AI productivity story usually goes like this: engineers can now be 10x more productive. If they're not, we're falling behind.
That might be true, but so is this: the nature of engineering work has been fundamentally upended in the space of a few months. The cognitive profile of the job has changed radically, the operations playbook hasn't caught up, and that gap is accelerating burnout risk.
The work changed faster than the leadership playbook did
A year ago, a senior engineer spent a significant portion of their day writing code. The work had a rhythm: periods of deep focus, clear outputs, tangible and hopefully steady progress. It was demanding, but the demands were well understood and fairly predictable.
It was also sometimes boring. Executing a decision through line by line of code meant repetitive work. Not all of it was interesting. It's easy to miss that the boring parts were also doing something useful: they were breaking up the intensity. It might not have been recovery time exactly, but it was very often lower-demand work.
AI-augmented engineering has largely eliminated those boring parts. On the whole, that's great. Nobody wants hours of repetitive typing. But it does mean the workday is more likely to remain intense from start to finish. More context switching, more decisions per hour, greater QA load as output volume rises, and a continuous stream of judgment calls as engineers direct the AI rather than write the code themselves. The recovery that used to happen inside the work has to come from somewhere else now, and most engineers have never had to think about that.
What "operating heavy machinery" means now
Engineering teams have always worked in high-stakes environments, but those stakes have now shifted. When AI accelerates output, problems propagate faster too.
This is what we mean by operating heavy machinery: the work isn't immediately, physically dangerous, but it does carries the potential for greater downstream impact. That means it requires a higher standard of judgment, sustained over more decisions each day. It's a standard that's hard to maintain on an empty tank.
Burnout in this context is insidious, subtly eroding judgment. It's harder to spot and faster to compound. By the time it's visible, the damage is often already done.
Why burnout looks different when everyone is augmented
Standard burnout signals like declining output, missed deadlines, or visible disengagement are partly masked when AI is filling the gaps. An engineer running on empty can still ship.
What they're likely to lose first is the judgments AI tools are still terrible at: the calls about what to build, what to skip, where the model has misread complex context, when to push back on a proposed direction. Those are critical calls in an AI-augmented team, and they're the hardest for a leader to see from the outside, until something obvious goes wrong.
This is where early signals and the right framework for organising them are critical. The Fuel-Gauge-Terrain framework is TANK's evidence-based model for burnout prevention: Fuel is the balance between stress and recovery; Gauge is your ability to read your own signals accurately; Terrain is the system environment that makes balance easier or harder.
In AI-augmented teams, many engineers won't see fuel problems coming. They've managed high-intensity work before, but always with low-intensity work built in as a natural counterweight. That counterweight is gone. To replenish fuel during the day, recovery now has to be deliberate, and many engineers are encountering that requirement for the first time.
Gauge issues tend to compound that problem. The same drive that makes someone good at this work makes early depletion signals easy to dismiss. And if the team is spending more time with machines and less with each other, the social signals that help people notice when a colleague is struggling get weaker too. The early warning system is weaker, precisely when it's needed most.
The terrain problem: what leaders can actually shift
Individual resilience matters, but it's not the main lever.
Terrain is where leaders have the most scope to act. In AI-augmented teams, the terrain questions are more specific than the usual list of meeting culture, load management and role clarity. Here are four we're seeing come up frequently:
Priorities, specifically stating what you've decided not to do. AI acceleration means the backlog grows faster too. Without an active deprioritisation practice, the pressure to do everything intensifies even as output rises. A regular, explicit review of what the team has decided not to work on is necessary, proactive load management.
Switching off outside work hours. When agents can work overnight and outputs produced for review at any time, the temptation to stay connected is constant. Leaders who actively support disconnection, not just permit it, are making a terrain choice that directly affects their team's recovery capacity.
Development, not just delivery. There's a meaningful difference between directing an AI to produce output and developing as an engineer. The former can become a treadmill; the latter requires space for work that stretches and builds capability. A regular check on whether people are growing or just babysitting output is worth building into the rhythm of the team.
Team connection by design. Senior engineers once spent significant time coaching and pairing with junior colleagues. That contact has shifted toward machines, away from people. Junior engineers lose informal mentorship. Senior engineers lose a source of meaning and connection that came with the coaching role. Both affect fuel by reducing the recovery time that comes with human connection. The informal signals that a colleague may be struggling get harder to read. Team connection may not happen as automatically in this environment; if not, it needs to be designed in.
What we're building — and where to hear about it first
TANK for Teams is the team layer we've been working toward: a burnout risk assessment that gives leads an aggregated view of their team's energy, recovery, and work environment, and a facilitated team retro that ends with one commitment the team itself can act on. Actionable team data, while protecting individual privacy.
We're building tools that sit directly in the developer's environment, providing just-in-time prompting around session goal-setting, progress tracking, and recovery cues. It meets engineers where they actually work.
Navin is presenting this work, including a live demo, at slashNEW (27–28 May) and on the Leadership track at AI Engineer (3–4 June). Both talks are built around how engineers can shift burnout-producing conditions toward ones that produce genuine flourishing, and what leaders can do to shape the terrain that makes that easier.
If you can't make either event, you can still register interest in the beta here. We'll be in touch when we're ready.