Blog
The Run I Didn't Take
A few days before our team retro, I sat looking at six terminal sessions open on my desktop.
Each was running Claude Code on a different piece of work. Some were planning, some were waiting on permission to read a file, one had been chewing on a refactor for an hour or more. I’d lost track of which was ready for me and which was still thinking.
I wanted to go for a run. My legs were stiff, my head was full, and the cold air outside would have been the right answer to both problems. But none of the agents were running on autopilot — they were planning, asking questions, waiting on permissions. If I disappeared for thirty minutes, half of them would stall, and I’d come back to triage instead of momentum. There was too much to do — I could run when it was done.
Spoiler: I didn’t go for my run.
The team I work with day-to-day has leaned into AI tooling as a productivity enhancer — not a replacement for engineers, product owners, designers or testers, but a multiplier on what each of us can get done. By most measures it’s worked. Throughput is up. We’re shipping things that would have taken much longer a year ago.
But somewhere over the past few months I’d started to feel stretched in a way I couldn’t quite name. More productive than ever. Still not productive enough. I’m relatively new to the company, and I’d watched colleagues run staggering parallel workloads and quietly decided I needed to keep pace. So I took on more. Spun up more agents. Kept more plates in the air. And got progressively more exhausted.
My first instinct was that I simply wasn’t using the tools well enough. I read up on better orchestration patterns. I built a few custom agents tailored to my own workflow. None of it moved the needle — the exhaustion stayed.
The reveal came in our team retro. One of our engineers said:
“The tools are great. We’re getting more done than ever, but I feel like I’m close to burning out.”
The rest of the team agreed, including me. The thing I hadn’t been able to name suddenly had a shape.
It’s a two-stage problem, and I think the second stage is the one nobody is talking about yet.
The first stage is context switching wearing new clothes. Every engineer learns early that switching tasks is expensive — you lose your place, the cache flushes, you spend twenty minutes re-loading what you were doing. The defence is to do one thing at a time.
But agentic engineering rewards the opposite shape. The work isn’t writing the code anymore; it’s orchestrating the agents that write the code. And once a single agent can grind on a task while you do something else, the productive move — the move that feels productive — is to start a second agent. Then a third. Then a sixth. The detail of any individual piece of code doesn’t get context-switched in your head, because the agent is holding it. But each task you’re shepherding still does. The load builds in a place engineers aren’t used to carrying it.
The second stage is more insidious — an erosion of the codebase knowledge we used to keep in our heads. We used to know how class A spoke to class B, how a particular API response was unpacked, how routing worked. With agents now writing a much larger share of what lands in the repo, that knowledge can no longer be quietly relied upon. And under pressure to move fast, the path of least resistance is to ask an agent rather than dig — which compounds the erosion.
In the retro we agreed, as a team, to try to minimise context switching. I’ve taken a different bet alongside that one: I’m trying to retrain my engineering brain to cope with the new shape of the work.
The intervention is unglamorous. I installed a tool called Spaceman on my Mac and now run one virtual desktop per workstream. One desktop for incident management — open incidents, alerts, the monitoring dashboard, the rota’s key contacts. One for comms — email, calendar, Slack. One for testing and debugging the mobile app — the simulator and a VS Code window on whichever worktree I’m currently in. And one desktop per active project, each with its own Claude Code terminal in its own worktree, the Jira ticket, the Figma frame, the relevant comms channels.
When I switch contexts, I switch desktops. When a piece of work is done, the desktop gets disposed. The agents benefit too — I can verify what they’ve produced against the designs and the acceptance criteria in the same physical space, without hunting through windows for the right tab.
It’s early days. But last week, while I was on the incident rota, my focus felt less stretched than it has in months. I could break off, look into an alert, and pick up what I was doing before without flailing for it. I also held myself to two concurrent projects instead of my recent average of four — and a long way from the eight I peaked at the week before.
The generalisable lesson, I think, is this. If we’re going to accept parallel context-switching as the new shape of the work — and the jury is still out on whether we should — then we need to shift cognitive load off our heads and onto our tools. A digital space per context is one small move in that direction. Capping concurrent agents is another.
The agents are productive. Keeping the engineer running them in one piece is a separate problem, and it needs its own scaffolding.
If your team is shipping more than ever and you’re quietly wondering why everyone looks tired, come and talk to me about the agentic engineer burnout problem. Worth having that conversation before the next retro names it for you.