What looks like productivity acceleration is quietly erasing the recovery time built into every engineering day.
I started noticing it in my engin...
For further actions, you may consider blocking this person and/or reporting abuse
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.