The Missing Middle

For most of my career, the basic shape of software work has stayed fairly consistent. Somebody defines a piece of work, maybe a product manager, maybe a tech lead, maybe a customer who shows up indirectly through a defect or a support case. Eventually it becomes a ticket, and the ticket says something like 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. Even the better tickets rarely contain the work itself. 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 work out the requirement hiding underneath the wording, find the code that owns the behavior, and figure out how the data model and the deployment path will react to the change, including the places where the system does not behave the way the diagram says it should. Turning a business request into a production change takes a lot more than typing, and all of it sits in one person's head while they do it.

For a long time, that arrangement made sense. The people defining the work usually did not have the access or the system knowledge to fill in those gaps. Product could describe the business need and leadership could describe the priority, but somebody still had to build the thing.

So the engineer went heads down. They pulled the loose pieces together and started building the bridge between the ticket and the finished change, which meant carrying a working model of the system the whole time they were writing code. Interruption hurt because of what it knocked over. The question at the desk was usually easy to answer, but the engineer had a fragile, temporary version of the system loaded into their brain, and the organization depended on it staying loaded long enough to finish the work. When it fell over it took time to rebuild, we called that context switching, and almost nobody asked why the context was only stored in one place.

Leaders Context Switched So Engineers Did Not Have To

For a long time I managed teams with exactly that constraint in mind. The leadership group existed partly to protect the team's focus, so managers, product people, and architects absorbed the noise and the team kept moving. It was a practical operating model, and the short version was that leaders context switched so engineers did not have to.

They took the meetings and the prioritization arguments, filtered the incoming requests, and kept the team out of every passing conversation. When it worked, the team got a protected lane, and I still think that lane is worth protecting.

The whole model was built around one constraint, which is that the engineer doing the work needed enough uninterrupted time to hold the problem in their head. Team structures, sprint rituals, and a lot of management habits grew up around the idea that a developer needs focus because the developer is 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. You ask it to explain an error, write a unit test, or turn an API response into a type. That is useful, and it is also the small version of the change.

The bigger change comes when AI starts acting less like a helper and more like a small team. Now the engineer can ask it to research the codebase, propose a plan, and review a pull request, sometimes in one chat and sometimes spread across several agents, a handful of branches, and whatever the build log said an hour ago.

That moves the engineer's job from implementing to orchestrating. It sounds like good news, and in many ways it is, but it also explains why so many people feel more scattered once they start using AI heavily. They believe they are still doing individual contributor work, only faster, when they have become the manager of a small AI team and nobody told them.

The Individual Contributor Becomes a Manager

A manager of an AI team has to decide what to delegate, explain the goal and the context, and then judge what comes back. Every one of those steps pulls you between the requirement, the code, and the agent's output, and underneath all of it sits your own judgment about whether any of it is safe to ship.

Everyone notices the extra tabs, chats, and branches. The bigger shift is harder to see, because AI pushes individual contributors into a role that looks a lot like technical leadership, where much of the day goes to managing the flow of work instead of doing it.

The uncomfortable part is that most teams have not named this shift yet. They teach people to use AI as a productivity tool and leave out how to orchestrate work or keep context from evaporating between sessions. So the burden lands back on the individual, and the old problem comes back in a new form. Before AI, the engineer carried the context because the ticket did not contain enough of it. With AI, the engineer carries it because the workflow does not contain enough of it, and the pain has moved without getting any smaller.

Why Context Switching Is a Lie

So when I say context switching is a lie, I am talking about the story, since anyone who has lost an afternoon to a string of interruptions knows the cost is not made up. The story says productivity suffers because people switch topics. I think it suffers because the system depends on people remembering too much, and those two diagnoses lead to different fixes.

In a healthy system, everybody context switches and nobody context switches. Everybody moves between topics, because product has to talk to engineering, engineering has to talk to operations, and operations has to talk to support. Nobody gets to live in a cave forever. What nobody should have to do is carry the whole system in their head.

The work needs somewhere to live. The requirement should be written down, and so should the decisions made along the way, the rollback plan, and the assumption everyone agreed to in a meeting that nobody recorded. Telling people to stop interrupting engineers is still good advice, but it only protects the fragile copy in someone's head, when the better fix is to stop keeping the only copy there.

Context That Survives a Sick Day

AI can make this problem worse, or it can finally give us a way out. Treated as a magic autocomplete engine, it makes things worse by producing more output, more half-finished branches, and more hidden assumptions for somebody to review. Treated as part of a delivery system, it gets a lot more interesting.

Prompt engineering starts to look like plain communication, learning to ask for the work clearly. Context engineering is requirements engineering under a new name, since the job is making sure the system has what it needs to do the work correctly. And the harness around the agents, the process that carries a change from idea to validation to production without anyone's memory holding it together, is ordinary delivery discipline. The goal is work that depends less on what one person happens to be holding in their head at 2:37 on a Tuesday afternoon.

The old context switching conversation keeps focusing on the interruption, even though the interruption is only painful because the context is fragile. If the work is well defined, the decisions are captured, and the agent has the right context available, switching topics still costs something, but it stops being catastrophic, because the system can recover when the system remembers.

The standard to aim for is durable context, meaning context that survives a lunch break, a sick day, a handoff, an AI session ending, and production asking a question three weeks after the person who made the change has moved on to something else.

You Cannot Scale Confusion

AI makes this more urgent because it speeds up output, and faster output makes weak context more dangerous. Bad assumptions travel faster, vague requirements turn into code faster, and a fragile workflow produces noise faster than anyone can read it.

You cannot scale confusion.

A lot of teams are missing this right now. They are handing engineers powerful tools without changing how work gets described, reviewed, or carried forward, so the engineer becomes the bottleneck again, and the reason has nothing to do with how fast they are. They are still the only place the context exists.

The next version of engineering work has to be different. Judgment and experience still matter, probably more than before, but the engineer cannot keep being the only storage layer for the truth of the work. The system is what happens after the code ships, and if the only person who understands a change is the person who made it, the system is already weaker than it looks.

What is worth fixing is a delivery process that runs on fragile human memory. AI gives us a chance to fix it, provided we use it as a reason to redesign how work moves and stop thinking of it as a faster keyboard. Get that right, and the next person who leans over a desk with a question costs the engineer a couple of minutes, because the work they were holding is already written down where both of them can find it.