The rhythm problem

Your team is shipping faster than ever. Some of them are also more tired than they can explain. Both are true, and your dashboards only show one of them.

A developer with twenty years behind him told me something a few weeks ago that I have not been able to put down.

He said his old burnout made sense. Write code for eight hours, brain fried, go home. Predictable. You knew where it came from and you knew it would pass.

His new burnout is harder to describe. Ask the AI to do something. Read what it produced. Decide if it makes sense. Notice it quietly broke something three files away. Ask again. Review again. Catch it before it drifts. Repeat.

On paper that sounds easier than writing the code himself. It is not. He is more wrung out at the end of those days than he ever was writing everything by hand, and he could not explain why to his manager without sounding like he was complaining about a tool that is supposed to be making his life easier.

I have heard a version of this from enough people now that I have stopped treating it as a personal quirk. It is a pattern. And if you lead a technical team, it is happening on yours right now, whether or not anyone has the language for it yet.

Here is what is actually going on.

Writing code, for all its frustration, has a rhythm to it. You hold a problem in your head, you build, and you get into a state where the work and the thinking are the same motion. Flow. It is tiring, but it is the good kind of tiring.

Reviewing and redirecting AI is a completely different motion. You are not building. You are supervising. You read something you did not write, hold it against a mental model of what you actually wanted, find the gaps, and steer. Then you do it again. And again. It is the cognitive shape of managing a very fast junior developer who never sleeps, never pushes back, and never learns from the last correction.

Anyone who has managed people knows that kind of work drains you in a way that does not look like effort. The cost is not the labor. It is the vigilance. It is the constant small context switches between reviewing, correcting, and redirecting something that produces confident output at a speed you cannot match and cannot fully trust.

There is no flow in that. There is only attention, spent in a thousand tiny pieces.

Now the part that matters if you are the one making the staffing and roadmap calls.

This drain is invisible on every dashboard you have. Velocity is up. Tickets close faster. The demo looks incredible. By every number you track, the team got faster, so you plan as if they did. More scope. Tighter timelines. The same headcount carrying more, because the tool made everyone twice as fast.

But you are not measuring the cost, because the cost does not show up as slower output. It shows up as people who are quietly more depleted than the throughput suggests. It shows up months later as the senior engineer who used to love the work and now sounds flat. It shows up as quality drift nobody can quite trace, because the person who approved the pull request was reviewing their ninth AI-generated change of the day and did not have a tenth careful read left in them.

Speed went up. So did a kind of overhead none of your tools are built to see. If you only price the speed, you will overcommit the team and never understand why morale and quality both slipped while the graphs stayed green.

I do not think the answer is to use less AI. The leverage is real and it is not going back in the box. The answer is to be deliberate about the rhythm instead of letting the tool set it.

A few things that seem to help, from the people who have found their footing.

Batch the AI work. Reviewing and redirecting is a mode, so treat it like one. Block it into focused windows instead of letting it interrupt every fifteen minutes, because the context switching is most of the cost.

For anything close to the core, write it yourself. The mental overhead of babysitting AI through a complex, critical decision often costs more than the time it saves, and you come out the other side actually understanding what you shipped. Spend the AI on the surface area, not the spine.

And as a leader, stop pricing your team as if everyone got faster for free. Build the review-and-redirect overhead into your estimates the same way you would build in the cost of onboarding three junior developers at once. Because functionally, that is what you did.

The tools are not the problem. A year in, I am convinced the rhythm is. We picked up an enormously powerful way to produce work, bolted it onto a workday designed for a completely different kind of effort, and then acted surprised that people are tired in a way they cannot name.

The teams that pull ahead will not be the ones using AI the most aggressively. They will be the ones who notice what it is quietly costing and design around it on purpose.

So a real question, and I would like to hear the answer. On your team, have you felt this shift yet, and are you managing the rhythm, or is the tool managing you?

Reply and tell me. I read every one.