18 days ago
This blog post was written fully by human hands and thoughts. All em-dashes are my own.
Within the context we find ourselves as tech workers, given the changes AI has brought our workflows, the question of productivity remains above all else. With new technologies, productivity should increase. Are we seeing that? Where is it being slowed down?
Most people will answer that the human-review stage is the biggest choke point for spewing out change after change -- and rightfully so. This part of the step is the vital to ensure there's a quality bar being met and improved as we find ourselves further from our code than ever before. But there's another silent killer at work: context switching.
There are macro-switches and micro-switches. A macro-switch is a context switch between chunks of work. For example, if I'm working on a feature, and it's waiting for review, I'll switch context to a bug ticket. This means I'm getting up to speed on a different issue, probably in a different part of the code, with a different mindset.
"Macro-switching is bad for engineers". This seems like something we all agreed upon in the field just a few years ago. Recruiters often bragged about low meeting count for engineers, because no engineer wants to context-switch often.
The reason we didn't like context-switching in the prehistoric (pre-AI) days was the loading of context. Switch tasks, and you have to store your old context, then immerse yourself in the new one. Depending on complexity that could take anywhere from a minute to an hour.
Now, we're doing these macro-switches, which we used to avoid by any means, many times a day. But we're all producing a lot more code. Whether or not it's conscious, we're doing this by managing the amount of context we're switching. Switching context is expensive when the context is deep. So, to be able to keep up with our output, we keep our context shallow.
This is something that agentic coding is a superpower for. Our agent stores all the context that exists around a task. If we forget anything, we can just ask in plain language. Getting back up to speed is now trivial. Plus, since we're not writing the vast majority of our code anymore, our understanding of it is much more shallow. There's less context we need to gain.
These macro-switches, though they can be unpleasant, are part of the LLM superpower, where they used to be an engineer's downfall. Switching between tasks to get shit done is easier and more effective than ever. Mastering this kind of context-switch might become the most desirable trait in an engineer in years to come.
But it's not all good...
A micro-switch, on the other hand, is a little moment during a single track of work. The most predominant micro-switch today is waiting for your LLM to output something to you. Maybe you have a first iteration of a change ready, but find a few issues, and prompt your agent to clean them up. It'll only take a minute -- not enough time to switch to another full task. This interesting space tends to lie in the work scoped between a deep, heavy project and a tiny one-shot change. These are things complex enough to have to iterate, and not so complex you go heads-down on it for hours. For many of us, this is a huge portion of the work that we do. So, how are we spending this time, and how is that affecting us?
I've taken some time to ask friends and coworkers how they handle these tiny bursts of downtime. The main two answers were "mini tasks" and "nothing work-related". Mini tasks ranged from checking emails, to reviewing tiny PRs, to communicating with stakeholders. Non-work-related activities included staring at a wall, cleaning up the desk, playing a turn in a video game, or petting a dog.
It's rare that you'll continue thinking about the task at hand while you wait. After all, you've already made a decision on how the code should change when you prompted it to your agent. All that's left is execution. So unless you're expertly queueing up each step of development in your brain (kudos), you're switching contexts. And, you're doing so frequently, for short periods of time.
Some of us are spending this time being productive, and others are using it to take time back for themselves (which is always promised and never delivered when technology creates efficiency). What's it doing to us? Can we look to some other activity that notoriously involves frequent, short context switches?
This 2025 research ran an experiment with three groups using short-form video social media. One group was allowed to context-switch (scroll) without any limits, one could do so with limits, and one was a control group which did not participate. The prospective memory, or the cognitive ability to recall intention, was tested periodically via reaction time, word recognition, and memory accuracy. As one could imagine, the group scrolling the most performed the worst on these tests. They were able to conclude that the speed of context switches were more of a cause of reduced cognitive ability, rather than the content itself.
If the issue is the speed of context switching and not content, that must include our work. Sure, the content is probably more intellectually demanding at work compared to on social media, but we're switching between these contexts very rapidly (in fact, it would be interesting to try an experiment recording frequency of window/tab-switching with and without agentic coding...). The informal consensus seems to support the idea:
It’s not only AI. It’s short form content, fast paced life. I can’t seem to be able to concentrate as I used to, get into the zone. I get irritated way more, for example when I can’t code a solution fast enough and the AI is being stupid, I get angry.
It's bleak to think that our career, which is valued for our ability to think, is encouraging practices that reduce our abilities to think.
Perhaps there are workflows that could help alleviate this potential deterioration. But whatever they are, there's a force keeping them at bay: the pressure to deliver at a higher pace. Reasonably, engineers are now expected to deliver more code. The assumption is that an engineer uses agents to code, and is able to macro-switch freely, so they can get a lot more done than the same engineer without an LLM.
You will fall behind on these expectations if you try to intentionally slow yourself down.
There's a few ways around this:
You can set cultural expectations with your team. Maybe one low-mid-complexity ticket per sprint should be done manually to keep skills sharp. Or, advocate for tickets to be pair-programmed with at least two humans to stay focused on a single task for an extended period of time.
We can look at the ordering of our work. Micro-switches are probably the most prevalent in mid-complexity tickets. Low-complexity tickets entail just two or three macro-switches (one-shot prompt, self-review, deploy). Large project tickets will likely have you focused in deep work. Practicing diversity of these ticket types in each sprint could at least ensure not all of your time is effectively spent brainrotting on TikTok.
...but realistically, no matter what we do, we'll be context switching a lot more for the rest of our careers. It's up to the individual to grow that skill while protecting their cognitive abilities. There will be huge challenge in learning which context-switches are worth the cost.
Comments
No comments yet.