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.
One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.
Top comments (11)
the evaluation load point hits hard. we conflated "reviewing AI output" with "not doing real work" and stripped the buffer from every schedule. but review work is cognitively heavier than writing the thing yourself - you're switching contexts constantly, you can't get into flow, and you're carrying the responsibility for decisions you didn't make. i noticed the same pattern in 1:1s - people sounding fine but just... flatter. took me a while to connect it to the compounding review fatigue.
That is where a lot of teams are misreading the moment. Evaluation got treated like spare capacity, so the pockets that used to let people reset got repacked with more judgment work. Your point about people sounding fine but flatter is the part leaders miss most, because the first thing that degrades is not output volume ... it is decision quality. Have you found any rituals that actually give people cognitive relief instead of just redistributing the load?
The evaluation load point is real. What happens is leaders look at output volume staying flat and miss that the quality of judgment calls is quietly declining. Those are harder to catch until something breaks. Curious if you've seen any rituals that actually help - not just moving the load elsewhere but genuinely creating recovery space.
You are absolutely right that this relentless push is destroying raw engineering talent and creativity. However, if you look at the bigger picture, the market is entirely obsessed with speed right now. It's a corporate arms race to see who can ship faster and dominate the industry.
Take Nokia as a classic example. Historically, no one could beat them in hardware design, craftsmanship, and durability—honestly, they still hold up against modern phones in that regard. But what happened? They were destroyed because competitors prioritized speed. Look at Apple and Samsung today; they are entirely focused on speed and rapid release cycles. The iPhone has arguably kept the exact same core look, software feel, and hardware philosophy for years, yet their biggest selling point every single year is simply: 'we are faster.'
It reminds me of a brilliant quote I read this morning: 'When speed replaces creativity, Design dies at the expense of velocity.' We are trading thoughtful architecture and human talent for sheer output.
That is the trap. The market rewards visible speed first, but teams usually pay for it later in rework, weaker decisions, and architecture that ages badly. The dangerous part is that dashboards will tell leadership the bet is working right up until the judgment quality starts slipping, which is the exact pattern I was trying to name in the piece.
The real leadership job now is separating faster shipping from better decision making. Those are not the same curve anymore.
That 'visible speed' on the dashboards is basically just taking out a massive loan with high interest. The teams are trading long-term architecture for short-term metrics, and eventually, the Technical Debt bankrupts the project.
As you said, separating the illusion of 'shipping fast' from the reality of 'building right' is the ultimate leadership challenge today.
"AI compresses effort so engineers hit cognitive walls earlier." I ran into this earlier this year writing some seriously dense security-heavy code. I generated 11k lines of code in 3 days and my brain was absolutely fried by end of day. I slept 10 hours one of those nights. They were great days - the dopamine hits kept coming because I was making so much progress so quickly - but by the end of my normal 8-hour workday, I was completely exhausted. I told my husband while it was enjoyable, I hope my job doesn't end up like that every day because it would take such a serious toll on my personal life. (Thankfully, it hasn't.)
I build in that recovery time by taking 5-minute walk breaks on a walking pad. It helps me reset my brain and make new connections by entering diffuse thinking mode, and when I come back to the keyboard, I'm feeling fresh again.
That is the part leaders will miss if they only look at output ... 11k lines in 3 days looks like a massive win on paper, but the real constraint becomes sustained judgment. When AI removes the slow parts, you spend more of the day evaluating risk, making tradeoffs, and holding complex context in your head without many natural resets.
Your walking pad example is exactly the kind of operating adjustment teams need to take seriously. Recovery cannot be treated like a personal nice to have when the work itself is getting more cognitively dense. Have you noticed that certain categories of work drain you faster than others ... security heavy work, debugging, or reviewing large AI generated changes?
It would be nice if more companies would focus on whether you got your work done instead of how many hours you worked, but in reality, the reward for finishing your work early is, well, more work. 😆
Doing code reviews for other people when there are 10k lines of code changes is probably the most draining and my least favorite thing to do. That security-heavy code was extremely challenging. I had only started working with Claude Code a few weeks earlier and was extremely paranoid about the code quality after hearing so many horror stories about agentic AI slop, so I was questioning everything. That combined with the security-related nature of the work left me completely on edge all day long. (I didn't mention that it took me twice as long to refactor it into something readable more understandable - also pretty tiring, but not quite as bad.)
The Cost of Zero Friction: When "Optimization" Deletes the Human Buffer
This is a profound observation of a systemic shift that almost everyone is feeling but few are naming. We’ve treated "friction" as a bug to be squashed, but you’ve correctly identified it as a vital biological governor.
The Shift from Creation to Continuous Audit
In a pre-AI world, the "flow" of engineering was a healthy oscillation between high-intensity synthesis and low-intensity execution. There was a rhythmic data flow: you’d exert cognitive energy to design, then "coast" while typing the boilerplate.
Now, that rhythm has flatlined into a high-frequency state of constant evaluation. We aren't "coding" anymore; we are "auditing" at scale. Auditing is computationally more expensive for the human brain than creation because it requires constant vigilance against "hallucinated logic" and subtle architectural drift. You can't let your mind sit in neutral when you're reviewing an agent's output—if you blink, you miss the technical debt.
The "Thermal Throttling" of Talent
From a systems perspective, what you’re describing is cognitive thermal throttling. When a processor runs at 100% capacity without cooling cycles (those four-minute build breaks), it eventually slows down to prevent permanent damage.
In engineers, this doesn't look like a "slowdown" at first; it looks like compliance.
As you noted, when the "why" disappears from planning, it's a sign that the engineer's internal "decision engine" has overheated. They are simply trying to process the queue to survive the day.
The Compression Paradox
Leaders often see AI as a way to "increase bandwidth," but bandwidth and throughput are two different things. You can increase the bandwidth (more code generated), but if the human throughput (the ability to meaningfully judge that code) is fixed, the system will eventually leak quality. We’ve optimized the "typing," but we’ve accidentally doubled the "thinking" tax on every minute of the workday.
A Reflective Takeaway
It makes me wonder: if we’ve automated the "low-stakes" work, do we need to deliberately re-introduce artificial friction? Perhaps "Slow Coding" days or "Manual Mondays"—not to be inefficient, but to allow the cognitive system to re-calibrate and find those "grooves" again.
Your point about sustaining capacity versus maximizing utilization is the bridge most leadership frameworks are missing right now. Velocity is a vanity metric if the engine is melting.
The compliance signal is the dangerous one. Output can still look healthy for a while after judgment starts degrading. Curious whether you’ve seen any teams reintroduce that recovery intentionally without making the workflow worse.