The Missing Middle

For most of my career, the basic shape of software work has been fairly consistent. Somebody defines a piece of work, whether that is a product manager, a business analyst, a tech lead, or a customer who shows up indirectly through a defect or a support case. Eventually that work becomes a ticket, and the ticket usually says something like build this feature, change this behavior, fix this bug, or make this screen do the thing the business needs.

Sometimes the ticket is good, sometimes it is thin, and sometimes it is barely more than a sentence and a screenshot. But even the better tickets usually do not contain all of the real work. They contain intent, and the engineer supplies the missing middle.

That missing middle is where most of the actual software work lives. The engineer has to understand the current system, infer the real requirement, find the owning code, and understand the data model, the deployment path, the testing gaps, the strange edge cases, and the places where the system does not behave the way the diagram says it should. They have to turn a business request into a production change, and that is not just coding. That is mental load.

For a long time, that model made sense. The people defining the work usually did not have the skills, access, or system knowledge required to fill in all of those gaps. Product could describe the business need, leadership could describe the priority, and architecture could describe the general direction, but the engineer still had to make it real.

So the engineer went heads down. They pulled all of the loose pieces into their head and started building the bridge between the ticket and the finished change, which meant they were not just writing code, they were carrying the working model of the system. That is why interruption hurt so much. It was not simply that someone asked a question at the wrong time. It was that the engineer had a fragile, temporary version of the system loaded into their brain, and the organization depended on that being preserved long enough to finish the work. When that mental model gets knocked over, it takes time to rebuild, and we called that context switching. But the deeper problem was that the context was never externalized in the first place.

Leaders Context Switched So Engineers Did Not Have To

This is also why engineering leadership has always been partly about protecting focus. For a long time I managed teams with that idea clearly in mind: the leadership group protects the team's focus, and engineering managers, product managers, tech leads, technical product managers, program managers, and architects all absorb noise so the team can keep moving. That was not just a nice management idea, it was a practical operating model. Leaders context switched so engineers did not have to.

They took the meetings, handled the prioritization arguments, filtered incoming requests, clarified ambiguity, talked to stakeholders, dealt with status reporting, and tried to keep the team from getting pulled into every passing conversation. When it worked well, the team got a protected lane, and that model had real value. It still does.

But it was built around a constraint, which is that the engineer doing the work needed enough uninterrupted time to hold the problem in their head. We built team structures, sprint rituals, management habits, and entire delivery models around the idea that a developer needs focus because the developer is the place where the context finally comes together.

Then AI Changed the Shape of the Work

At first, a lot of engineers treated AI like a better coding assistant. Ask it a question, generate a function, explain an error, write a unit test, refactor a method, translate an API response into a type. That is useful, but it is not the big change.

The bigger change happens when AI stops being a coding helper and starts acting more like a small team. Now the engineer can ask AI to research the codebase, propose an implementation plan, generate tests, compare approaches, write documentation, inspect error output, review a pull request, or walk through a design decision. Sometimes that work happens in one chat, sometimes across several agents or tools, sometimes inside an IDE, and sometimes across tickets, branches, build logs, documentation, and production symptoms.

That changes the role of the engineer. The engineer is no longer only implementing, the engineer is orchestrating. That sounds good, and in many ways it is, but it also explains why so many people feel more scattered when they start using AI heavily. They think they are still doing individual contributor work, just faster, when in reality they are often becoming the manager of a small AI team. That is a very different job.

The Individual Contributor Becomes a Manager

A manager of an AI team has to decide what work to delegate, explain the goal, provide context, review the output, catch bad assumptions, split work into pieces, keep the pieces aligned, and decide when the result is good enough and when it needs another pass. That is orchestration work, and orchestration work is full of context movement. You are moving between the requirement, the code, the test, the agent output, the production behavior, the deployment path, the review comments, and your own judgment about whether any of it is safe.

That is the pain people are feeling. It is not just that AI creates more tabs, chats, prompts, and branches. It is that AI pushes individual contributors into a role that looks a lot more like technical leadership. They are managing the flow of work, not just doing the work.

The uncomfortable part is that many teams have not named this shift yet. They are still teaching people to use AI as if it is only a productivity tool, not teaching them how to orchestrate work, preserve context, or turn vague intent into reusable working material. So the burden lands back on the individual, and the same old problem returns in a new form. Before AI, the engineer had to carry the context because the ticket did not contain enough of it. With AI, the engineer often has to carry the context because the AI workflow does not contain enough of it. That is not progress. That is just moving the pain around.

Why Context Switching Is a Lie

This is why I say context switching is a lie. I do not mean the cost is fake, because the cost is very real. I mean the story is wrong. The story says productivity suffers because people switch topics. The better story says productivity suffers because the system depends on people remembering too much. Those are not the same problem.

In a healthy system, everybody context switches and nobody context switches. That sounds contradictory, but it is not. Everybody moves between topics because real work requires coordination: product has to talk to engineering, engineering has to talk to operations, operations has to talk to support, and developers have to understand requirements, implementation, testing, and production behavior. Nobody gets to live in a cave forever. But nobody should have to carry the whole system in their head either.

The work needs somewhere to live. The requirement should live somewhere, and so should the decision history, the deployment expectations, the rollback plan, the known risks, the test strategy, and the assumptions. That is how you reduce the real cost. You do not reduce it by telling everyone to stop interrupting engineers, although that is still good advice. You reduce it by externalizing the context.

Durable Context Changes the Economics

This is where AI can either make the problem worse or finally give us a path out. If AI is treated as a magic autocomplete engine, it will make the problem worse by creating more output, more half-finished work, more review burden, more branches, more uncertainty, and more hidden assumptions. But if AI is treated as part of a delivery system, the opportunity is much bigger.

Prompt engineering becomes communication, because you learn how to ask for the work clearly. Context engineering becomes requirements engineering, because you make sure the system has the information needed to do the work correctly. Harness engineering becomes delivery discipline, because you build the process that moves the work from idea to implementation to validation to production without relying on memory and heroics. The goal is not to make engineers type faster. The goal is to make the work less dependent on what one person happens to be holding in their head at 2:37 on a Tuesday afternoon.

That is where the old context switching conversation falls short. It keeps focusing on the interruption, but the interruption is only painful because the context is fragile. If the work is well defined, the decisions are captured, the tests are clear, the deployment path is boring, and the AI has the right context available, then switching topics is not free, but it is not catastrophic either. The system can recover because the system remembers.

That is the standard we should be aiming for. Not heroics, not perfect focus, not pretending that people can avoid coordination, and not pushing every messy detail into an engineer's head and then acting surprised when interruption is expensive. The real goal is durable context: context that survives a meeting, a lunch break, a sick day, a handoff, an AI session ending, a different engineer picking up the work, and production asking a question three weeks later.

You Cannot Scale Confusion

AI makes this more urgent because it increases the speed of output, and when output gets faster, weak context becomes more dangerous. Bad assumptions move faster, unclear requirements turn into code faster, and fragile workflows produce more noise faster. You cannot scale confusion. You can only scale the system around the work.

That is the part I think a lot of teams are missing right now. They are trying to adopt AI without changing the operating model, giving engineers powerful tools without changing how work is described, reviewed, validated, or carried forward. So the engineer becomes the bottleneck again, not because they are slow, but because they are the only place where the context exists. That is the same old failure pattern wearing new clothes.

The next version of engineering work has to be different. The engineer still matters, and judgment and experience matter more than ever, but the engineer should not be the only storage layer for the truth of the work. That truth needs to be captured, shaped, tested, and reused. The system is what happens after the code ships, and if the only person who understands the change is the person who made it, the system is already weaker than it looks.

Context switching is not the disease. The disease is building software delivery around fragile human memory. AI gives us a chance to fix that, but only if we stop treating it as a faster keyboard and start treating it as a reason to redesign the way work moves. The future is not engineers going heads down harder. The future is engineers becoming better orchestrators of systems that can carry context with them. That is the real shift, and once you see it, the old context switching conversation starts to feel too small.

Frequently asked questions

What does it mean to say context switching is a lie?

It does not mean the cost of interruption is fake, because that cost is very real. It means the usual story blames the wrong thing. The story says productivity drops because people switch topics. The better explanation is that productivity drops because the system depends on one person holding too much of the working model in their head. Interruption is only expensive because that mental model is fragile, and the real fix is to make the context durable rather than to demand perfect focus.

What is the missing middle in a ticket?

A ticket usually contains intent: build this feature, fix this bug, change this behavior. It rarely contains the real work. The missing middle is everything the engineer has to supply to turn that intent into a production change: understanding the current system, inferring the real requirement, finding the owning code, and working through the data model, the deployment path, the test gaps, and the edge cases. That work has traditionally lived in the engineer's head, which is exactly why interrupting them is so costly.

How does AI change the role of the engineer?

Used lightly, AI is a faster coding assistant. Used heavily, it starts acting like a small team that can research the codebase, propose plans, generate tests, compare approaches, and review code. That turns the engineer from an implementer into an orchestrator who delegates work, provides context, reviews output, and catches bad assumptions. It is a different job, closer to technical leadership, and it is full of context movement, which is why many people feel more scattered rather than less when they adopt AI seriously.

Why do people feel more scattered after adopting AI?

Because they think they are still doing individual contributor work, just faster, when they have actually become the manager of a small AI team. Managing that flow means moving constantly between the requirement, the code, the tests, the agent output, the production behavior, and the review. The old problem returns in new clothes: before AI the engineer carried the context because the ticket did not hold it, and with AI the engineer carries it because the workflow does not hold it. The pain just moved.

What is durable context?

Durable context is context that lives in the system instead of in one person's head. The requirement, the decision history, the deployment expectations, the rollback plan, the known risks, the test strategy, and the assumptions all live somewhere they can be found and reused. Durable context survives a meeting, a lunch break, a sick day, a handoff, an AI session ending, a different engineer picking up the work, and production asking a question three weeks later. It is what changes the economics of software delivery.

Why does AI make externalizing context more urgent?

Because AI increases the speed of output, and when output gets faster, weak context becomes more dangerous. Bad assumptions move faster, unclear requirements turn into code faster, and fragile workflows produce more noise faster. You cannot scale confusion, you can only scale the system around the work. Teams that adopt AI without changing how work is described, reviewed, and validated just make the engineer the bottleneck again, not because they are slow, but because they remain the only place the context actually exists.