What looks like productivity acceleration is quietly erasing the recovery time built into every engineering day.
I started noticing it in my engineers first. In one-on-ones. In how the same conversations sounded different toward the end of a sprint. I heard it enough times across enough people that I started looking for it deliberately. Then I noticed it in myself. I'm not coding more than half my hours. My work is reviewing, deciding, evaluating ... across systems, teams, timelines. And I was still running out of steam by Wednesday. We went from running a marathon to sprinting a marathon. Same course. Same distance. But you can't sprint a marathon and finish the same.
Recovery Time Was Hidden in the Friction
Before AI, engineering had something built into it that nobody named. Recovery time.
Not blocked time. Not wasted time. Recovery time.
The build step that took four minutes. You'd flip to a browser tab, refill your coffee, let your brain sit in neutral for a moment. Not thinking about architecture. Not evaluating anything. Just waiting.
Writing boilerplate by hand was tedious. But tedious was the point. Low stakes. Low cognitive demand. Your hands typed while your mind coasted. There was no decision in it. Just the satisfying click of producing something familiar.
Refactoring a module you knew felt almost meditative. You knew the code. You knew what needed to move. The work had grooves. Your attention could settle into something easy while the harder thinking finished processing in the background.
None of this felt like rest. Even to the engineers themselves.
But it was rest. The throttle built into every engineering day.
Those pockets of low demand weren't friction to optimize away. They were the throttle that kept a sustainable pace sustainable.
What AI Actually Replaced
AI didn't just speed up those tasks. It replaced them. Not with the same tasks done faster ... with entirely different tasks.
The build runs in 45 seconds now. Those four minutes are gone. And they've been replaced with four minutes of reviewing what the model generated.
The boilerplate writes itself. The time you saved is filled with evaluating whether it fits your architecture, follows your conventions, doesn't introduce patterns that will calcify into problems eighteen months from now.
Every minute that used to be low stakes is now high stakes. Does this output pass the test. Does it pass the test and make sense. Does it make sense and not create downstream debt.
Every minute is an evaluation.
There's no coasting anymore. There's no meditative refactoring. There's no four minute reset. There's a stream of decisions, each one flowing directly into the next with no gap in between.
Engineers spent years training one cognitive muscle. The traditional approach to programming built a specific rhythm into the work ... heavy judgment, then recovery. Heavy judgment, then recovery. The boring tasks were the low-intensity reps between hard sets.
Then came the mandate. Overnight, it demanded a completely different muscle. The training cycle that built the first one had no equivalent for the second. The new game started at full intensity immediately.
The Mental Model Most Leaders Are Running
If you lead engineers, you're carrying this belief ... AI saves time, so engineers should have more capacity.
It's a reasonable belief. It just doesn't map to what's happening.
AI compresses effort so engineers hit cognitive walls earlier.
Compression is different from reduction. If a sprint used to contain forty hours of varied cognitive demand, AI compresses the low demand portions to nothing. The engineer doesn't end up doing less. They end up doing all of it, in less time, with no recovery built in.
The output looks the same for a while. Maybe it looks better. The metrics move. The velocity numbers read well. I've written about what those numbers actually measure and what happens when leaders mistake them for health. The pattern is consistent ... things look fine until they suddenly don't.
AI compresses effort so engineers hit cognitive walls earlier.
What It Looks Like in Practice
Cognitive overload doesn't announce itself. It doesn't look like someone staring at a blank screen. It looks like things getting approved that shouldn't. Pull requests that should have been flagged, that weren't. Architectural shortcuts that nobody questioned in review, even though three people in that room would have caught the same thing six months ago.
The quality of decisions drops before the quantity of output drops.
By the time the output is visibly degraded, the problem has been compounding for weeks.
One signal worth watching ... when your best engineers stop asking why in planning. When the people who used to push back on the framing of a problem start accepting the framing and jumping straight to solution. That's not a focus improvement. That's cognitive depletion showing up as compliance.
The engineers who are best at their jobs are also the most likely to push through the wall without telling anyone. Not because they're hiding it. Because their mental model for feeling off is "I need to work harder to get back on top of things." They're trying to solve their way out of the problem that is the problem.
The Question Worth Asking
Look at your team's calendar for tomorrow. Not the meetings ... look at the time engineers spend building.
Ask one question about that time. Where are the moments when nobody is asking them to evaluate anything?
Where is the work that doesn't require judgment to complete? Where is something low stakes, familiar, with grooves?
If you can find it ... protect it. Don't fill it with more AI generated output to review. Don't schedule a ceremony into it. Let it be what it is.
If you can't find it ... you're not looking at a capacity problem. You're looking at a depletion problem. And it will surface on your team before it surfaces in your metrics.
What This Actually Requires
This isn't an argument against AI tooling. The tooling is useful.
Nobody is built for sustained high stakes evaluation all day. There is a ceiling, and it isn't a software limitation. What AI changes is how fast you reach it.
Remove the throttle without acknowledging what the throttle was doing ... and the pace becomes the problem.
Give engineers work that costs less to evaluate. Protect the moments when judgment isn't required. Design the pause into the day now that the workflow stopped doing it automatically.
Some of that is task design. Some of it is how you structure rituals and reviews. Some of it is recognizing that when an engineer asks for a day to work on something slower, they are not being resistant to change. They are self-regulating. Let them.
Your job as a leader is not to maximize the utilization of your engineers' cognitive capacity. It's to sustain it.
Your job as a leader is not to maximize the utilization of your engineers' cognitive capacity. It's to sustain it. If you can't find the recovery time in your team's day, you're not running a productive engineering org. You're running a depletion schedule.