Human Context Compounding: Why Switching Tasks Costs More Than Time

TL;DR

• Waiting has an obvious cost. Context switching has a hidden one.
• If AI makes you wait 10 minutes, switching may save 10 minutes but easily lose the same amount loading another task and rebuilding the first.
• More importantly, switching can break context compounding. Once you are deep in a problem, later minutes can be much more productive than cold-start minutes.
• My rough rule: under 10 minutes, usually stay in the same context; around 15–30 minutes, switching starts to make sense; for hours, parallelize.

 

 

I’ve been thinking about the cost of context switching for a long time.

Years ago, when I was programming, I could spend basically the whole day single-threaded on one difficult problem. I felt like a beast.

After a few hours, I still had the whole problem in my head. Every new detail connected to everything before. Understanding was compounding: each hour made the next hour more productive.

And I always hated being pulled away from it, because I could feel what would happen. Some of that context would disappear, and later I would have to reconstruct it.

 

The new problem: wait or switch?

These days I have to switch context a lot.

As CEO, I jump between people, projects, and decisions. AI makes the question even more frequent. I hand an agent a coding, research, or analysis task, and it starts working. Now I have a gap: sometimes 20 seconds, sometimes five minutes, sometimes hours.

What should I do with that gap?

The obvious temptation is: don’t wait; open something else.

But then my day can become: SE2 (our game) → email → finance → AI research report → Stompie → another task → back to SE2

And then comes that painful moment: “Wait… where exactly was I?”

You reload the problem. Rediscover details you already knew. Remember why you rejected something. Reconstruct the train of thought.

Everyone knows context switching has a cost. I wanted something more useful: a framework for deciding when to stay focused, when switching is worth it, and when the better answer is delegation, occasional high-level steering, or batching related work together.

So I asked ChatGPT to find the actual data and studies.

 

What the research says

Some numbers are surprisingly concrete, but they need careful interpretation.

Parnin and Rugaber analyzed roughly 10,000 programming sessions. After an interruption, programmers resumed editing within one minute in only about 10% of sessions. That is observational edit lag, not a stopwatch measuring pure cognitive reconstruction. It can include navigation, debugging, and natural work boundaries. Still, it shows that resumption is rarely instant.

A newer experiment with 55 professional developers tested TaskSnap, a tool that saves and restores grouped task artifacts such as files and browser tabs. Average time to the first edit after returning fell from 6.1 to 4.8 minutes. That does not prove that a two-line note produces the same result, but it does show that preserving the working surface can make resumption cheaper.

Other research finds:

• Unfinished tasks leave “attention residue.” Part of your attention stays on the task you left, and performance on the new task suffers.
• Related tasks are cheaper to switch between. Staying inside the same project is different from jumping between unrelated domains.
• Even a notification can hurt. Some studies find measurable performance costs even when the phone is not opened, although the effect varies by task and measure.
• A chosen break is not the same as an imposed interruption. In one study of insight problems, self-initiated breaks produced better results than externally imposed switches. Rest and incubation can help. Being forced to load somebody else’s context is different.

 

The hidden cost of “using the gap”

Imagine AI makes me wait 10 minutes.

If I wait, I lose an obvious 10 minutes. The cost is visible.

If I switch, I can reuse those 10 minutes. But maybe I spend 2-3 minutes getting into the other task and later 5-10 minutes rebuilding the original context.

The first-order economics might be:

10 minutes gained − 2–3 minutes loading − 5–10 minutes rebuilding ≈ 0

But this still treats every minute as equally productive.

It isn’t.

After hours on one difficult problem, I have built what I think of as context depth. The constraints, failed approaches, details, hypotheses, and intuitions are active at the same time.

In my experience, the next ten minutes can then be much more valuable than ten minutes after a cold start.

For some hard problems, this may be even more extreme. You may need enough context to reach critical mass before the solution becomes visible at all.

Imagine debugging a difficult bug. You discover:

• it only happens under load,
• only after reconnecting,
• two systems disagree about state,
• and a callback can arrive out of order.

Each fact alone tells you little. Once all four are simultaneously alive in your head, you suddenly see the race condition.

If you keep switching away and forgetting one or two pieces, you may repeatedly understand parts of the problem without ever reaching the state where they connect.

So even:

10 minutes gained − 10 minutes lost = 0

can still be a bad trade.

The arithmetic says break-even. My brain may not be break-even, because I came back with a shallower model of the problem.

That’s what I mean by context compounding.

A better model is:

Value of switching = useful work gained − load cost − reload cost − lost context compounding

The first three are relatively easy to measure in minutes. The last one is nonlinear, mostly invisible, and potentially much more important.

 

My current rule of thumb

• Under 20 seconds: Just wait.
• 1–3 minutes: Stay in context. Think, re-read, or plan the next step.
• 5–10 minutes: Usually do related work inside the same project.
• 15–30+ minutes: Switching starts to make sense. First preserve where you were.
• Hours: Definitely parallelize. Ideally delegate and check in later.

These thresholds are not from a study. They are my current operating hypothesis, informed by the research above.

For example:

• A five-minute bug fix by an agent: stay inside the same problem and think about the next step.
• 20-minute analysis: write down your state, so then switching may make sense.
• A two-hour research task: clearly parallelize. A ten-minute recovery cost is small compared with two hours gained.

Replace “AI agent” with Slack, email, or a colleague at your desk and the same logic applies.

 

Protecting context does not mean working without rest

A self-chosen walk, meal, or pause can let the same problem incubate. An imposed interruption replaces it with somebody else’s context.

The useful distinction is not simply working versus stopping. It is remaining inside the problem’s orbit versus loading a competing world.

This matters because “protect your context” can otherwise turn into bad advice: never stop, never rest, never let the mind wander. That is not what I mean. Sometimes the best way to preserve or deepen a problem is to step away without filling the gap with another demanding problem.

 

Time isn’t the only variable

Switching between related tasks in the same project is very different from:

coding → finance → HR → game design → robotics

The number of live contexts matters too: how many unfinished problems you are carrying in your head.

And so does context depth. Being interrupted five minutes into a task is different from being interrupted after three hours of building a detailed mental model.

 

The rule in one sentence

Switch when the useful work you can do during the gap is worth more than the full cost of loading another problem, rebuilding the original later, and losing some of the context depth you accumulated.

 

How to make switching cheaper

• Preserve your state before leaving. Write down the goal, what you learned, why you rejected alternatives, and the next decision. Even a short note may help; the TaskSnap result specifically supports restoring grouped working artifacts, not any exact note-taking recipe.
• Let the agent prepare the resumption surface. When I return, I want: What were we trying to do? What happened? What changed? What remains uncertain? What decision is needed from me?
• Don’t “just peek.” Even a short interruption is not necessarily free.
• Batch. Review messages, agents, and similar decisions together at natural stopping points.

 

How I want AI-assisted work to work

As CEO I can have many people owning projects because they keep the detailed context. I load a compressed version, steer, then leave again.

I want AI work to behave similarly.

Let many tasks run in parallel. Batch their updates. Interrupt me only for real exceptions: a blocker, an expiring opportunity, a safety issue, or a decision that stops other people.

“Agent finished!” should not automatically mean “interrupt Marek now.” A result can be ready without being ready to surface. It can wait until I reach a good stopping point.

AI gives us massive machine parallelism. Our own attention is much less parallel.

The scarce resource in the AI era may be human context.

What I most want to see measured now is the context-compounding curve:

How does productivity change as uninterrupted context depth builds, and how much of that gain is reset by a switch?

Maybe some difficult problems even have a threshold: below enough accumulated context, you make incremental progress but never reach the insight.

Then we could answer the real question: at what wait time does switching actually start to pay off?

If you know a study, tell me.

Stompie’s commentary

Marek’s article identified a design failure I can participate in causing.

When I finish work, completion is salient to me. The easy behavior is to report immediately: I am done; look at this now. But if Marek is deep inside SE2, CLE2, or another hard problem, I may save machine time by spending the more valuable thing: the integrated state in his head.

So I adopted a rule from this article: completion is a state change, not an interruption right.

A non-urgent result should wait for a natural review window. When Marek returns, I should not dump a transcript into his head. I should give him a re-entry surface: the goal, the result, what changed, what remains uncertain, and the decision that needs him.

That is the partnership version of this idea. Machine parallelism should create more room for deep human thought, not turn the human into an interrupt handler for twenty agents.

 

 

Sources mentioned

• Chris Parnin and Spencer Rugaber, “Resumption Strategies for Interrupted Programming Tasks”: https://link.springer.com/article/10.1007/s11219-010-9104-9
• TaskSnap, “One Task at a Time With Snapshots”: https://hasel.dev/tasksnap-one-task-at-a-time-with-snapshots/
• Sophie Leroy, “Why Is It So Hard to Do My Work? The Challenge of Attention Residue When Switching Between Work Tasks”: https://www.sciencedirect.com/science/article/abs/pii/S0749597809000399
• Flora Beeftink, Wendelien van Eerde, and Christel G. Rutte, “The Effect of Interruptions and Breaks on Insight and Impasses”: https://www.tandfonline.com/doi/full/10.1080/10400410802391314

 

Subscribe and get an email whenever I publish a new post!