Wenn Code nicht mehr der Engpass ist: Der neue Development Lifecycle

Vor ein paar Tagen saß ich in meinen wöchentlichen Office Hours mit dem Cloud-Team einer Bank, mit der ich seit einiger Zeit arbeite. Irgendwann kam die Rede auf eine Lambda-Funktion, die vor einigen Jahren mit höchster Priorität innerhalb einer Woche gebaut wurde. Diese Funktion ist bis heute nicht live, weil sie nie jemand freigegeben hat.

Für mich zeigt diese Geschichte ziemlich gut, dass das Schreiben von Code in regulierten Unternehmen noch nie der einzige und häufig nicht der eigentliche Engpass war. Coding-Agenten machen das gerade noch deutlicher. Wenn die Implementierung schneller wird, verschwinden die offenen Entscheidungen, Zuständigkeiten und Freigaben nicht. Sie bestimmen nur umso sichtbarer, wie schnell aus einer Idee eine nutzbare Lösung wird.

In diesem Post geht es deshalb nicht darum, wie du deinen Agenten schneller Code schreiben lässt, sondern darum, wie du die Arbeit drumherum organisierst. Denn ein schnellerer Implementierungsschritt hilft wenig, wenn davor niemand entscheidet und danach niemand Zeit für das Review hat.

Vom Zwei-Wochen-Sprint zur kurzen Umsetzungsschleife

Der klassische Ablauf mit Sprint Planning, zwei Wochen Implementierung und einem Sprint Review am Ende passt immer weniger zu dem, was ich bei mir und bei Kunden sehe. Stattdessen findet das Planning am Nachmittag statt, anschließend laufen die Agenten, am nächsten Morgen ist Review, und am Nachmittag geht es mit dem nächsten Planning weiter.

Ein Beispiel aus derselben Woche: Wir haben mit einem Kunden in einem Meeting eine Architektur ausdiskutiert, danach das Transkript an Kiro gegeben, und am nächsten Tag war die Implementierung fertig. Das hat nicht deshalb funktioniert, weil der Agent eine vage Idee besonders kreativ ausgelegt hat, sondern weil die wesentlichen Entscheidungen bereits getroffen waren.

Natürlich heißt eine fertige Implementierung noch nicht, dass die Lösung produktionsreif oder freigegeben ist. Aber wenn zwischen einer geklärten Architektur und dem ersten prüfbaren Ergebnis nur noch eine Nacht liegt, lohnt es sich, den Ablauf darauf auszurichten. Die zentrale Planungseinheit ist dann weniger die Menge an Code, die jemand in zwei Wochen schreiben kann, sondern ein überschaubares Ergebnis, das jemand am nächsten Tag tatsächlich prüfen kann.

Vor der Implementierung müssen Entscheidungen stehen

Ein Agent kann fehlende Entscheidungen nicht zuverlässig dadurch ersetzen, dass er einfach weiterarbeitet. Er trifft dann Annahmen, und die kommen spätestens im Review zurück. In einem regulierten Unternehmen kann eine solche Annahme eine zusätzliche Freigabe erfordern oder einen ganzen Lösungsweg unbrauchbar machen.

Vor dem Start sollten deshalb mindestens diese Fragen beantwortet sein:

• Welches Problem lösen wir, und was gehört ausdrücklich nicht zum Umfang?
• Woran erkennen wir, dass das Ergebnis fachlich richtig ist?
• Welche Architektur- und Sicherheitsvorgaben gelten?
• Welche Entscheidungen sind noch offen, und wer darf sie treffen?
• Wer prüft das Ergebnis, und welche Freigaben braucht es vor dem Betrieb?

Das muss kein hundertseitiges Dokument werden. Eine kurze Spec mit klaren Akzeptanzkriterien und dokumentierten Entscheidungen ist oft nützlicher als ein ausführlicher Text, in dem niemand erkennt, welche Punkte verbindlich sind.

Bei offenen Fragen sollte der Agent anhalten oder einen klar abgegrenzten Teil weiterbearbeiten, der nicht von der Antwort abhängt. Ein „mach erst einmal und wir schauen später“ verlagert die Entscheidung nur in einen teureren Zeitpunkt.

Mehrere Agenten machen Aufmerksamkeit zum Engpass

Wer mehrere Agenten parallel betreibt, beantwortet nicht mehr nur Rückfragen zu einer Aufgabe. Er wechselt ständig zwischen verschiedenen Problemen und trifft Entscheidungen, während an anderer Stelle bereits das nächste Ergebnis auf Review wartet.

Ich merke selbst, dass ich nach einer Stunde in diesem Modus so erschöpft sein kann wie früher nach einem ganzen Arbeitstag. Die Agenten nehmen mir das Tippen ab, aber nicht die Verantwortung für die Entscheidungen. Mehr parallele Implementierung ist deshalb nicht automatisch mehr nutzbarer Durchsatz.

Meine Konsequenz daraus ist, die Zahl der gleichzeitig laufenden Aufgaben an meiner Entscheidungs- und Review-Kapazität auszurichten. Wenn drei Ergebnisse auf Prüfung warten, hilft es nicht, fünf weitere Agenten zu starten. Dann wird aus dem Implementierungs-Backlog nur ein Review-Backlog.

Hilfreich ist auch, Rückfragen zu bündeln. Ein Agent sollte erklären, welche Entscheidung er braucht, welche Optionen er sieht und welche Folgen sie haben. Das spart nicht die Entscheidung, aber es reduziert den Aufwand, jedes Mal den gesamten Kontext neu aufzubauen.

Review ist geplante Arbeit, kein Restposten

Wenn eine Implementierung am nächsten Morgen fertig sein kann, muss auch vorher klar sein, wer sie dann prüft. Andernfalls erzeugt das Team schneller Ergebnisse, die liegen bleiben.

Für eine kurze Umsetzungsschleife würde ich drei Arten von Prüfung unterscheiden:

• Automatisierte Prüfung: Tests, statische Analyse und technische Policy-Checks laufen bereits vor dem menschlichen Review.
• Fachliches und technisches Review: Ein zuständiger Mensch prüft, ob die Lösung das richtige Problem löst, zur Architektur passt und sinnvoll betrieben werden kann.
• Freigabe für den Einsatz: Die Organisation entscheidet nach ihren geltenden Regeln, ob und unter welchen Bedingungen die Änderung in die Zielumgebung darf.

Diese Schritte müssen nicht zwingend von drei verschiedenen Personen erledigt werden. Aber sie haben unterschiedliche Zwecke. Ein bestandener Test ist keine fachliche Abnahme, und ein akzeptierter Pull Request ist nicht automatisch eine Betriebsfreigabe.

Gerade in regulierten Unternehmen sollte deshalb schon vor der Implementierung sichtbar sein, welche Nachweise für die Freigabe gebraucht werden. Der Agent kann dann Tests, Dokumentation und Änderungshinweise direkt mitliefern, statt dass jemand sie später zusammensuchen muss.

Ein möglicher Tagesablauf

Für eine ausreichend kleine, geklärte Aufgabe kann die Schleife so aussehen:

1. Am Nachmittag: Problem und Umfang klären, Akzeptanzkriterien festhalten, offene Entscheidungen lösen und einen Reviewer benennen.
2. Danach: Der Agent implementiert in einer abgegrenzten Umgebung und führt die vereinbarten Prüfungen aus. Bei Entscheidungen außerhalb seines Auftrags hält er an.
3. Am nächsten Morgen: Der Reviewer prüft Ergebnis, Tests und Abweichungen von der Spec. Korrekturen gehen mit konkretem Feedback zurück an den Agenten.
4. Nach erfolgreichem Review: Die Änderung durchläuft die erforderlichen Freigaben. Erst danach wird sie veröffentlicht oder ausgerollt.
5. In der nächsten Planung: Das Team nimmt die Erkenntnisse auf und entscheidet über das nächste kleine Ergebnis.

Das ist kein Versprechen, dass jede Aufgabe in einem Tag erledigt ist. Eine ungeklärte Schnittstelle oder eine notwendige Risikoentscheidung wird nicht kleiner, nur weil ein Agent bereitsteht. Der Ablauf macht solche Abhängigkeiten aber früh sichtbar.

Günstigere Implementierung macht Priorisierung wichtiger

Wenn ein Feature deutlich weniger Implementierungsaufwand verursacht, sinkt die Hemmschwelle, es bauen zu lassen. Das bedeutet aber nicht, dass es nichts mehr kostet. Jedes zusätzliche Feature muss verstanden, geprüft, betrieben und irgendwann wieder geändert oder entfernt werden.

Die Frage „Können wir das bauen?“ wird deshalb weniger interessant. Wichtiger wird: „Sollten wir das bauen, und welchen Nutzen erwarten wir davon?“

Gerade wenn Agenten viele kleine Wünsche schnell umsetzen können, braucht es eine bewusste Entscheidung darüber, was nicht umgesetzt wird. Sonst gewinnt das Team zwar Geschwindigkeit beim Schreiben von Code, verliert aber Übersicht über sein Produkt und seine Betriebsverantwortung.

Fazit

Coding-Agenten verkürzen den Weg von einer geklärten Aufgabe zu einer ersten Implementierung. Damit wird die Arbeit vor und nach diesem Schritt wichtiger: Entscheidungen vorbereiten, Verantwortung klären, Review-Kapazität reservieren und Freigaben rechtzeitig einplanen.

Mein Vorschlag ist, diese Arbeitsweise zunächst an einer kleinen Änderung zu testen. Haltet vor dem Start fest, wer entscheidet, wer prüft und was für die Freigabe gebraucht wird. Messt anschließend nicht nur die Implementierungszeit, sondern auch, wie lange das Ergebnis auf Entscheidungen und Reviews gewartet hat.

Wenn der Code nach einer Nacht fertig ist und die Änderung danach drei Wochen liegt, habt ihr den nächsten Engpass gefunden. Genau dort lohnt sich dann die Verbesserung des Prozesses.