My Brain Never Gets to Clock Out

A few weeks ago I finished a day of what we now politely call “AI pair programming” and realized I was more drained than after any day of hard manual coding I could remember. Not tired in the good way, the way you feel after a long run. Tired the way you feel after a long argument with someone you can’t stop agreeing with.

I couldn’t explain it at first. The code got written. The tickets moved. Nothing went wrong. But my brain felt like it had been doing sprint intervals for nine hours straight, and I hadn’t written a single line myself.

Then it clicked. The work didn’t disappear. It got promoted. Every task that used to be easy implementation is now high-level architecture, and my brain never gets to clock out.

The death of easy work

There is a lie we tell ourselves about programming, which is that the typing is the hard part. It isn’t. The hard part is deciding what to build and why. The typing was always the rest.

Think about the tasks that used to fill the comfortable middle of a workday. Renaming a variable across six files. Writing the boilerplate for a new endpoint. Building the same form you have built forty times. These were low-stakes, semi-mechanical, and weirdly restorative. Your strategic brain could go quiet. Your hands knew what to do. That is flow state, and flow state is a break for the part of you that makes decisions.

AI deletes that break. It takes the typing and leaves the deciding. You no longer write the function. You describe the function, evaluate three versions of it, and pick the one that is least wrong. The mechanical work is gone, and with it the only part of the day your architecture brain got to sit down.

Key Takeaway: AI removes the implementation, not the thinking. What looks like less work is actually the same thinking with the recovery time stripped out.

Every task is now a design decision

Before, a small task was a small task. You opened the file, you wrote the thing, you moved on. The cost of being wrong was low, because you were close to the code and you would see the mistake in the next compile.

Now a small task is a design review you run in your own head. Should this be a hook or a utility? Do we want it typed strictly or loosely? Is this the right abstraction or are we premature? You are making these calls constantly, for work that used to require none of them, and each one is a tiny withdrawal from the same account.

This is decision fatigue, and it is the new bottleneck. Not token limits. Not model quality. The number of meaningful choices a human can make in a day before the quality of those choices craters. We have built a workflow that maximizes the number of choices per hour and then wonder why everyone is fried by Thursday.

The review tax

The cruel part is that reading AI code is harder than writing your own. When you write it, you hold the reasoning in your head as you go. When the model writes it, you have to reconstruct the reasoning from the result, and you have to do it while suspicious.

To judge a diff you didn’t author, you must hold the entire architecture in your working memory at once. You can’t coast. You can’t skim. A subtle bug in a generated function looks exactly like a correct one until you trace the types through three files, and the only thing that catches it is a human who is paying full attention the whole time. So the vigilance never lets up. The model does the typing and then bills you, quietly, in attention.

What this does to a team

Here is where it stops being a personal complaint and starts being an organizational problem. The shift I just described does not stay with the individual. It scales, and it scales badly.

Everyone becomes an architect. On an AI-native team, the junior who used to learn by implementing now mostly prompts, and the senior who used to rest into mentoring by pairing now audits. Nobody gets the easy work, because there isn’t any. The whole team lives in the high-cost decision layer, and the layer where you build muscle memory by doing the boring thing simply evaporates.

The apprenticeship ladder breaks. We used to onboard people by handing them the boring reps. Rename this, wire that, build this form the long way. Those reps were not busywork. They were how a person developed pattern sense, the gut feel for what clean code looks like before they could explain it. Automate those reps away and the junior skips the part where they build intuition. They arrive at architecture decisions with no reps underneath them, and you can feel it in their code reviews.

The implementation floor disappears. Somebody used to own the low-level details. Not in a heroic way, just by having typed them. That ownership meant that when something was subtly off, a human pattern-matched it on instinct. When no human types the details, no human owns them, and the subtle errors stop having a natural predator. The bus factor on “who actually understands this” goes up while the code volume goes up faster.

The velocity paradox. The team ships faster, which leadership reads as health. But it understands less of what it ships, which is the opposite of health. Meetings that used to be about building become meetings about aligning on architecture, because now everyone is making architecture calls and they have to agree. Decision fatigue, which was already the bottleneck for one person, now scales with headcount. The fleet moves fast and nobody is sure who is steering.

Key Takeaway: The team that ships at fleet velocity on AI is also the team that is mentally fried and quietly unsure how its own internals work.

What helps, lightly

I am not going to hand you a ten step playbook, because that is the other article’s job and I would be performing the very optimization I am critiquing. But a few things have helped me, and they might help your team.

Carve out deliberate implementation time and protect it. Not as a treat. As maintenance for the part of your brain that the AI workflow is starving. Reinstate low-stakes reps for juniors on purpose, even when the model could do them faster, because the reps are the point. Share the architecture load across humans so it is not one brain carrying the decision weight for three streams of output. And schedule dumb work on purpose, the kind that lets the strategizing mind go quiet for an hour.

None of this makes the architecture tax go away. AI genuinely changes the shape of the work, and the work is real. But you can stop pretending the tax isn’t there, and you can stop letting it be the only kind of thinking your team does all day.

Final thoughts

A few months ago I wrote about the AI-native team and how orchestrating intent beats writing lines. That piece is true. This one is the footnote it was missing. The orchestra is faster. It is also exhausting, and the exhaustion is not a personal failing. It is the predictable cost of promoting every task to a decision.

As I argued in your codebase is an asset, if a tool touches your code it becomes a stakeholder in your technical debt. The same is true of your attention. The model is now a stakeholder in how your team spends its cognitive energy, and right now it is spending all of it.

This piece was inspired by a recent post from Matt Pocock, who put the feeling into words I couldn’t find at the time. I was living it myself after a few dev cycles on Hero Foundry, and the resonance is what pushed me to write the footnote above.

If your team ships at fleet velocity but nobody can explain how the internals work, what are you actually optimizing for? And who is going to notice when the architecture quietly rots?