How AI Is Changing Software Development Part 1 -
The CTO´s Perspective

The Developer Becomes the Orchestrator

Context switching has long been regarded as one of the biggest productivity killers in software development. This is why companies invest heavily in creating focused blocks of work, minimizing meetings, and keeping teams small with clearly defined responsibilities. In general, the longer a developer can stay focused on a problem, the more productive they are.

But it is about more than just productivity. Good developers know the state often referred to as flow. After a certain amount of time spent getting into a problem, the code itself fades into the background and the problem becomes the primary focus. Connections become clearer, constraints become more apparent, and decisions are often made more intuitively. This is precisely the state that is initially lost with every context switch.

There is another effect that, in my view, is often underestimated. Every context switch increases cognitive load. As a result, we become more likely to rely on mental shortcuts or assumptions instead of rechecking the details. Small inaccuracies accumulate, connections are overlooked, and the likelihood increases that errors will only be discovered later. Context switching therefore costs more than just time. It often comes at the expense of quality as well.

As CPTO at eperi, I am therefore currently exploring how we can mitigate the negative side effects of context switching caused by the use of agents.

Until now, software development has largely followed a linear process: a requirement was analyzed, then implemented and tested. After that came the next task. Of course, there have always been interruptions caused by day-to-day business. At best, however, the majority of working time consisted of focused work on a single problem.

AI is changing the entire working routine, though. Today, a developer may start an implementation, refactoring, or the creation of unit tests and only receive the result several minutes later. During this time, the agent continues working on the task, while the developer can already move on to the next ToDo. This inevitably creates more context switches.

And because more and more of these pauses are emerging, what we use this time for becomes crucial. If a developer starts working on the next feature during this time, they will likely experience exactly the negative effects of context switching that we have known for years: mentally switching between different requirements costs both time and quality. Agentic coding amplifies this problem exponentially.

Unless, that is, the developer remains within the same domain or problem space. In that case, much of the understanding they have already built up is retained. The flow may be interrupted, but it is not completely lost. Switching between implementation, test design, documentation, and architecture of the same feature is fundamentally different from jumping between three unrelated tasks or projects.

We should therefore no longer assess context switching solely by how often a developer switches between tasks. What matters much more is how far the developer mentally moves away from the problem they are actually trying to solve.

In the second part of this series, I will look at how the bottleneck in software development is shifting dramatically as a result of agentic coding. Because when development capacity increases through the use of agents, the supporting functions suddenly become the limiting factor.