On Lean and Agility

Eine steile These: die immer weiter um sich greifende Integration von KI-Agenten in die Softwareentwicklung führt dazu, dass gerade aus DevOps ein neues Vorgehendmodell entsteht, das zwar grundsätzlich die selben Tätigkeiten und Ideen umfasst, sie allerdings in der Schwerpunktsetzung so stark vertauscht, dass dadurch etwas Neues entsteht. Einen "offiziellen" Namen dafür gibt es noch nicht, naheliegend wäre aber "OpsDev".

Um kurz zu erklären, wie ich zu dieser These komme: unter DevOps verstehe ich nicht nur die Zusammenfassung von Development und Operations in einer Einheit, sondern auch eine dazugehörende Gewichtung. Entwicklung/Development macht darin den Grossteil der Arbeit aus, da sie nicht automatisierbar ist (bzw. bisher war). Damit das so bleiben kann, wird versucht, Betrieb/Operations weitgehend zu automatisieren, entweder durch die Entwickler selbst oder durch Plattform-Teams.

Gleichzeitig wird in DevOps das Releasen, Deployen, Betreiben und ggf. Reparieren der Software einfacher und schneller, da diejenigen die dafür zuständig sind auch die sind, die die Software ursprünglich geschrieben haben. Während reine Operations-Mitarbeiter oft rätseln müssen, warum sich der für sie fremde Code in bestimmter Weise verhält, fällt dem ursprünglichen Erzeuger eine Analyse und Fehlerbehebung meistens leichter.

Im Umfeld von KI-getriebener Softwareentwicklung ist es dagegen auf einmal die Entwicklung, die weitgehend automatisiert ist, oder zumindest teilautomatisiert (je nachdem ob bereits Agentic Development stattfindet oder ob nur gepromptet wird). Für diesen Tätigkeitsbereich den Grossteil der Arbeitszeit freizuhalten ist damit nicht mehr nötig, stattdessen bleibt mehr Zeit für andere Tätigkeiten übrig. Und damit kommen wir zum Betrieb.

Betrieb/Operations kann in der KI-getriebenen Softwareentwicklung auf einmal unerwartet aufwändig werden, da die Entwickler plötzlich vor dem selben Problem stehen wie früher die reinen Operations-Mitarbeiter. Die Anwendungen die deployt, released, betrieben, gewartet und repariert werden müssen, bestehen wieder aus fremdem Code, nur mit dem Unterschied, dass der "fremde Erzeuger" jetzt nicht mehr ein anderer Mensch ist, sondern ein KI Agent, also ein Computerprogramm.

Durch diese beiden Verschiebungen verändern sich auch die Anteile der beiden Tätigkeitsgebiete an der Arbeitszeit. Nicht mehr die Entwicklung steht im Vordergrund und der Betrieb im Hintergrund, sondern umgekehrt: im Vordergrund steht der Betrieb, im Hintergrund die nur noch in Teilen selbst durchgeführte Entwicklung. Und diese Umkehrung kann man auch in der Benennung deutlich machen, daher der Name OpsDev anstelle von DevOps.

Angesichts der Geschwindigkeit und der Tiefgreifenden Natur des aktuellen Umbruchs kann es natürlich sein, dass die These der Bewegung von DevOps zu OpsDev nur eine temporäre Gültigkeit hat und die Situation sich schon bald ganz anders darstellt, für den Moment entspricht sie aber dem, was ich gerade in verschiedenen Firmen wahrnehmen kann. Wenn des diese Seite in ein paar Jahren noch gibt kann ich ja überprüfen, wie die Entwicklung weitergegangen ist.

Einer der spannenden Nebeneffekte des Einzugs von Künstilcher Intelligenz (AI/KI) in die Softwareentwicklung ist, dass auch das methodische Vorgehen sich weiterentwickelt. Ob dabei ein weiteres Vorgehensmodell entstehen wird, das ähnliche Popularität erlangt wie Scrum und SAFe muss sich noch zeigen - es gibt aber einen ersten Kandidaten: Artificial Intelligence-Driven Software Development Lifecycle, oder abgekürzt AI-DLC.

Entwickelt wurde AI-DLC im Herbst 2025 im Developer Transformation Program von Amazon Webservices (AWS). Es wurde aber von Anfang an auch extern veröffentlicht, sowohl im AWS DevOps & Developer Productivity Blog (einschliesslich einer offiziellen Method Definition) als auch ausführlicher im privaten Blog des Programmleiters Dereck Chen (Teil I, Teil II, Teil III, Teil IV). Ein Menge Stoff also, aber wie genau sieht dieses Framework jetzt aus?

Auf den ersten Blick gibt es viele Elemente, die einen bekannten Eindruck machen. Im Mittelpunkt stehen autonome, crossfunktionale Teams aus 3 bis 6 Personen - so genannte Taxi Teams, da sie in ein einziges Taxi passen sollen (eine kleinere Variante von Amazons klassischen Two Pizza-Teams). Fest vorgegebene Rollen in diesem Teams gibt es nicht, empfohlen werden aber Product Manager, Full Stack Developers, QA Engineers und DevOps Engineers, sowie weitere bei Bedarf.

Auch der namensgebende Lifecycle ist in ähnlicher Form bereits bekannt. Es gibt die drei Phasen Inception (Anforderungen erfassen), Construction (die eigentliche Entwicklung) und Operation (Betrieb und Monitoring), die aber nicht nur einmal durchlaufen werden, sondern in sich ständig wiederholenden Iterationen. Diese werden Bolt (sinngemäss "Blitzstrahl") genannt, wodurch klar gemacht wird, dass sie kürzer sind als die klassischen Sprints (nur wenige Stunden oder Tage).

Dass derartig kleine Teams in derartig kurzen Zeiträumen funktionierende Incremente erzeugen, integrieren und betreiben können, liegt schliesslich am Einsatz einer Entwicklungs-KI. In allen drei Phasen erledigt sie den Grossteil der Arbeit, die menschlichen Teammitglieder sind als Human in the Loop nur noch für den initialen Input, die Qualitätssicherung und für Edge Cases zuständig, in denen die KI an Grenzen gerät und Hilfe braucht.

In der konkreten Umsetzung sieht das so aus, dass die KI in der Inception-Phase den Ist-Stand der Systeme, den Entstehungskontext (Architektur, Coding Standards, etc) und die grossen anstehenden Anforderungspakete, die Epics, bereits kennt. Aus einem dieser Epics wird eine mittelgrosse High-Level-Anforderung (eine so genannte Unit) definiert, aus der die KI User Stories und Akzeptanzkriterien erstellt. Die werden vom ganzen Team in einer so genannten Mob Elaboration geprüft und freigegeben.

Die freigegeben (und ggf. vorher nochmal in einer weiteren Verbesserungsschleife angepassten) User Stories werden als nächstes in der Construction-Phase durch die KI umgesetzt, was je nach Umfang unterschiedlich lange dauern kann. Sobald das abgeschlossen ist, erfolgt erneut eine Prüfung und Freigabe durch das gesamte Team, dieses mal unter dem Namen Mob Construction. Das kann nochmal in Unterphasen für Entwicklung und Test unterteilt werden (muss es aber nicht).

Die freigegebenen (und auch hier ggf. in einer weiteren Verbesserungsschleife angepassten) Incremente werden schliesslich durch die KI selbstständig auf Produktion deployt, einschliesslich der dabei durchzuführenden Tests und des anschliessenden Monitorings. Auch Bugs und Incidents werden (soweit möglich) von der KI selbstständig behoben. Der menschliche Anteil besteht hier aus der regelmässigen Kontrolle der dabei entstehenden Metriken und regelmässigen Sicherheits-Audits, Penetrationstests, o.Ä.

Soviel zur Beschreibung, jetzt zur Einordnung. Was auf den ersten Blick auffällt, sind die starken Parallelen zu Extreme Programming, sowohl in Bezug auf übernommene Elemente (iterativ-incrementelle Entwicklung, Epics, User Stories, Akzeptanzkriterien, Mob Programming) als auch in Bezug darauf, was nicht definiert wird (feste Rollen und Meetings, Backlogs, etc.). Selbst wenn es sich selbst nicht so nennt hat AI-DLC damit die Charakteristigen eines agilen Frameworks.

Auf den zweiten Blick fällt auf, dass der angestrebte intensive KI-Einsaz auf mehreren Vorbedingungen beruht. Sowohl das automatisierte Herunterbrechen der Anforderungen als auch das automatisierte Programmieren und Betreiben erfordern aktuelle Daten und Dokumentationen, klare und durchgehend eingehaltene Architektur- und Coding-Standards sowie ein nicht unwesentliches Token-Budget. AWS kann man zutrauen, das zu haben, andere Unternehmen müssten erst umfangreiche Vorarbeiten leisten.

Wenn das gegeben ist, kann man aber von einer deutlichen Beschleunigung der Entwicklungs-Geschwindigkeit ausgehen. AWS selbst nennt als Showcase sein Bedrock-Projekt, das von den ursprünglich geplanten 12 Monaten auf 11 Wochen beschleunigt wurde - mit Sechs Entwicklern, statt der ursprünglich eingeplanten 40. Derartige Dimensionen sind atemberaubend, und selbst wenn in anderen Vorhaben nur ein Teil davon erreicht würde, wäre es viel.

Ein sehr lebhafter und unterhaltsamer Vortrag, den Venkat Subramaniam hier abliefert. Er versucht sich an einem neuen Blick auf das Thema AI, also Artificial Intelligence, und kommt dabei zu einem schönen Backronym: AI bedeutet für ihn Accelerate Inference, also die Beschleunigung von Schlussfolgerungen. Das ist für ihn nicht notwendigerweise etwas Schlechtes, sondern gibt nur Rahmenbedingungen für die Nutzung vor - er rät dazu, AI für die Generierung von Ideen zu nutzen, die Lösungs-Umsetzung aber selbst vorzunehmen, um nicht Kontrolle über Inhalt und Qualität zu verlieren.

Was seine Ausführung unterhaltsam macht sind neben dem Vortragsstil die zahlreichen Analogien, mit denen er seine Ideen erklärt, u.a. mit Bezügen zu Mahatma Ghandi, Franklin D. Roosevelt, Arthur C. Clarke, Henry Ford und Charles Darwin.

In der Softwareentwicklung ist es seit dem eintreten von KI-Anwendungen in den Massenmarkt zu einem geradezu atemberaubenden Innovations und Disruptions-Tempo gekommen - und keiner weiss wo es hinführen wird. Adrian Cockcroft skizziert hier eines der interessanteren Zukunftsszenarien: ein grosser Teil der Jobs wird sich vom Schreiben der Software zu Plattform-Services verlagern, durch die sichergestellt wird, dass KI-generierter Code sicher, verlässlich, verständlich, veränderbar, Archtitektur-Standards entsprechend und Audit-sicher ist.

Was zu den oben genannten Zwecken wichtig wird um die KI-Agenten in die richtige Richtung zu lenken ist für Cockcroft ironischerweise genau das, was vor einem Vierteljahrhundert am Anfang der agilen Bewegung stand: systemisches Denken, Clean Code, einfach verständliche Anforderungen, gute Testabdeckung und kollaboratives Arbeiten - nur dass das es jetzt von Agenten angewendet wird statt von Menschen.

Bild: Pexels / Javier Gonzalez - Lizenz

Der grosse Hype um das Thema Künstliche Intelligenz (KI/AI) ist nicht mehr ganz so ausgeprägt wie er es kurz nach dem Markteintritt von ChatGPT & Co war. Eigentlich gut so, denn jetzt kann man mit etwas nüchternerer Betrachtung bewerten, wo dadurch ein wirklicher Mehrwert erbracht wird. Einer der Bereiche in denen das stattfindet ist das Baugewerbe, und die Technik die hier im Einsatz ist, trägt einen relativ unbekannten Namen: Parametric Design.

Kurz zum Kontext: beim Bauen von Gebäuden kann man anders als beim Maschinen- und Gerätebau nicht mit einem Prototypen beginnen, aus ihm lernen und einen besseren bauen. Was einmal steht lässt sich nur teuer wieder abreissen. Die ersten Ergebnisse (wenn man von Design-Skizzen absieht) bestehen hier daher aus Berechnungen der Statik und der Materialbelastbarkeit der zukünftigen Gebäude. Erst wenn die fertig sind, kann das eigentliche Bauen beginnen.

Da diese Berechnungen aufgrund der zahlreichen Parameter (u.a. Höhe, Breite, Grösse der Innenräume, Material, Untergrund, Wetter) sehr umfangreich sind, führten sie bis ins 21. Jahrhundert fast durchgehend zu langen vorgelagerten Planungsphasen. Waren diese einmal abgeschlossen, war ein nachträgliches Anpassen kaum möglich (und wenn es erzwungen wurde sehr teuer, wie im Fall des Berliner Flughafens). Das Vorgehen war also eher Anti-Agil.

Mit dem Aufkommen von KI-Anwendungen hat sich das geändert, vor allem aufgrund des genannten parametrischen Designs. Bei ihm werden nur bestimmte Rahmenbedingungen (Parameter) fest vorgegeben, etwa Stabilität und zu tragende Last. Das System wird dann angewiesen, unter Respektierung dieser Vorgaben Lösungsvarianten für einen Design-Entwurf zu erstellen. Das kann dann deutlich schneller erfolgen als durch einen Menschen.

Zu Beginn wurde diese Technik vor allem für Gebäudepläne eingesetzt, bei denen eine Berechnung durch Menschen extrem lange gedauert hätte, die aber auch mit KI noch langwierig waren (z.B. bei den Setas de Sevilla von 2011). Mit dem Fortschritt in der KI-Technologie ist das aber noch einmal deutlich beschleunigt worden - bei aktuellen Vorhaben, wie dem West Bund Convention Center in Shanghai, konnte eine komplette Neuberechnung im wahrsten Sinn des Wortes über Nacht erfolgen.

Damit ist agiles Arbeiten jetzt auch in der frühen Planungs- und Berechnungsphase eines Bauvorhabens möglich. In wenigen Tagen können umsetzbare Entwürfe entworfen, berechnet und vorgestellt werden, und das bei Bedarf mehrfach nacheinander oder parallel zueinander. Und wenn dann beim eigentlichen Bauen noch modulare Konstrktion oder 3D-Druck zum Einsatz kommen, kann das Bauen von Gebäuden ähnlich schnell möglich werden wie das von Software.

Über die Folgen des Einsatzes künstlicher Intelligenz in der Softwareentwicklung konnte man in den letzten Jahres einiges lesen, das meiste allerdings mit wenig Realitätsbezug. Das heisst aber nicht, dass es keine sinnvollen Anwendungsfälle gäbe, im Gegenteil. Nach und nach werden sie erkannt, ausprobiert, bewertet und veröffentlicht, so wie in diesem Fall: dem Einsatz von Vibe Coding-Prototypen statt Anforderungsdokumenten bei Google.

At @Google, we are moving from a writing‑first culture to a building‑first one.

Writing was a proxy for clear thinking, optimized for scarce eng resources and long dev cycles - you had to get it right before you built.

Now, when time to vibe-code prototype ≈ time to write PRD,…

— Madhu Guru (@realmadhuguru) July 29, 2025

Zum Kontext: Anforderungsdokumente (oder Product Requirements Documents/PRDs) sind in der Softwareentwicklung bisher ein notwendiges Übel. Sie sind abstrakt, können missverstanden werden und sind aufwändig in der Erstellung und Aktualisierung. Allerdings müssen Anforderungen irgendwo festgehalten werden, Inhalt, Intention und Kontext sind meistens zum umfangreich um ohne derartige Unterstützung im Gedächtnis zu bleiben.

Madhu Garu, der für Gemini zuständige Produktmanager bei Google, beschreibt im oben eingebetteten Post ein alternatives Vorgehen: anstelle eines Anforderungsdokuments präsentiert ein Produktmanager seinem Team einen digitalen Prototypen, also ein noch unfertiges, nicht integriertes und ggf. fehlerhaftes Stück Software, das aber die gewünschte Funktion bereits in einer so guten Form enthält, dass ein Entwicklungsteam sie nachbauen kann.

Dass Produktmanager oft nicht selbst programmieren können wird dabei umgangen, indem der Prototyp durch Vibe Coding erstellt wird, also dadurch, dass er einem KI-Programm beschrieben wird, das ihn dann programmiert (mehr dazu hier). Die Anforderung wird durch den Prototypen deutlich plastischer als durch eine blosse Beschreibung in textform, und (und jetzt wird es interessant) ist im Vergleich zu einem Anfoderungsdokument oft schneller zu erstellen.

Garu geht in den Kommentaren unter seinem Post noch auf weitere Aspekte des Vorgehens bei Google ein: so wird es auch dort nicht überall eingesetzt, bzw. vorgeschrieben, sondern nur dort, wo der Produktmanager es beherrscht und für sinnvoll hält, ob weitere Teams es übernehmen entscheiden sie selbst, Vibe Coding-Prototypen werden nicht auf Produktion deployed und für grössere oder abstraktere Themen ist weiterhin die Schriftform Standard.

Insgesamt eine spannender Erfahrungsbericht von einem Unternehmen, das schon mehrfach bewiesen hat, agile Entwicklungspraktiken zu beherrschen. Sowohl die Art des Einsatzes als auch die Art der Einführung dürften erkennbar dazu beitragen, dass die Kommunikation effektiver, das Feeback schneller und die Lieferzyklen kürzer werden. Eine empfehlenswerte Inspiration also, die man auch im eigenen Unternehmen bei Gelegenheit ausprobieren sollte.