Getting back into code after an interruption takes time: research calls it the resumption lag. A few seconds of preparation before you switch can make the return faster, and going back to where you last edited is often the quickest way in. Batch your agent replies, see which session waits before you switch, and go straight back afterwards.
Why getting back is the hard part
An agent pings you. You switch to its terminal, read what it wants, answer, and come back. The answer took thirty seconds. Then you look at your own code and cannot remember what you were about to do.
That gap is the subject of this guide. Its partner, Context switching with AI coding agents: what it costs, covers why switches are costly and how to have fewer of them. This one assumes the switch has happened and asks how to get back quickly.
What research says about resuming a task
The studies below looked at university students in labs, office workers in the field and programmers' recorded editor activity. None of them studied coding agents, so treat the findings as a guide to how memory and attention behave.
The resumption lag is real, even after short breaks
Erik Altmann and Gregory Trafton (Cognitive Science Society, 2004) gave 96 Michigan State University undergraduates a fast, complex task on screen and interrupted them with a second task. They measured the resumption lag, the time needed "to collect one's thoughts" and restart. It was "double the interval between uninterrupted actions (3.8 s vs. 1.9 s)".
Seconds sound small. But this was a task where people acted every two seconds and had been away for under a minute. Code holds far more state than that, so the return is often longer.
Programmers often need minutes, not seconds
Chris Parnin and Spencer Rugaber at Georgia Tech analysed about 10,000 recorded programming sessions from 85 programmers (IEEE International Conference on Program Comprehension, 2009). A session started after a break of 15 minutes or more in editor activity, whatever the reason for the break. They found that "only 10% of the programming sessions have coding activity start in less than a minute", and in about 30% of sessions the first edit came more than 30 minutes later. The authors suggest some of those long gaps may involve debugging before any edit.
They also found that "only 7% of the programming sessions involve no navigation to other locations prior to editing". In other words, people usually look around the code to rebuild their picture before they type.
Going straight back to your last edit is faster
In a smaller data set of 12 developers, Parnin and Rugaber looked at sessions where the first change was in the method the developer had edited last. In those sessions, coding resumed "within one minute 35% of the time". That happened in only about a quarter of their sessions: most of the time, people first went elsewhere in the code. When the work does continue where you stopped, going straight there is one of the quickest ways back in.
Cues left before the break help
Altmann and Trafton also gave people a warning a few seconds before each interruption. For some, the task stayed on screen during those seconds; for others, the screen went blank at the warning. Each warning length was a separate experiment with 24 people. With an 8-second warning, people who could still see their task resumed faster afterwards. With warnings of 2 or 4 seconds there was no measurable effect, and at 6 seconds the effect was only marginal. The authors read this as people using those seconds, without being told, to fix cues in memory that help them later.
The practical lesson is modest: a few seconds of deliberate preparation before you switch seems to pay off when you come back.
Returns often come after detours
Gloria Mark, Victor González and Justin Harris shadowed 24 managers, analysts and developers (CHI 2005). 77.2% of interrupted work was picked up again the same day. When it was, the return came after an average of 25 minutes and 26 seconds, and in between people worked in an average of 2.26 other areas of work. Informants described these detours as "very detrimental".
One switch often turns into a chain. You answer the agent, notice an email, check a build, and only then come back.
Before you switch: leave yourself a way back
The research points to the moment before you leave as the best time to act. These habits take seconds.
Leave a one-line note
Before you answer an agent, write down the next step you were about to take: a comment in the code, a line in a scratch file, or a sticky note. Make it concrete, such as "next: handle the empty list in parseRows". A note is a cue you can find again, and it keeps the plan out of your head while you deal with the agent.
Leave the screen where you were
Keep the file and the line you were editing open. Leave the failing test output visible. Parnin and Rugaber's data suggests that picking up at the last edit site is one of the fastest ways back, so do not close the tab you were working in.
Take the few seconds
When an agent pings you, do not jump at once. Finish the line, glance at what you were doing, and then switch. Altmann and Trafton's results suggest those seconds of preparation are not wasted.
While you are away: keep the detour short
The fastest way back is a short trip. These habits stop one answer from turning into five tasks.
See which session waits before you switch
If you do not know which agent needs you, you end up tabbing through terminals to find it, and each one you look at is another detour. Find out first, then go straight to the right session. How to monitor multiple Claude Code sessions compares the ways to get that signal.
Batch your replies
If two or three agents are waiting, answer them in one pass rather than coming back to your code between each. Several short trips cost several resumption lags. One trip costs one.
- Answer the agents that block other work first.
- Keep replies short and specific so the agent does not come straight back with a question.
- Do not start reading a long diff in the middle of a batch. Note it for later.
Do not chain other tasks
Once you have answered, go back to your code. Email, chat and builds can wait for your next planned break. The 2005 field study shows how often a switch picks up two or more detours before people return.
When you come back: rebuild quickly
- Read your note first, before you look at anything else.
- Return to the last edit site, then widen out only if you need to.
- Run the tests or the build once to see the current state.
- If you have lost the thread entirely, rewrite the next step in a sentence before you type code.
Some returns will still be slow, especially after a long agent conversation. That is normal, not a failing.
A glance instead of a search
Orbtile helps with one step here: knowing which session needs you without searching for it. It shows each coding-agent session as a tile on a Logitech MX Creative Keypad, on an iPhone or Android phone running Orbtile Mobile, or on your computer screen, with its name, state and latest words. Waiting sessions come first, and a summary tile shows how many are waiting and which one.
- One glance tells you whether anything needs you, so you can finish your line and leave your note first.
- A short press opens the waiting session's window, so the trip goes straight to the right place.
- For local sessions, supported permission requests and multiple-choice questions can be answered from the keypad without leaving your editor.
For how answering from the keypad or a phone works, see Approve agent tool calls without switching windows. A status pad does not bring your train of thought back. Your note and your open file still do that.
FAQ
What is resumption lag?
It is the time it takes to restart a task after an interruption ends. In one lab study of 96 students, the first action after an interruption took about twice as long as a normal action. In recorded programming sessions, the first edit after a break often came minutes later.
How do I get back into code faster after an interruption?
Before you switch, write a one-line note with your next step and leave the file and test output open. When you return, read the note, go to the last place you edited, and run the tests once before you widen out.
Should I answer every agent the moment it pings me?
Not usually. Finish the line you are on, leave a cue, and then answer. If several agents are waiting, answer them in one pass, then go straight back to your code instead of picking up other tasks.
Do notes really help?
In one lab study, people who could see their task for 8 seconds before an interruption resumed faster afterwards. Shorter warnings showed no clear effect. A note is a simple way to leave a cue on purpose, though no study here tested notes directly.