The Multitasking Myth

I've never believed in multitasking. Not for humans. And here's what most non-technical people don't realize: not even for computers.

A CPU doesn't do five things at once. It does a little bit of one thing, saves its place, picks up the next thing, does a little bit of that, saves its place, picks up the next. Context switching. The processor works on a thread, stores its state (registers, stack pointer, program counter), swaps in the next thread's state, and picks up where that one left off. On a single core, only one thread is ever executing at any given instant. Multiple cores give you actual parallelism, but even then each core is still context-switching between more threads than it can run simultaneously.

What makes this work in computing is two things. First, the switching is essentially perfect. The CPU doesn't lose information when it saves state. It doesn't accidentally carry over data from one thread into another. Memory is isolated. The context is preserved exactly as it was. Second, it's blindingly fast. A context switch takes microseconds. The overhead exists, and OS engineers spend careers minimizing it, but to a human observer it looks instantaneous. It looks like multitasking.

Humans have neither of these advantages.

The Human Version

When you switch from writing code to answering an email to reviewing a pull request, you don't save state perfectly. You lose things. The variable name you were about to type. The architectural concern you were holding in your head. The thread of logic you'd been building for the last twenty minutes. It doesn't get stored in a register somewhere. It evaporates. And when you switch back, you have to rebuild it. Sometimes from scratch.

The research is pretty clear on this. The American Psychological Association has documented what they call "task-switch costs," which is just a clinical way of saying you lose time every time you jump between tasks. Studies consistently put it at 20 to 40 percent of productive time. Not 2 percent. Not 5 percent. A quarter to nearly half of your working time, gone. Not because you're lazy, but because your brain doesn't have memory isolation. Context from one task bleeds into another. The rebuild time is real and it compounds.

I've known this about myself for thirty years. If I have five tasks and I try to work on three of them in parallel, it takes me longer to finish all three than it would've taken to do them one at a time. And the quality is worse. We all know multitasking is a myth. We just keep doing it anyway because it feels productive.

The Multiplier

Here's where agentic development makes this interesting, and not in a good way. I'm working in Claude Code on a task. It's churning away, reading files, writing code, running tests. While it's doing its thing, I have a thought. There's this other task I've been meaning to get to. And the agent is going to be busy for a few minutes anyway. So I open another terminal window, spin up another Claude Code instance, and start a second task. That one gets going, and I think of a third thing. Open another window. For instance, I started writing this article while I was publishing my last article, while I was waiting on Claude to finish making changes to the draft of my upcoming presentation. Three tasks, three windows, one brain. And I didn't even notice I was doing it until I was already deep in all three.

For about five minutes, this feels like a superpower.

Then they all start finishing at the same time.

One agent needs a decision about an API design. Another wants me to review a test that's failing. The third is asking a clarifying question about requirements. And then my phone rings. Someone wants to talk through a deployment. So now I'm switching between three agent outputs that each require genuine evaluation, while trying to have an intelligent conversation with a human being.

Anybody who's talked to me during one of these moments knows exactly what it looks like. They'll pause mid-sentence and say something like, "I'm just waiting for you to pay attention to me again." And they're right. I'm not paying attention to them. I'm not really paying attention to any of the three agents either. I'm doing the human equivalent of a context switch every fifteen seconds, and losing state every single time.

The Bottleneck Moved

This is the part that took me a while to see clearly. In traditional development, the bottleneck was production. Writing the code, running the tests, doing the deploy. That was the slow part. The thinking, the architecture, the design decisions, the code review? That was relatively fast because you did it in the gaps while waiting for the slow part.

Agentic development flipped that. Production is now the fast part. The agent writes code, runs tests, and iterates faster than I can read what it's doing. The bottleneck moved to evaluation. Reviewing what the agent built. Deciding if the approach is right. Catching the subtle architectural mistake that the tests won't flag. That's the part that requires my full, undivided attention. And that's exactly the part that gets destroyed by multitasking.

When I'm bouncing between three agent windows, I'm not doing the one thing that actually matters: thinking carefully about what each one produced. I'm skimming. I'm approving things I should be questioning. I'm missing the thing that'll cost me two hours to fix later because I didn't spend two minutes looking at it now.

Finding the Line

I've had to figure out where my limit is. Everyone's going to find their own sweet spot, but here's mine: it breaks the moment I need to talk to another person or apply critical thinking.

Two agents running on tasks that are mechanical and independent? One deploying, one running a migration? That's fine. I can glance at each output, confirm it looks right, and move on. The context-switch cost is low because neither task requires deep thought.

But the second one of those agents is doing something that requires my judgment, like designing an API or making architectural decisions or writing code that touches business logic, I need to be there for it. Fully there. Not "I'll check in when it finishes" there. Because by the time it finishes, it's made forty decisions I should've been watching, and I'm about to rubber-stamp all of them because I've got two other windows blinking at me.

And deployments? I just said deployments are fine to run in parallel, and as the words formed in my head I thought, "Yeah, that's not smart either." Because the one time something goes wrong in a deploy is exactly the time you need to not be distracted by two other things.

The Discipline

The temptation is real and constant. Agentic development creates dead time that feels wasteful. The agent is working, you're watching, and your brain screams at you to go do something else. Every instinct you have as an engineer, all that wiring around efficiency and throughput and utilization, tells you to spin up another task.

But the dead time isn't dead. It's the time when you're maintaining context. Staying in the problem. Keeping the state loaded so that when the agent comes back with a result, you can evaluate it with the full picture in your head. The moment you walk away from that to start something else, you've paid the context-switch tax, and you'll pay it again when you come back.

The irony is thick. We borrowed "multitasking" from computers, applied it to ourselves, and it was always a lie. Now we have AI agents that can actually do work in parallel, and the thing that limits them is the same thing that always limited us: the human in the loop can only genuinely focus on one thing at a time.

Context switching has a cost. It had a cost when it was just us, and it has a cost now that we have agents. The only difference is the scale of the mistake when we ignore it.

← Back to Blog