The AI Hangover

You did not do more work. You did a different kind of work, and it costs more per hour.

There is a state I end some days in now that I did not have two years ago.

It arrives after a long session with a coding agent, and usually not a bad one. The opposite: a session where a great deal got built, the kind of afternoon that used to be a fortnight. At the end of it I am not tired the way a long day of programming used to make me tired. I am flattened. Food does not touch it. Coffee does not touch it. A walk does not touch it. The only thing that resolves it is sleep, and not a nap either.

I have started calling it an AI hangover, and once I named it I found that most people doing this kind of work recognise it immediately and had not said it out loud.

To be clear about what this is: an observation, from one person, repeated enough times to be a pattern. I am not making a claim about neurochemistry and I have not measured anything. What I can do is describe it precisely and argue about the cause, because the obvious explanation is wrong and the wrong explanation leads you to manage it badly.

The obvious explanation, and why it fails
The obvious explanation is volume. You produced four times as much, so of course you are wrecked.

It fails on its own terms. The tiredness does not scale with output. I have had sessions that shipped an enormous amount and left me fine, and sessions that produced one stubborn module and left me unable to form sentences at dinner. If volume were the driver those would be the other way round.

It also fails on kind. Ordinary programming fatigue is a depletion. You feel like you have been running and you slow down gradually, and you can usually feel it coming an hour out. This is not that. This has a distinct quality of overload rather than depletion, it arrives late and abruptly, and the thing that is exhausted is specifically judgment. I can still lift things. I can still hold a conversation. What I cannot do is decide anything.

That last detail is the tell, and it points at the actual cause.

You changed jobs without noticing
Here is what actually changed when you started working this way.

You stopped being an author and became a reviewer.

That sounds like a smaller change than it is, because both activities are called programming and happen at the same desk. They are not the same work, and they do not cost the same.

When you write code yourself, most of the minutes are production. You are typing, and typing is slow, and while your hands are moving your mind is running ahead assembling the next piece. Decisions are real but they are punctuation. They sit between long stretches of execution, and those stretches are where you recover.

When you drive an agent, the production minutes are gone. The agent has them. What is left for you is the part that was always the expensive part: read this, understand what it does, decide whether it is right, decide whether it is right for this codebase, decide whether the thing it did instead of what you asked is better than what you asked, and decide all of that fast enough that you are not the bottleneck.

Every single output is a judgment call, and there is nothing in between them.

You did not take on more work. You took on a stream of work that is nothing but the costly part, with the cheap part removed, and then you did it for six hours because it was going well.

Why reviewing costs more than writing
Two reasons, and both get worse the better the agent gets.

You have to build a model of code you did not write. When you write a function, the mental model arrives for free as a byproduct: you cannot type it without understanding it. When you read a function, the model has to be constructed deliberately, and construction is work. Any developer who has reviewed a large pull request knows that forty minutes of review is worse than forty minutes of writing, and nobody finds that surprising. What is new is doing it all day, at speed, as the entire job.

You cannot fully trust the output, so you never stop watching. Not because agents are bad, but because they are good enough that errors are plausible rather than obvious. A broken thing announces itself. A subtly wrong thing does not, and the only defence is sustained attention. Sustained attention at a constant level, with no natural breaks, is a well-known way to wear a person out, and it is the state you are in from the first prompt to the last.