Skip to main content

Playing a Chess Simul: Are AI Agents Exhausting Our Best People?

We were promised that AI would be the "Easy Button" for engineering. Instead, I’m seeing something else: my highest-performing leads and managers are reporting a level of fatigue that feels different from standard burnout. They aren’t just tired; they’re depleted.

I recently heard a brilliant analogy for this: Using AI agents is like a Grandmaster playing 20 games of chess simultaneously. On paper, the Grandmaster is "20x more productive". But look closer at the board. They aren't just playing; they are context-switching at a terminal velocity.



The "Reviewer's Tax"

When an engineer writes code, they are in "Flow State." They build the mental model, piece by piece. It’s hard work, but it’s linear. When that same engineer uses three different AI agents to generate a PR, they shift from Creator to Auditor. They are no longer building the house; they are the site inspector walking through a house built in five minutes by a hyperactive robot.

They have to:

  • Verify the logic (is this actually solving the problem or just looking like it?)

  • Check for hallucinations (did the agent just invent a library?)

  • Ensure architectural alignment (does this "perfect" code actually fit our legacy mess?)

The Grandmaster Problem

In a simultaneous exhibition, the Grandmaster isn't just making moves. They are maintaining 20 different mental maps.

For the modern Engineering Manager or Lead, the "agents" are both their opponents and partners. You’re prompting dev agent on one screen, a planning agent on another, and reviewing a generated test suite on the third. Engineers are working multiple taxing problems at once, context switching, and then also being overloaded with pull request reviews from their peers who are doing the same thing. 

The cognitive load isn't reduced; it’s compressed. You’re doing the deep thinking for five different workstreams in the time it used to take to do one. While this can be a productivity gain I fear there is a cognitive debt that will eventually be paid back in the form of burnout.

What This Means for the Org

As leaders we need to be aware, and look out or measure the fatigue of our engineers and managers. As we ride this wave, we have to be making sure our most valuable assets - the people with the judgement and experience to know when the AI is wrong - are able to catch the next wave too. I worry as my team's pace of onboarding to use AI tools increases, we might see our top talent accelerate towards burnout and not catch it in time to stop it.

Are you seeing your team burning out? Anything you have learned that would help me avoid this?
Labels:

Comments

Post a Comment

Popular posts from this blog

The "Just-in-Time" Manager and the 1:1 Gemini Gem

  We’ve all been there. The calendar notification pings. You finish your previous meeting (which ran over by three minutes), and as the Zoom window for your next 1:1 pops up, you’re frantically tabbing through Google Docs and Slack. You’re trying to remember: What did we talk about last time? Did that project go okay? Wait, did they mention a vacation or a baby? You’re "prepping" while the meeting is already happening. You’re physically present, but mentally, you’re a detective trying to solve the mystery of your own calendar and trying to switch off the last meeting.  It’s a common trap for managers, especially as their direct reports grow and they now have skip level 1-1s, or skip-skip level 1-1s. Our schedules are a mosaic of context-switching, and unfortunately, the deep, reflective prep our direct reports deserve is often the first thing to get squeezed out as we are dealing with incidents or other emergencies.  From "Zero Prep" to "Instant Context" R...
Post a Comment
Read more

Prompting AI Adoption for Skeptical Engineers

We’ve all seen the headlines. "AI will replace the junior engineer”.  "The 10x engineer is now a 100x engineer." In leadership meetings almost every conversation comes back to velocity and how we could unlock efficiency with AI.  But when you talk with the team the reality can be different. Your most senior engineers - the ones who built the core of your system - are looking at Copilot or Cursor with a squint. Some see it as a toy; others see it as a threat to the craft; a few see it as a glorified Clippy that hallucinates half-baked solutions into their carefully maintained repos. As Engineering Managers and Directors, we are currently in a delicate spot. We are being asked by the business to "leverage AI," but we are being told by some of our best people that it’s "not quite there yet". How do we advocate for AI without sounding like a marketing brochure? How do we move the skeptics without losing their trust? 1. Validate the Skepticism (Because it...
Post a Comment
Read more

The New Unit of Planning: Headcount vs Tokens

  As I work through another planning cycle, the ritual remains the same: the spreadsheet opens, the roadmap is prioritized, and we start the negotiation for more "heads." In my world, and likely yours, the engineer has always been the fundamental unit of progress. If we want to move faster, we hire more of them. But this year, the math feels... off. I’m asking myself - do I really need a new hire for this or do I just need a larger token budget? We are moving away from a world of Fixed Labor and into a world of Variable Compute. When you hire a Senior Engineer, you’re buying a long-term asset. You’re also buying a 6-month onboarding lag, a management overhead, and a permanent line item on the P&L.  When you "hire" tokens you’re buying instant, fractional capacity. If your engineers are telling you they can automate 30% of the "toil" using a custom-tuned model, the traditional argument for that extra engineer disappears. We are moving from mere manageme...
Post a Comment
Read more