How long to refocus after an interruption? 23 minutes, or one tap

Agentic coding changed the shape of a developer's day. The agent works for minutes at a time, then stops and asks. Every one of those asks is an interruption, unless it arrives somewhere you can answer without leaving what you were doing. The research on interruptions is older than coding agents, and it tells you what each ask costs and what makes one cheap.

How long does it take to refocus after an interruption?

The number most people have heard is Gloria Mark's: across her office studies, workers took about 23 minutes on average to get back to an interrupted task. That figure covers knowledge work in general, and it includes the detours people take on the way back, not just the time to re-read the screen.

For programmers specifically, the picture is sharper. Parnin and Rugaber analysed 10,000 recorded programming sessions from 86 developers and surveyed 414 more. Only 10% of interrupted sessions resumed productive editing within a minute. Most needed a period of re-navigation first: opening files, scrolling to where they had been, rebuilding the mental model of what the code was about to do.

Sanchez, Robbes and González looked at the same problem from the other side, using several thousand interaction traces gathered from dozens of developers doing software evolution tasks. Work fragmentation correlated with lower observed productivity, and longer switches made it worse.

Why programming interruptions cost more than most

Programming is unusual in how much state lives in your head and nowhere else: which three files you are changing, why the test is failing, what you decided not to do yet. An interruption does not delete that state, but it decays while you are away, and the longer you are gone the more you rebuild on return.

The same mechanism is at work in an inbox that is always open: the cost is not reading the message, it is the attention the message takes with it when you go back.

PeakWatch does this from your own data. Your coding agent, on your wrist. Join the free beta →

Why coding agents make it worse before they make it better

An agent that needs your approval every few minutes produces the worst kind of interruption: unpredictable, brief and blocking. You cannot leave the desk, because it might ask. You cannot fully engage with something else, because it will ask. The productive time the agent saves is paid back in supervision, one glance at the terminal at a time.

There are three kinds of ask, and they arrive at different rates. A permission request (may I run this command, may I write this file) is the most frequent and the most urgent, because the agent is stopped until it is answered. A clarifying question is rarer and usually worth a sentence back. A finished task is the only one that can wait. Supervision that treats all three the same, by watching the terminal, pays the full price for every one of them.

The temptation is to remove the ask, and that is the wrong fix: an agent that never asks is an agent you should not run on your own machine. The gate is doing a job. The problem is where the gate is, not that it exists.

What makes an interruption cheap

Not every interruption costs 23 minutes. The expensive ones share a shape: they pull you to a different place, they need you to rebuild context before you can act, and they leave you somewhere else when they are done. A cheap interruption is the opposite on all three counts.

• It arrives where you already are. If answering means walking back to the desk, the walk is the cost, not the answer.
• It carries its own context. "Approve Write?" needs you to go and look. "Approve Write to src/api/auth.ts?" can be answered on sight.
• It fails safe if you ignore it. An ask you can leave unanswered without consequence is not an obligation; it is an option.

Anthropic's own Remote Control for Claude Code moves the ask to your phone, which handles the first point. How to set that up is its own guide. A watch handles all three.

Moving the ask to the wrist

The interruption cannot be removed. What can change is where the ask lands and how much it costs to answer. A request that arrives on your wrist, with the tool and its arguments in front of you, is answered in the time it takes to read a sentence and tap. You were in the kitchen, or in a meeting, or on a walk, and you stayed there.

This is the difference between the two bars in the figure above. One is the time to rebuild a working context after being pulled away. The other is a glance. The agent's question is the same in both cases; the cost of answering it is not. This is what asynchronous supervision depends on: asks that reach you and cost seconds, so you can be somewhere else while the work continues.

How PeakWatch handles the ask

PeakWatch ranks your sessions by which one is blocked on you, shows every permission request with its arguments and the SDK's reason, and lets you approve, deny or say why in one tap. Ignore it and the request denies itself when the sixty-second countdown ends. The sessions keep running on your machine; the interruptions stop owning your location. It is in private beta, on Wear OS watches, including Galaxy Watch, with a small relay you run yourself.

Hen Eytan · Founder, UPeak

Builds the UPeak apps and writes up the research behind them.