Context Switching Is the Work

For most of my career as a developer, context switching was the enemy.

The productive state was deep focus. You loaded a feature into your head: the shape of the codebase, the files involved, the edge cases, the test suite, the trade-offs behind the existing implementation. Once that map was warm, the best thing anyone could do was leave you alone. A meeting, a Slack thread, a support question, or a second feature would evict part of that mental model. Getting it back was expensive.

This made sense because implementation was the scarce activity. If you were the one writing the code, keeping the full stack of details in short-term memory was the work. You needed to know where to jump, which abstraction to reuse, which tests to run, and what had already been tried. The better you were at staying in that state, the faster you could ship.

Agentic coding changes that equation.

When I work with a coding agent, I still need to understand the feature. I still need to know what good looks like. But once the problem is framed, the next step is often not to type the implementation myself. It is to give the agent the task, let it explore the codebase, make edits, run tests, hit errors, fix them, and report back.

That loop takes time. Sometimes it is five minutes. Sometimes it is thirty. On a large codebase, merely running the relevant tests can take a while. During that time, the human developer is not exactly idle, but they are no longer using the same kind of uninterrupted attention that hand implementation required. They are waiting for a worker to come back with a result.

The obvious response is to start another task.

Then another.

Then the first agent finishes, and you need to switch back. You review the diff, read the transcript, check whether the implementation matches the intent, run or inspect the tests, decide whether the agent got stuck for a real reason or just lost the thread, and either accept the work or send it around again. A few minutes later, another task is ready for review. Then another.

This is the part of software development that feels inverted. The old ideal was to reduce context switching so that one person could implement one thing quickly. The emerging skill is to switch contexts well enough to supervise several implementations in parallel.

That is a different job.

It is not less technical. In some ways it is less forgiving. The agent can write the code, but it cannot be responsible for the product judgment, the boundary of the change, the taste of the abstraction, or the decision that the tests prove the right thing. Those still belong to the engineer. What changes is where the engineer spends most of their time. Less of it is spent pushing characters into files. More of it is spent decomposing work, preserving intent, reviewing results, and deciding what deserves another iteration.

In that world, context switching is no longer merely a tax. It becomes part of the production model.

You can already see tooling move in this direction. Apps such as Conductor, Superset, and Herdr are built around parallel agentic work. They assume that one developer may have several workspaces running at once, each with its own branch, agent session, logs, tests, and review state. They are not optimizing for the old image of a developer staring at one editor buffer until the feature is done. They are optimizing for a developer dispatching work, monitoring progress, and dropping into the right context at the right time.

Git worktrees are a good symbol of the shift. I knew about them for years, but I almost never used them. Why would I? I was rarely implementing multiple features at the same time. With coding agents, worktrees moved from trivia to daily infrastructure. They let each agent have its own clean checkout, its own branch, and its own test runs without trampling the others.

My own workflow has followed the same path, although I have been stubborn about where I want it to live. I spent years shaping Emacs into my working environment: buffers, splits, Magit, LSP, search, navigation, review. When agentic coding arrived, I did not particularly want to replace all of that with a new desktop app. I wanted the parallel-agent workflow inside the editor I already knew.

So I used an agent to build an Emacs version of that idea:

emacs-superset on GitHub

It is essentially a worktree manager with awareness of what my agents are doing: which tasks are running, which ones are waiting for me, and which ones are ready to review. It is not as polished as the venture-backed versions of the same concept, but it fits my hands better because it is integrated with the tools I already use. I still review in Magit. I still move through buffers the way I always have. The difference is that the unit of work is no longer just "the file I am editing"; it is "the set of agent tasks I am supervising".

That distinction matters because the hard part becomes rehydrating context quickly.

When an agent returns after twenty minutes, I need to recover the original intent of the task, understand the route it took, and judge the result without starting from zero. That requires better notes, better task descriptions, smaller scopes, clearer acceptance criteria, and cleaner isolation between parallel efforts. It rewards developers who can make a problem legible before handing it off and then review the answer critically when it comes back.

In other words, the skill is not "let the agent code and stop thinking". It is closer to technical editing, debugging, and project leadership compressed into a single-person workflow.

There are limits to this argument. I am mostly talking about application development, especially the large amount of professional software work that consists of shipping understandable product features against existing systems: CRUD, integrations, UI changes, migrations, internal tools, API endpoints, tests, refactors, and all the unglamorous glue that keeps products moving.

If you are working on a subtle algorithm, a novel database engine, a compiler optimization, a hard distributed-systems problem, or anything where the central work is holding a deep mathematical or conceptual model in your head, the old rules may still apply more strongly. Deep focus is not going away everywhere.

But most developers are not spending most of their days inventing new algorithms. Most of us are moving product software through a long sequence of bounded changes. For that kind of work, agentic coding makes parallelism practical in a way it was not before.

Tomorrow's productive developer may not be the person who can disappear for six hours into a single uninterrupted implementation. It may be the person who can keep five pieces of work moving, switch into each one at the right moment, understand what changed, and make a good call quickly.

I used to hate context switching because it broke the work.

Now it increasingly is the work.