Die starke Zunahme der Geschwindigkeit, mit der Software geschrieben wird, ist nicht mehr die einzige Herausforderung für Entwicklungsteams. Da Tools wie Cursor sich von Codevorschlägen innerhalb der Entwicklungsumgebung hin zur Ausführung vollständiger Aufgaben auf Grundlage von Spezifikationen und Tickets entwickeln, könnte das Problem künftig in der Fähigkeit der Organisation liegen, zu bestimmen, was den Bau wert ist, es zu testen, sicher bereitzustellen und anschließend zu betreiben und zu warten.
Darum geht es in Hannah Foxwells Vortrag mit dem Titel „Das Entwicklungsteam neu erfinden“, der sich stärker auf die Auswirkungen des agentischen Programmierens auf Menschen und Prozesse konzentriert als auf die Fähigkeiten der Agenten selbst. Foxwell stützt ihre Argumentation auf drei Grundpfeiler, die ihrer Ansicht nach unabhängig davon wichtig bleiben, wie stark sich die Tools beschleunigen.
Vom Geschwindigkeitsmangel zum Übermaß an Kapazität
Foxwell beschreibt einen Weg, der bei Teams begann, die zweimal jährlich Software veröffentlichten, und über Agile, Cloud Computing, DevOps und Continuous Delivery zu mehreren Bereitstellungen pro Tag führte. Ihrer Ansicht nach beginnt sich das, was einst als fernes Ziel präsentiert wurde – hohe Geschwindigkeit –, in eine Realität zu verwandeln, aus der Organisationen bislang noch nicht wissen, wie sie Nutzen ziehen können.
Im Modell des agentischen Programmierens können Agenten Spezifikationen zerlegen, Code und Tests schreiben und anschließend bei Bereitstellung und Überwachung helfen. Diese Fähigkeit kann jedoch einen gegenläufigen Druck auf das Produktmanagement erzeugen: Entwicklungsteams könnten Arbeit schneller umsetzen, als die Organisation klare und qualifizierte Anforderungen bereitstellen kann. Deshalb sieht Foxwell die Lösung nicht darin, jede Idee oder Anfrage anzunehmen, da dies zu aufgeblähten und wenig fokussierten Produkten führen könnte.
Der erste Grundpfeiler: Das bauen, was den Bau wert ist
Foxwell betont, dass Code nicht das Ziel, sondern ein Mittel zur Lösung eines echten Nutzerproblems ist. Wenn die Kosten für das Testen von Ideen sinken, ist es besser, Prototypen zu erstellen und sie mit Nutzern zu erproben, bevor sie in eine langfristige Verpflichtung innerhalb des Produkts umgewandelt werden.
Zu den im Beitrag vorgestellten Mustern gehört der „Produktmanager, der Prototypen programmiert“, um die Distanz zwischen Idee und Test zu verkürzen, oder die Zusammenarbeit eines Produktmanagers mit einem Entwickler, wenn eine Idee die Möglichkeiten des schnellen Prototypings überschreitet. Außerdem verweist der Beitrag auf die Rolle des Field Engineers, eines Ingenieurs, der in der Nähe des Kunden arbeitet und befugt ist, dessen Probleme zu lösen, sowie auf den „Product Engineer“, der an der Gestaltung des Produkts beteiligt ist, weil er selbst Nutzer ist oder den Nutzern nahesteht.
Foxwell stellt Experimente vor, bei denen die Größe und Zusammensetzung von Teams neu betrachtet werden. Statt des Modells eines Teams aus sechs bis acht Entwicklern und einem Produktmanager erproben einige Organisationen kleinere Teams, während Andrew Ng ein umgekehrtes Modell vorgeschlagen hat, das zwei Produktmanager für einen Entwickler vorsieht, der in der Lage ist, ein ganzes Agentenheer zu koordinieren. Diese Modelle werden nicht als feste Regeln präsentiert, sondern als Experimente, die den Wandel des Engpasses widerspiegeln: weg von der Entwicklungskapazität hin zur Klarheit der Anforderungen und zur Geschwindigkeit von Entscheidungen.
Gleichzeitig warnt der Beitrag vor Praktiken wie dem Ausliefern eines Features und dem sofortigen Wechsel zu einer anderen Aufgabe, ohne seine Nutzung zu überprüfen, dem Annehmen jeder Kundenanfrage oder der Festlegung der Priorität anhand der Meinung der am höchsten bezahlten Person. In einer Umgebung, in der das Schreiben von Software schneller wird, könnten Nutzerforschung, Benutzererfahrung und die Fähigkeit, den Wert zu überprüfen, wichtigere Unterscheidungsmerkmale sein als die Ausführungsgeschwindigkeit selbst.
Der zweite Grundpfeiler: Geschwindigkeit braucht Sicherheit
Die Zunahme des Umfangs von Änderungen erfordert einen Produktionspfad, der mit ihnen Schritt halten kann. Foxwell warnt, dass Lücken bei der Testabdeckung und manuelle Schritte den Bereitstellungspfad zu einem Engpass machen können, sodass sich Änderungen ansammeln, bevor sie die Nutzer erreichen.
Daher verbindet der Beitrag Geschwindigkeit mit automatisierten Tests und verweist auf Beispiele für den Einsatz von Agenten bei der Erstellung kontinuierlicher Tests und bei der Unterstützung von Teams bei der Bewältigung technischer Schulden, der Migration von alten Plattformen und der Umstrukturierung von Codebasen. Die Idee besteht nicht darin, künstliche Intelligenz auf einen langsamen Prozess aufzusetzen, sondern den Weg in die Produktion neu zu konstruieren, damit er die neue Änderungsrate bewältigen kann.
Foxwell betont, dass Zuverlässigkeit und Sicherheit keine akzeptablen Tauschgeschäfte gegen Geschwindigkeit sind. Sie schlägt vor, sich auf Kennzahlen, Service-Level-Ziele und Fehlerbudgets zu stützen, ergänzt durch eine schriftliche Richtlinie, die festlegt, was die Organisation beim Überschreiten des akzeptablen Ausfallniveaus tun wird – etwa Veröffentlichungen zu verlangsamen oder Ressourcen auf Zuverlässigkeit und Resilienz zu lenken.
Außerdem ist sie der Ansicht, dass schrittweise Bereitstellungen, Feature Flags, A/B-Tests und Blue-Green-Deployments dabei helfen, viele Änderungen zu verwalten, ohne sie allen Nutzern gleichzeitig auszusetzen. Sie denkt auch über die Rolle von Site-Reliability-Engineering-Teams und internen Plattformteams neu nach und versteht sie als beratende und befähigende Funktionen, die Entwicklungsteams einen sicheren und gut vorbereiteten Pfad bieten.
Was ändert sich in der Praxis?
Die redaktionelle Schlussfolgerung aus dem Vortrag lautet, dass Agenten allein nicht beweisen, dass Entwicklungsteams kleiner werden oder Arbeitsplätze verschwinden werden. Sicher ist, dass sich die Engpässe verlagern werden: von der Codeproduktion hin zur Auswahl der Probleme, zur Überprüfung des Werts, zur Ausweitung der Tests, zur Steuerung der Zuverlässigkeit und zur schnellen Entscheidungsfindung.
Offen bleibt, ob Organisationen die neuen Möglichkeiten nutzen werden, um bessere Produkte zu bauen und ihre Ideen zu testen, oder ob sie darauf mit dem Aufstapeln weiterer Features reagieren werden. Auch die neuen Verhältnisse zwischen Entwicklern, Produktmanagern, Plattformteams und Zuverlässigkeitsteams sind weiterhin Experimente und keine bewiesenen Ergebnisse. Deshalb erfordert die Einführung des agentischen Programmierens, seine Auswirkungen auf Produktqualität, Vorfälle und Nutzererfahrung zu messen, statt sich lediglich auf die Anzahl der Codezeilen oder die Geschwindigkeit der Veröffentlichungen zu beschränken.