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

Warum Entwickler nicht länger das Bottleneck sind

Über viele Jahre hinweg war die Entwicklungskapazität einer der entscheidenden limitierenden Faktoren in Softwareunternehmen. Produktideen waren meist schneller vorhanden als die Zeit, sie umzusetzen. Roadmaps wurden priorisiert, Features verschoben und Kundenwünsche zurückgestellt, weil schlicht nicht genügend Entwicklungskapazität zur Verfügung stand. So weit, so bekannt. Und klar ist auch, dass wir im Begriff sind, dieses Bottleneck zu lösen. Konsequent wird sich das Bottleneck verschieben und dabei spielt es zunächst keine Rolle, ob Agentic Coding die Produktivität eines Entwicklers um 20 % oder 100 % steigert. Sobald Entwicklung schneller wird als der Rest der Organisation, entstehen Engpässe an anderer Stelle. Und damit stehen wir vor der Frage, welche Funktionen innerhalb einer Produktorganisation mit dem zusätzlichen Entwicklungs-Output Schritt halten müssen.

Ganz am Anfang der Wertschöpfungskette steht bekanntlich das Requirements Engineering: Je schneller die Entwicklung wird, desto wichtiger werden ausreichend präzise Anforderungen. Product Owner werden sich in Zukunft dadurch vermutlich stärker auf Produktstrategie, Roadmaps und Priorisierung konzentrieren. Die eigentliche Ausarbeitung einzelner Anforderungen wird dagegen häufiger durch die Entwicklungsteams selbst stattfinden (müssen). Entwickler kennen die Architektur, verstehen die technischen Auswirkungen einer Anforderung und verfügen heute bereits über Werkzeuge, mit denen Spezifikationen, User Stories oder Akzeptanzkriterien vorbereitet werden können. Dadurch verschiebt sich ein Teil der fachlichen Detailarbeit näher an die Entwicklung.

Eine ähnliche Entwicklung sehe ich im Technical Writing: Agenten können heute bereits aus Commits, Pull Requests oder Tickets technische Dokumentation und Release Notes erzeugen. Dadurch verschwindet die Aufgabe des Technischen Redakteurs keineswegs, aber auch sie verändert sich: Statt Inhalte vollständig selbst zu verfassen, wird es künftig häufiger darum gehen, Informationen zu strukturieren, zu validieren und für unterschiedliche Zielgruppen aufzubereiten. Die eigentliche Texterstellung wird zunehmend automatisiert.

Noch deutlicher zeigt sich diese Entwicklung in der Qualitätssicherung: Auch hier unterstützen Agenten bereits heute bei der Erstellung von Testfällen, Testskripten oder automatisierten Regressionstests. Dennoch bleibt die Verantwortung für die Qualität weiterhin bei den menschlichen QA-Engineers. Daher müssen Entwickler ihnen künftig unter die Arme greifen, indem sie beschreiben, welche Bereiche eines Systems durch ihre Änderungen betroffen sind und welche Tests daraus resultieren, quasi als Teil des Hand-overs an die nächste verantwortliche Stelle, denn sonst entsteht dort das nächste Bottleneck. Gerade weil jedes neue Feature mindestens einmal durch einen Menschen verstanden und ausprobiert werden muss, bevor die Effekte einer Automatisierung greifen. Wenn Entwicklung durch Agenten schneller wird, wächst automatisch auch die Menge neuer Funktionalität, die verfügbaren Testkapazitäten wachsen dagegen oft nicht mit.

Für viele Unternehmen wird das organisatorische Konsequenzen haben. Ein möglicher Weg, um diese zu gestalten besteht darin, mehr Testverantwortung wieder in die Entwicklungsteams zu verlagern: Entwickler werden künftig vermutlich einen größeren Teil ihrer Arbeitszeit für Reviews, Testdesign und Testdurchführung aufwenden. Paradoxerweise könnte Agentic Coding also dazu führen, dass Entwickler weniger Zeit mit dem Erstellen von neuen Features verbringen als ursprünglich angenommen, da die hinzugewonnene Zeit durch neue Aufgaben aufgefressen wird. Das gilt es aktiv zu steuern, weshalb wir konkret darüber nachdenken, Entwickler zukünftig mehr in das Design, die Dokumentation, aber auch ins Testen von Features mit einzubeziehen und damit Bottlenecks an anderen Stellen zu vermeiden, ggf. zu dem Preis einer niedrigeren Zufriedenheit mit dem eigenen (Feature-)Output der Entwickler. Die Alternative wäre allerdings, neue Ressourcen im Produktmanagement und der Qualitätssicherung einzustellen, und dafür den Headcount in der Softwareentwicklung zu reduzieren, um kostenneutral bleiben zu können.

Denn die knappe Ressource heißt künftig nicht mehr Entwicklungskapazität, sondern Produktverständnis, Qualitätsbewusstsein und – vor allen Dingen – gute Entscheidungen. Im dritten Teil der Serie möchte ich deshalb einen Schritt weitergehen. Denn wenn mehr Features entstehen als jemals zuvor, stellt sich zwangsläufig die Frage, wie Produkte trotzdem verständlich, wartbar und langfristig erfolgreich – im Sinne des Mehrwerts für die Kunden – bleiben können.

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.