Lately I've been developing several projects in parallel with AI. I hand an implementation to Claude Code or Codex, and while it cooks, I move on to another project. There I ask another AI to implement something, then on to the next. I am, more or less, a scheduler juggling a handful of processes.

Even when there's only one project, not much changes. I split it into separate working trees with git worktree and hand different tasks in the same repository to AIs in parallel. In the end, what I'm lining up isn't so much projects as tasks.

And it's true that I spend far less time writing code. Implementations that used to eat hours are often done while I'm making tea. The version of me from a few years ago would have fallen out of his chair.

But lately something doesn't add up. Writing code has gotten overwhelmingly easier, and yet, somehow, I'm more tired than I used to be.

Of course, maybe I'm simply doing more work. The one who got carried away spawning more processes was, after all, me. Still, running several AIs at once leaves me with a peculiar kind of fatigue that doesn't seem to be explained by workload alone.

A single-core head

Say one project is in the middle of authentication work, another is tinkering with its database, and a third is getting UI fixes. Even within a single repository, each worktree has a different feature moving forward at the same time. As long as each AI has its instructions, all three move forward at the same time. So far, so good.

The trouble arrives once an AI finishes. Now I have to review what it did. Reading the authentication code means recalling that project's auth flow and design. Reviewing a database change means loading the existing table structure and the blast radius back into my head.

The AI dutifully keeps each project's context intact while it works. My head does not. No matter how many AIs are lined up, the reviewer is still a single core. Every time I switch tasks, a context switch happens and I have to load the new task's context from scratch.

What was I thinking about a minute ago? I mutter that to myself and reread code and chat history more often than I'd like to admit. It wears on me more than I expected.

A half-remembered book

Come to think of it, I recall reading about something like this once: Johann Hari's Stolen Focus. As I remember it, the book is about how smartphones, social media, and modern ways of working are eroding our ability to concentrate.

I think it said that simply switching between tasks carries a cognitive cost. Something about how every time you respond to an email or a phone notification, your focus breaks, and getting back to what you were doing takes time. ...Or so I've written, but frankly I'm not confident.

My memory was hazy, so I had an AI look up the related research (asking the very thing that steals my focus to summarize a book about focus is a little odd, I admit). It turns out there's a concept called task-switching cost: when people switch between tasks, it isn't just the screen or the work that changes, there's a cognitive load involved too.

Then I found a more interesting study: Sophie Leroy's 2009 paper, "Why is it so hard to do my work? The challenge of attention residue when switching between work tasks." When you switch away from an unfinished task, part of your attention stays behind, and performance on the next task suffers. The phenomenon is called attention residue.

That one hit close to home. I'm thinking about one task when another AI reports that it's done. While I'm reading that code, yet another AI asks me to check something. On screen I've switched tasks, but in my head I may still be chewing on the previous task.

To stretch the earlier metaphor, I think I've switched, but the previous process is still squatting in the background. Of course, this research isn't about AI coding. Even so, it looks like a real clue to what this fatigue actually is.

Self-sufficient in notifications

The other thing I found interesting was a 2015 study on smartphone notifications. It found that even without touching the phone, merely receiving a notification hurts performance on tasks that demand attention. Not even touching it is enough, apparently.

Seen that way, AI coding agents may have become a new breed of notification source. "Implementation complete." "Tests failed." "Please review." Every time one of these arrives, my attention drifts from whatever I'm doing.

Worse, unlike email or Slack, these are notifications I can multiply at will. Sitting idle while an AI does the work feels like a waste, so I give another AI a job too. And sure enough, that AI starts asking me to check things as well.

I think I'm being efficient, while busily building a machine for stealing my own focus. Self-sufficiency in notifications. Of all the ways to be wrong, I managed to be wrong industriously.

Judging instead of writing

So what has AI actually changed about development? I used to write the code myself to build a feature. Think through the design, write it, run it, fix it. It took time, but for that whole stretch I was mostly wrestling with one problem.

These days, I spend much less time writing code myself. In exchange, there's more instructing the AI, reviewing what it built, making design calls, and asking for fixes. And I'm doing all of that across several tasks at once.

In hindsight it's obvious: what went down was the time spent writing code, not the need to think. If anything, because the AI keeps churning out implementations, the number of decisions a human is asked to make may have gone up. Work done with the hands has been swapped for work done by making calls.

What bothers me most is that the speed at which AI generates code and the speed at which a human understands and judges it don't necessarily match. AI can write a lot of code in a short time, but making sense of it still takes a corresponding amount of time. Add switching between multiple tasks, and of course it wears you out.

At that point, it seems to me, raw brainpower starts to show, and bluntly. Hold several contexts in your head, read the code the AI wrote, and make a call on the spot. That's no longer a contest of fast hands; it's a contest of quick minds. Back when the hands did more of the work, even an ordinary head like mine could make up the difference through sheer persistence. But the moment AI took over the writing, what was left was the speed and accuracy of judgment, and there's no fudging that.

I'll confess: I'm not especially sharp. With every switch I drop part of the previous context, and I end up rereading the same code again and again. Handing everyone a powerful tool like AI may, if anything, have made the differences in ability on the human side more visible. At least, that's how it feels to me. If so, it's ironic, to say the least.

Beyond efficiency

To be clear, being able to move several projects forward with AI is something I'm genuinely grateful for. Ideas I used to give up on for lack of time can now take shape. And it isn't just side projects. At my day job, too, development is moving at a pace that would have seemed impossible a few years ago. I'm actually building more, and I do feel more productive.

As far as efficiency goes, I really did succeed. Work on another task while the AI implements, and the waiting disappears; my hands never stop. The question is whether that's the optimal setup. If every switch carries a cognitive cost, this efficiency comes with a hidden price. It got faster, sure. So what's the best way to run things?

I can think of a few candidates. First, settle into a single task and move it forward in larger chunks. Narrowing down to one project isn't enough on its own: if tasks are lined up across worktrees, the switching happens inside the same repository too. Or maybe it's enough to keep the AIs running in parallel but set aside one block of time for reviewing their results. Fewer processes, or scheduled review time.

Another option is to change what I do with the wait. While the AI implements, instead of reading code from another task, I could pin down the next part of the spec for the feature I've handed off. Or I could interview users and confirm what we should be building in the first place. Neither is something I can hand off to an AI wholesale, and neither forces me to swap out the context loaded in my head. Free hands don't have to mean spawning another process.

Frankly, I don't know yet which one is optimal. It may well depend on the size of the task, or on how my head is doing that day. I'm also curious how much research actually exists that looks squarely at parallel development with AI and cognitive load.

While I'm confessing: I wrote this very post while waiting on an AI running implementations and tests in the background. Not pinning down a spec, not interviewing users. Even as I typed, part of my mind kept wondering whether the tests had passed. A living specimen of attention residue, in other words.

Heads don't run in parallel

AI has undeniably made writing code easier. Running several projects on your own is far more realistic than it used to be.

But that doesn't mean the human head can now process things in parallel. However fast AI writes code, the one who understands it and makes the call is, in the end, me. Going forward, protecting my own focus may matter a great deal more in AI development than writing code quickly.

Having written all that with a straight face, here I am again today, handing implementations to several AIs at once. My terminal tabs keep multiplying.

References