Wie KI die Softwareentwicklung verändert Teil 1 -
The CTO´s Perspective

Der Entwickler wird zum Orchestrierer

Context Switching gilt seit jeher als einer der größten Produktivitätskiller in der Softwareentwicklung. Deshalb tun Unternehmen viel für fokussierte Arbeitsblöcke, möglichst wenige Meetings und kleine Teams mit klaren Verantwortlichkeiten. Je länger ein Entwickler an einem Problem arbeiten kann, desto produktiver ist er in der Regel.

Es geht dabei jedoch um mehr als nur Produktivität: Gute Entwickler kennen den Zustand, den man häufig als Flow bezeichnet. Nach einer gewissen Einarbeitungszeit tritt der eigentliche Code in den Hintergrund und das Problem selbst rückt in den Fokus. Zusammenhänge werden klarer, Randbedingungen fallen auf und Entscheidungen werden häufig intuitiver getroffen. Genau dieser Zustand geht bei jedem Context Switch zunächst wieder verloren.

Hinzu kommt ein zweiter Effekt, der aus meiner Sicht häufig unterschätzt wird. Jeder Context Switch erhöht die kognitive Last. Dadurch wird es wahrscheinlicher, dass wir mit mentalen Abkürzungen oder Annahmen arbeiten, statt Details erneut zu prüfen. Kleine Ungenauigkeiten summieren sich, Zusammenhänge werden übersehen und die Wahrscheinlichkeit steigt, dass Fehler erst später auffallen. Context Switching kostet deshalb nicht nur Zeit. Es kostet häufig auch Qualität.

Als CPTO bei eperi beschäftigt mich daher derzeit die Frage, wie sich die negativen Seiteneffekte von Context Switching, das durch den Einsatz von Agenten entsteht, mitigieren lässt.

Denn bisher verlief Softwareentwicklung überwiegend linear: Eine Anforderung wurde analysiert, anschließend implementiert und getestet. Danach folgte die nächste Aufgabe. Natürlich gab und gibt es Unterbrechungen durch das Tagesgeschäft. Der überwiegende Teil der Arbeitszeit bestand jedoch im besten Fall aus konzentrierter Arbeit an genau einem Problem.

KI verändert jedoch den ganzen Arbeitsalltag: Ein Entwickler startet heute eine Implementierung, ein Refactoring oder die Erstellung von Unit-Tests und erhält das Ergebnis oft erst einige Minuten später. Während dieser Zeit arbeitet der Agent weiter an seinem Task, der Entwickler kann jedoch schon am nächsten ToDo arbeiten, wodurch zwangsläufig mehr Context Switches entstehen.

Und weil immer mehr dieser Pausen entstehen, ist es maßgeblich, wofür diese Zeit genutzt wird. Denn wer in dieser Zeit bereits am nächsten Feature arbeitet, wird vermutlich genau die negativen Effekte von Context Switching erleben, die wir seit Jahren kennen: Der mentale Wechsel zwischen verschiedenen Anforderungen kostet Zeit und Qualität. Und Agentic Coding verstärkt das Problem exponentiell.

Außer der Entwickler bewegt sich innerhalb derselben fachlichen Problemstellung. Denn dann bleibt ein großer Teil des aufgebauten Verständnisses erhalten. Der Flow wird zwar unterbrochen, geht aber nicht vollständig verloren. Zwischen Implementierung, Testdesign, Dokumentation und Architektur desselben Features zu wechseln, ist etwas anderes als zwischen drei unabhängigen Aufgaben oder Projekten zu springen.

Wir sollten daher Context Switching künftig nicht mehr ausschließlich danach bewerten, wie häufig zwischen Aufgaben gewechselt wird. Entscheidend ist vielmehr, wie weit sich der Entwickler gedanklich von seinem eigentlichen Problem entfernt.

Im zweiten Teil dieser Serie geht es um die Beobachtung, dass sich das Bottleneck der Softwareentwicklung durch Agentic Coding drastisch verschiebt. Denn wenn Entwicklungskapazität durch Agenten wächst, werden plötzlich die „supporting functions“ zum limitierenden Faktor.

Hinweis: Aus Gründen der besseren Lesbarkeit wird in diesem Artikel die männliche Form verwendet. Sie schließt selbstverständlich alle Geschlechter gleichermaßen ein.