tempo / notes / ai coding fatigue

the problem

AI coding fatigue: why hour six with Claude feels different

A long session with an agent does not tire you the way a long session alone at a keyboard does. The work is lighter and the day is heavier. The reason is structural, and once you can see it, you can do something about it.

The complaint is now common enough to be boring. Someone finishes a nine-hour day of building with Claude, having shipped more than they would have shipped in two days on their own, and feels wrecked in a way that does not match the output. Not the satisfying tiredness of hard thinking. Something flatter: irritable, foggy, unable to decide what to eat, re-reading the same diff four times without it going in.

The instinct is to treat this as a discipline problem — you should have stopped, you know better. It is more useful to treat it as a design problem. Agentic coding quietly removed three things that used to regulate a working day, and nothing has replaced them.

1. The waiting is gone

Programming used to be full of enforced pauses. Compiles. Test suites. Deploys. Waiting on a colleague to answer. Reading documentation you had not read yet. None of these were designed as rest, but they functioned as rest: thirty to ninety seconds where your hands stopped and your gaze left the screen and your breathing went back to something normal. A day had dozens of them.

An agent fills that space. The model is working, so you are reviewing. The review finishes, so you are already writing the next instruction. The gaps did not get shorter — they got occupied. You can now go four hours without a single moment where nothing is demanded of you, which is a thing that was previously quite hard to arrange.

2. The work shifted from producing to judging

Writing code yourself is mostly generative: you hold a plan, you type, you get into a groove. Working with an agent is mostly evaluative. Is this right? Is this what I asked for? Did it quietly change the thing I did not want changed? Should I accept this, or re-prompt? Is that test passing for the right reason?

Judgement is the expensive mode. Every diff is a decision, and an agent can hand you a decision every ninety seconds for as long as you are willing to keep receiving them. Volume is the whole point of the tool — and it is also why a productive day can leave you emptier than an unproductive one.

The tell: at hour two you read the whole diff. At hour six you skim it and look at the test result. Nothing about the diff changed. Your budget for judging did.

3. Stopping points stopped arriving

Work used to end itself. You finished the feature, or you hit a wall you could not get past without someone else, or it got late enough that the next step needed a fresh head. Agents dissolve walls. There is always one more thing that could plausibly work, and it costs you a sentence to try it. The session does not reach a natural end — it reaches whenever you happen to look up.

This is the mechanism behind the retry spiral, which deserves its own treatment: how to notice you are in one while you are in one.

Dose and friction are not the same signal

Most tooling that thinks about developer strain looks for trouble — errors, failures, things going wrong. That catches the bad afternoon and misses the expensive one. Two different things cost you, and they behave differently:

FamilyWhat it meansHow it behaves
Friction Something is going wrong. Retries clustering on one target, error rates above your own normal, prompts collapsing from sentences into fragments, urgency and swearing, subagents churning. Spikes and fades. Loud. Easy to attribute after the fact.
Dose Nothing is going wrong. You have simply been at it a long time: hours actually inside the tool, minutes since a real break, how fast you are prompting against your own baseline, how many separate codebases you are holding at once, how many days since a lighter one. Accumulates. Silent. Feels like nothing until it doesn't.

An eight-hour day, most of it unbroken, does not need to have gone badly to have cost you something. This is the part that gets missed: people wait for a bad day to justify stopping, and a smooth day of very high volume never supplies the justification.

Why you are the last to know

The awkward part of depletion is that the faculty you would use to detect it is the faculty that goes first. Judgement degrades, and judging your own state is judgement. By the time the signal is strong enough to notice unaided, you have usually been in it for an hour or more — which is exactly the interval where you make the decisions you unpick the following morning.

Which is why the useful version of this is not a feeling. It is a measurement, taken by something that is not also tired.

What actually helps at hour six

  1. Break at boundaries, not at failures. The worst moment to stop is mid-spiral, when stopping feels like defeat and you will not do it. Stop when something lands — the test goes green, the agent finishes the refactor. Seams are cheap; rescues are not.
  2. Count hours in the tool, not hours at the desk. Time at the desk includes lunch, meetings and staring out of the window. Time actually inside an active session is the number that predicts how you will feel at seven. It is usually lower than you would guess, and rising faster.
  3. Make the pause short enough that you will actually take it. A fifteen-minute walk is better and you will not do it at hour six. Forty seconds of deliberate physiological reset — a long exhale, feet on the floor, eyes off the screen — is a thing you will do, because refusing it is more effort than doing it. See what a 40-second reset is.
  4. Count codebases. Holding three repositories at once is not three times the work, it is three sets of context competing for the same room. Two is usually the honest ceiling.
  5. Watch for the prompt collapse. When your instructions go from two clear sentences to no. undo that, the session has changed character. That is not the agent getting worse. It is a readout.

One honest caveat. Nothing here is a clinical claim, and none of it is a diagnosis. These are patterns in how a working session behaves — hours, retries, error rates, the shape of your own prompts. Persistent exhaustion that survives the weekend is a conversation for a doctor, not a statusline.

Measuring it instead of guessing

This is the problem Tempo was built for, and the reason it measures dose rather than only trouble. It watches the shape of your session — never the content — scores it, and warms a single glyph in your Claude Code statusline as load rises: steady, elevated, depleted. Past an hour it shows your running total for the day, so a calm dot is visibly a measured calm dot rather than a broken one.

At the top of the scale, and only in a seam — after a turn completes, when nothing is running — it offers one 40-second reset, and cites the signal that earned the offer. At most twice a day, with ninety minutes between. A single decline silences it. It makes no network calls, stores no prompt text, and rm -rf ~/.tempo erases everything it ever knew.

See your own hour six

Free through the beta. One line, about two minutes, and the glyph in your next session is the proof it is running.

curl -fsSL https://trytempo.net/install.sh | bash

Piping to bash deserves a look first — read the script. Or see all the install options, including the skill file for Claude chat, Cowork and Claude in Chrome.

no accountno network callsno telemetry