Context Switching, More Important Than Ever
The era of agentic coding continues.
It’s kind of boring to rehash how wildly my productivity has grown in the last few weeks, but I feel like it’s important to set the stage. Here’s a chart of my weekly GitHub commits over the last two years:
Talking about the efficiency of agentic coding is already uncool, so that’s not what I’m going to do.
Even though the pace of change isn’t slowing, I feel like I’m hitting my groove. I often have three or four terminal windows open while I work, one in each quadrant of the screen, and I bounce between them.
Usually only one or two of them are Claude Code sessions. The others are for me to check infrastructure stuff or deploy apps – things I don’t want Claude doing for me.
Claude1 seems to be getting faster but I’m entrusting it with bigger tasks, and expecting it to do better research before taking action. On net, some things are now very fast but others are painfully slow.
And so, even more than before, it’s all about context switching.
The Early Days
I’ve been toying with AI coding tools since they first started making an impact. (I even gave a conference talk about it.) That was when they were just autocomplete with a seemingly-miraculous ability to anticipate what you were about to type.
When I started hearing about agentic tools, like Claude Code and Cursor, I didn’t really get the point. My fancy autocomplete was getting better and better every day, so I didn’t think there would be any benefit from being less involved with the code.
I was wrong. When I got Claude Code in the summer of 2025, and then Cursor shortly thereafter, I was thrilled at just how much I could trust the agent to do without my intervention. Of course, that’s only gotten better and better in the last six months.
But I had another reaction, one that I’ve seen expressed less often: it was awesome that I could do my reading in between prompting my agents! Every week, I read a good number of newsletters, and agentic coding enabled me to get a lot of that done during the time I was already going to spend working on personal projects.
Of course, toggling from listing feature requirements, to reading world news, to instructing Claude on the finer points of my preferred architectural patterns, to world news again is a recipe for mental fatigue. It’s genuinely tiring to engage with the details of how a software project works, then switch to something else entirely, and then try to re-engage.
But it’s becoming necessary to be a good software engineer.
Context Switching
Fairly or unfairly, I had a viscerally negative reaction to the advent of “Deep Work”, as Cal Newport calls it. The way I remember it happening is that some time around 2018, everyone heard about how context switching was bad and uninterrupted work sessions were good, and then started talking about how we should rearrange our workplaces to enable more of those uninterrupted blocks.
My reaction to this, even now, is basically: yes, duh. Being pulled away from your work because someone messaged you on Slack is annoying. It’ll probably take you some time to re-acclimate to the task when you return.
But that’s not to say you shouldn’t answer your coworker. Or that you should block 4-hour chunks every day to work continuously, making yourself unavailable.
The core work you produce at your job is (hopefully) valuable. But so is your ability to share information with others, as is your ability to react to changing circumstances when they occur.
The fascination with deep work has diminished, thankfully, but for a long time it was actually difficult to find space on certain coworkers’ calendars because they were in “focus blocks” – even if I desperately needed 20 minutes of their time to figure out a pressing issue.
Again, that’s not to say that context switching isn’t annoying, or that it isn’t disruptive. It’s just that in order to be effective in any organization larger than one person, you need to deal with it a fair amount2.
In the New Era
AI agents are making context switching relevant again. As I’ve spent more time bouncing between agents and other tasks (or sometimes agents in one project and different agents in another), I think my ability to do it is improving.
And that’s important, because that workflow is almost certainly going to be the dominant mode of software development until the field is completely handed over to AI. Investing in this as a skill, and accepting it as a way of working, is about to become table stakes at every technically-competent organization.
And to answer some objections: yes, I’m an enthusiast and yes, I’m relatively early in my career and more comfortable making changes. But it’s not going to matter if other engineers don’t like this change; it’s coming regardless. I think it’s totally plausible that the median engineer will be someone who manages two agents while still sitting in meetings with business stakeholders to field technical questions. Chugging along on one task is probably not going to be enough to keep up, at some point, no matter how talented you are.
Software engineering as a discipline is changing radically, and I recommend embracing that.
-
When I say “Claude” here, I mean “Claude Code and the main model I’m using (Opus 4.5 & 4.6)”. Whether the Claude API is faster, I can’t say. But newer Opus models in Claude Code seem to be able to act very quickly when given simple tasks or questions. ↩︎
-
I’m about to irritate the four readers who weren’t already annoyed, but I felt similarly about the brief hyper-salience of introversion, which I recall centering largely around the book “Quiet: The Power of Introverts in a World That Can’t Stop Talking”. Being introverted is fine, and I would consider myself more introvert than extrovert. But the idea that organizations should contort themselves to accommodate it feels crazy. Being effective at your job means exactly that: being effective. Sometimes that means working on your weaknesses, whether that’s a discomfort with public speaking, an inability to sit quietly, or difficulty context switching. ↩︎