Someone at work recently said that with AI, their perceived cost of context switching had gone to zero. This surprised me at first because context switching is a notorious bugbear of engineers.
Context switching is what happens when someone or something interrupts you during focused work: All of the information your brain was juggling drops to the floor. When you get back to your task, you have to re-assemble all of that context again, slowly and laboriously working your way back into a juggling rhythm, one ball at a time. Ugh.
There is a ton of research that supports the notion that interruptions are costly and that it takes at least 20-30 minutes to find your way back to a productive point after an interruption. It’s a central thesis of Cal Newport’s 2016 book Deep Work that “the act of focusing without distraction on a cognitively demanding task” is a “superpower in our current economy.”
Recovering from interruptions – context circa 1950-2025
Interruptions happen. No one gets to work on just one thing. If that job exists, tell me where to apply. So how do we get better at resuming interrupted tasks? Chris Parnin and Spencer Rugaber wrote a paper in 2010 called “Resumption strategies for interrupted programming tasks.” To give yourself the best chance of getting back to productive, here are the kinds of things you should do before you suspend work on a task:
- Leave a note at the exact point of interruption. Put it directly in the code as a comment (e.g.
// TODO: fix this, was in the middle of X) rather than in a separate note-taking app — a situated note carries the surrounding context with it. - Deliberately leave a compile error or failing test at your stopping point, if you can. This forces you back to the right spot when you resume and creates active curiosity about why it’s broken, rather than relying on memory alone.
- Prime your environment as a memory cue. Leave the relevant file open, the cursor on the right line, or an error message visible on screen instead of closing everything down — navigating back to a cue is a stronger trigger than starting cold.
- Prune anything irrelevant. Close extra tabs, windows, or files unrelated to the task so you don’t hit interference from unrelated context when you return.
- Scaffold the remaining work if the task has multiple steps. Add high-level comments or placeholders outlining what’s left to do — effectively writing a mini task breakdown into the code so you can restore the plan, not just the last edit location.
For software engineering in particular, leaving breadcrumbs to lead you back to the specific thing you were working on five levels down in a cognitive tree helps you get back to that point faster. But you also need to remember things about the first four levels: What calls this code? Is this method a database query? What are the indexed columns? How is it cached?
The new context
Sometime in 2025, we stopped programming, at least in the traditional sense. While we might peek at some critical sections in a PR, we’re more likely to direct and interrogate a coding agent to direct and interrogate the code: Verify cache invalidation when an hourly aggregate is updated. Re-run the 5-minute model for every top-of-hour interval yesterday and report mean and median runtime.
We’re not five layers down anymore. We’re skipping around between layers and working at a coarser conceptual grain, leaving the finer grain to the harness and model. For those of us who had a longer stretch of pre-2025 programming, it’s taken some adjustment. But with a little practice it becomes freeing to zoom out and work at a more abstract level. We’re now living in solution space instead of code space. Our knowledge of what happens down on level five of the code is still useful, but we don’t spend a lot of time there.
I currently have six coding agents open across multiple repos. None of them are running right now, but I leave them open and jump back in whenever I need to kick off new work. Writing things down is still the key to doing complex work, but now I don’t have to leave TODOs in the code because the agents are writing things down for me.
The new context is more coarse grained and the harness and model maintain the old fine-grained context. You could say the new context is just a pointer to the old context. That’s why it’s easier and cheaper to switch, because you’re switching pointers, not the context itself.
Making the new context legible
Do I worry about losing my understanding of what the agents are doing? Yes. Does it bother me to just be a manager of agents and no longer a software craftsperson? Sometimes. Am I concerned that my critical thinking skills will atrophy? Deeply.
I don’t have answers to these worries yet, and in fact I’m consciously working on suppressing my controlling instincts to “supervise” the agents. Instead, I’m doing what I learned to do as a manager of humans, asking “give me a sketch of your solution … did you think of X, Y, or Z? … how will this perform at 600k records per minute? … if this breaks, how will it break? … no tautological or silly tests, please.” I’m not recommending these, just telling you what I do. These satisfy my need to stay in touch with the implementation, and they’re much easier to juggle across multiple projects than the details of what method of what class I was working on when someone tapped me on the shoulder.
So, yes, context switching is easier now, and if you want to get a human-readable summary of a coding agent’s context, you can just ask. Many people have created skills that summarize sessions in different ways for different use cases, but you can always start with “Remind me what we're working on again?“
I created a small slash command for Pi called pi-recap that uses the following prompt to generate a legible context for me:
Generate a recap of this workstream to help the developer re-enter the session after time away, written for a human catching up rather than for the agent’s own state-tracking.
Open with the original goal as stated or inferred, so the developer can re-anchor on what this session was actually for. Summarize the work done so far as a short narrative of what was built or changed and why, not a diff or file list, since the developer needs to reconstruct intent rather than inspect edits the agent already has in hand.
Call out the decisions or tradeoffs made along the way that a returning developer would need to know to avoid re-litigating them or being surprised by them. State plainly what is still unresolved or in-progress — an open question, a choice deferred to the developer, or a part of the task not yet started — since this is the gap the developer’s judgment needs to fill, not something the agent can silently resolve.
Close with one concrete next action, framed as a recommendation the developer can approve, redirect, or take over, rather than an open-ended list of options. Keep the whole recap under 25 lines, tight enough to read in a few seconds, since its job is re-orientation, not documentation.
Here’s what that looks like for a short session before publishing that repo:
Making your context legible for others
Companies are still populated mostly by humans. Humans are terrible at communicating. Natural language is not optimized for lossless information transfer. This is frustrating and costly. Tom Wujec has a great TED talk in which he makes visible how different people’s mental models are when they are asked to draw how they make toast.
Agents haven’t solved this yet, but I want to leave you with a thought-provoking post from John Cutler’s brilliantly named newsletter about product development, The Beautiful Mess.
Say I have 10 stakeholders, and each stakeholder likes information “a certain way.” Pre-AI, I didn’t have many options. I could:
1. Try to persuade them all to look at information the same way [not going to happen]
2. Make 10 versions of every presentation so that we could have effective meetings [worth a try if you have 2 days to spare!]
The full post is worth a read, not just for engineers or product managers. It’s relevant to AI’s ability to hold and recap context in different ways for different types of brains.
Leave a Reply