Faster AI Is Fragmenting Your Attention
A practical system for batching AI-assisted work, designing clean handoffs, and running multiple agents without multitasking yourself
Get the guide to build your first AI agent directly in your inbox on newsletter signup:
AI is both a blessing and a curse. A blessing because it removes so much work from our plates that we can focus on the important things. A curse because you can have many open workstreams that require your attention, fragmenting it.
AI context switching is the cognitive cost a developer pays when moving repeatedly between coding, prompting, waiting, and reviewing. AI agents work on different tasks. AI can shorten individual tasks, but every handoff can force the engineer to rebuild a mental model.
The obvious answer would be to run less AI and switch less often. I do not think that is the right answer. AI agents can research, implement, test, and review several tasks at the same time. They help you scale yourself. AI is a force multiplier. Giving up that concurrency would throw away the biggest advantage of it.
The sharper principle is this: to figure out how the Staff and Principal engineers worked before AI.
They are the people who were pulled into many projects but had to code none by themselves. The ones who were involved in many discussions to give some direction and let the teams implement independently.
It’s easy to understand with humans: The Staff engineer would not rapidly jump between one project and another. They would go, involve themselves only in the parts that only they can do, and later let the team implement independently.
Same with AI. AI concurrency does not require human concurrency.
Let’s see in this article how to
manage it.
In this post, you’ll learn
What AI context switching means for software engineers using coding agents
Why faster AI coding workflows create more human handoffs and fragmented attention
How batching AI-assisted engineering work reduces context switching
How to run multiple AI agents without multitasking yourself
How loop engineering helps design AI agent handoffs that protect deep work
AI Makes Tasks Faster, but Your Attention More Fragmented
Before AI agents, many engineering tasks occupied a meaningful block of time. I would spend my entire day on a single bug, including reproducing, root-causing, writing the fix, testing it, etc. There were interruptions, but I had a single task to return to after meetings or other interruptions.
Now one single task produces multiple transitions. I describe the problem in a prompt, then wait for an investigation, then review the plan, then approve the implementation, then inspect the diff, then read the test results, and then answer follow-up questions.
Each step may be faster than doing that step manually. But a given hour is more fragmented than in the past.
The hidden cost is not only the time spent waiting. It’s the number of roles and tasks I move through. In a short period, I can do an investigation, write to delegate work, write code, review, or even be a product owner. Even when every conversation concerns software, each role loads a different question into my head.
The problem gets bigger when the moment the agent starts working, I have to decide if I find something else to occupy the next 30 seconds or not. It gets better if I can hand the agent a long enough piece of work that I can leave intentionally.
Some engineers are already comfortable with this because they have spent years delegating. They know how to assign work, continue with something else, and return at a meaningful checkpoint. The problem is that most AI interfaces make accidental switching easier than deliberate delegation.
I wrote separately about how AI-generated dead zones damage deep work and code review quality:
Batch the Work AI Made Cheap
For years, alternating between different kinds of work made sense to me. I mean alternating between writing code, review a pull request, or answering a message. Each block lasted long enough to create useful variety, and I wasn’t writing 2 different commits at the same time, or switching between two PR reviews. I’d finish one and then start the other.
AI changed the duration of those blocks. If an agent prepares a review in a few minutes, another summarizes a design, and a third investigates a ticket, I suddenly have many more opportunities to switch.
Consider that GitHub is having many outages because the platform was not ready to sustain the increased load of traffic with AI.
Well, I have to tell you that you previous software engineering workflow is not prepared either. It’s having brain-outages. It’s failing.
One fix is batching. I batch work that shares a mental context.
Related pull requests: I review changes in the same subsystem together while its architecture is loaded in my head.
Project communication: I answer decisions and questions for one project in the same block instead of reacting to each notification.
Design decisions: I compare decisions of the same project together because one decision often changes the constraints of the next.
Agent results: I let agents prepare the evidence first, then review completed work in a deliberate queue.
I have been super productive the last month. I raised 2x or 3x the commits of other peers. I was switching between tasks with AI, answering messages from other teams, and reviewing PRs.
But they were all about the same project. I was not juggling between contexts. I was in the same context advancing multiple things.
There is a counterargument here. Doing similar tasks one after another can feel monotonous. The old ordering may have given us variety, and variety can be useful. I still want it, want meaningful blocks of work instead of micro-blocks.
Some time ago, micro-learning got popular. You know what’s better than micro-learning? Sitting for a focused period of time to learn something.
Just remember that we’re not trying to build a perfect calendar. Sometimes you have to do urgent tasks that override your plan.
To me it’s clear. Good batching protects the mental context
Let AI Agents Work in Parallel While You Stay Single-Threaded
Paying attention to several agents is exhausting.
I learned this by doing the obvious thing. I started one agent, opened another task while it worked, launched a second agent, checked the first result for a follow-up prompt, and then returned to the second task without remembering why I had started it.
My brain was acting as a scheduler for incomplete conversations.
Yet I told you earlier that I was super productive starting multiple tasks. How did I do it?
There are three ways I can work with AI agents:
Wait on one prompt: I preserve focus, but the workflow moves only as fast as one conversation.
This is where people end up saying “I’m faster doing it myself”
Fake multitasking: I rotate through half-finished chats and code. I have a high level of frenzy that leaves me exhausted
Async orchestration: Agents advance independently and return completed artifacts to a queue. I keep one human work item in progress.
The third mode is the one I want.
There’s no reason why I wouldn’t want many AI agents advancing many things in parallel.
The point is that I am a manager. I have multiple engineers under my supervision, each working on a separate task, and I am responsible for their code quality.
But I don’t have to be a micromanager. Micromanagers suck.
What I focus on is:
One piece of work from my agents at a time. I review, think, and provide the direction
How to make the process smoother so I’m needed less each time.
A team works great when the manager can be gone, and it continues working. Still, the manager is needed to figure out where the bottleneck is and make things work.
Imagine I have an agent working on an implementation. At the same time, one agent investigates an unfamiliar ticket and records the relevant code paths, constraints, and open questions. Another checks whether feedback on an existing pull request was addressed and returns evidence for each comment. A third implements an already approved plan, runs the tests, and prepares the diff.
I do not follow their conversations. When any of them reach a deliberate switching point, I open the next workspace and find a report waiting for me.
That is not human multitasking. The machines are concurrent. My attention remains sequential.
AI becomes more useful when it can work independently for longer.
Think about the evolution of AI for software engineering
In the early days, AI was an autocomplete. It autocompleted a single word.
Then it was able to autocomplete a function. Later, I was using a chatbot, copy-pasting code between the browser and IDE. The unit of work was the function from a prompt, sometimes going up to an entire file.
Then we got the current AI agents that did changes in many files
Then it got tools, so it was running the build
Now my agents run research, implement the changes, run build and tests, deploy in a staging environment, run tests from the outside, measure some stuff, and give me a report of all the work done.
The unit of work got bigger, so I can provide the initial prompt to the agent and leave it working for a full hour.
The review queue also needs a limit. Ten completed agents waiting for judgment can become another form of overload. But I’m not afraid of leaving my AI agents’ output sitting there for a while until I arrive at that piece of work. I remain sequential.
For the broader system behind parallel agents, persistent task state, reusable procedures, and evidence loops, read my AI setup for software engineers:
Design AI Agent Handoffs That Deserve Your Attention
Asynchronous work becomes useful only when the agent knows what it must produce before returning control.
This is where I’d like to introduce the concept of design for the handoff, which is connected with loop engineering.
Loop engineering is the practice of designing systems that do everything by themselves: find work, prompt agents, observe results, evaluate progress, remember state, and stop when a condition is met. In a previous article, I focused on how one designed process can trigger many agent runs over time.
For context switching, the most important part is the stopping condition.
The handoff is not the agent’s last message. The handoff is something you prepared before prompting
If we don’t design that boundary, the loop stops being a good abstraction, and it causes overhead. If we remain involved one message at a time, we haven’t delegated the work.
A useful handoff has three possible states:
Blocked: The agent explains what prevents progress, what it tried, and what would unblock it.
Needs decision: The agent presents the options, tradeoffs, recommendation, and exact decision required from me.
Done: The agent returns the artifact, verification evidence, remaining risks, and anything it could not prove.
The artifact depends on the kind of loop.
An investigation should return sources, findings, uncertainty, and open questions.
An implementation should return the changed files, important decisions, tests run, and known limitations.
A review should point to the precise location, explain the failure mechanism, and include evidence instead of vague concern.
The loop should do as much closed work as it safely can before the handoff. It should not interrupt the work just to ask “I’ve implemented the function, do you want me to implement the rest of the code?”.
This is the same reason good engineering feedback loops need evaluators. If the loop can’t tell whether progress is real, it will not know when it has completed. Tests, linters, or a structured checklist give the agent a scoreboard before it asks for human judgment.
I am not only telling the agent how to work. I am designing how the work returns to me.
When not to use asynchronous AI work
I keep the loop shorter when I know I need to update my system to complete a task.
For example, I told you earlier I was super productive this month because I was focused on a single project. Any new task is easy for my current system. But if I have to jump into another service, I’d probably iterate with AI in shorter loops because I don’t want to wait for an hour to receive a crappy output from AI. An earlier checkpoint can prevent hours of wasted inference.
If success depends on judgment the agent cannot test, more autonomy only postpones the moment when I find the mistake. The goal is the longest safe loop followed by the smallest useful handoff.
These are the systems I write about in Strategize Your Career: batching work that shares a mental context, defining tasks agents can advance alone, persisting state outside a chat, and reviewing evidence at deliberate handoff points. If you’re tired of AI noise in your day, if you want to improve your judgment instead of fragmenting it, subscribe below.
To see the complete model for recurring agents that verify, remember, stop, and return human control, read Loop Engineering:
Conclusion: Agents Can Run Concurrently, Your Attention Should Stay Sequential
Context switching isn’t new. AI increased the number of opportunities to do it.
That makes this a systems problem, not only a discipline problem. I can close Slack and resist Cmd+Tab, I can remove notifications, but the stronger fix is to design a system that does not require my attention after every agent step.
Batch human work that shares a mental model. Let agents run independent tasks in parallel. Remain single-focused when you review your AI agents’ output.
Try this with one task today.
Agents can run concurrently. Your attention should remain sequential.
If you found value in this post:
❤️ Click the heart to help others find it.
✉️ Subscribe to get the next one in your inbox.
💬 Leave a comment with your biggest takeaway
♻️ Share it with your peers
Today’s article will allow you to move faster through the phases of our system to become productive engineers and get promoted faster
I’m building this system below for paid subscribers. Thanks for your continued support!
🗞️ Other articles people like
If you want to go deeper on turning AI conversations into inspectable work products, read this next:
Stop using AI as a chat box
·Last week, I was fixing a simple bug that looked like one wrong config value.
