The Hidden Cost of AI: The Mental Load Behind Multi-Tasking Development

Give a developer three AI agents and they'll happily kick off three tasks at once. It feels like a multiplier: more work in flight, more throughput, more shipped by Friday. For the first few days, it is. Then the reviews start piling up, and something less obvious starts happening.

Each task an agent runs isn't just code being written somewhere out of sight. It's a thread the developer has to keep alive in their own head: what was this ticket actually asking for, what did the agent decide to do about the edge case in checkout, was that the right call, does this PR need a careful look or a quick skim. Multiply that by five parallel runs and you don't have five times the throughput. You have five open loops competing for the same limited attention.

This is the part that doesn't show up in a velocity chart. Task-switching has a cost that's been studied in cognitive psychology for decades, and it doesn't go away just because the actual typing is being done by something else. If anything, reviewing five different implementations in five different mental contexts back to back is harder than writing five features in sequence, because there's no ramp-up. You're expected to have full context on demand, cold, every time.

The teams that handle this well don't try to out-multitask the problem. They change what the human has to hold in their head at all. Instead of a firehose of raw diffs, they want a pre-digested judgment: what changed, why, what's risky about it, and what the agent is uncertain about. That's a different shape of information than a diff, and it's the difference between reviewing code and reviewing decisions.

That's also why context matters as much as automation. An agent that can explain its own reasoning, that flags the part of a change it's least confident about, gives a reviewer something to actually engage their judgment on, rather than forcing them to reconstruct the whole story from scratch. The cognitive load doesn't disappear, but it gets pointed at the right ten percent instead of spread evenly across all of it.

The next constraint on how fast software gets built isn't going to be how many tasks an agent can run in parallel. It's going to be how much of that work a human can meaningfully absorb without burning out. Teams that design around that limit, instead of ignoring it, are the ones who'll actually get to keep the speed they've unlocked.