Das Prozessmodell einer KI-Softwarefabrik in vier Zoomstufen: vom Kundenwunsch bis zum Betrieb, und an welcher Stelle der Mensch den Takt vorgibt.
Mit Coding-Agenten kostet das Schreiben von Code kaum noch Zeit. Am Software Development Lifecycle (= SDLC = Lebenszyklus der Softwareentwicklung) ändert das mehr, als es auf den ersten Blick scheint: Wenn das Schreiben von Code kaum noch Zeit kostet, wird alles andere zum Engpass. Anforderungen, Entscheidungen, Reviews und Abnahmen laufen weiter im Tempo von Menschen. Wer nur das Coding beschleunigt, verschiebt den Stau also an die nächste Stelle der Kette.
Seit Andrej Karpathy den Begriff Agentic Engineering im Februar 2026 populär gemacht hat1, reden viele über Agenten, die Code schreiben. Über das, was davor und danach passiert, reden deutlich weniger: Woher kommt die Anforderung? Wer trifft die Architekturentscheidung? Und was passiert mit dem, was der Betrieb über die Software lernt?
In diesem Artikel wird das Prozessmodell, nach dem wir bei Storm Reply mit Agenten Software bauen, in vier Zoomstufen skizziert: vom Gesamtkreislauf über den Engineering-Kreis bis hinunter zu den einzelnen Systemen, durch die ein Ticket läuft. Für jede Stufe wird benannt, wer arbeitet: Mensch, Agent oder Automatisierung.
Zoomstufe 1: Drei Kreisläufe statt einer Pipeline
Der Begriff Software Factory ist älter als die meisten Entwickler, die heute mit Agenten arbeiten. Hitachi nannte 1969 als erstes Unternehmen eine Softwareorganisation „Fabrik“ und meinte damit die standardisierte, wiederholbare Produktion von Software mit industriellen Methoden2. Eine Fabrik denkt in Durchläufen. Software dagegen ist nie fertig, deshalb besteht unser Modell auf der obersten Ebene aus drei Kreisläufen, die sich berühren.
Der Kundenkreis beginnt mit Idee und Kickoff und läuft über Workshops und Requirement Engineering zu fachlichen und betrieblichen Anforderungen. An seinem Ende stehen Review, Abnahme und Freigabe, danach Go-Live und Übergabe. Hier sitzen Kunde, Product Lead und Projektmanager am Tisch, und schon hier arbeitet ein Agent mit, etwa indem er Workshop-Ergebnisse strukturiert und nachfragt, wo eine Anforderung noch Interpretationsspielraum lässt.
Der Engineering-Kreis rechts macht aus den Anforderungen ein ausgeliefertes Feature. Er ist das, was die meisten Menschen meinen, wenn sie von einer KI-Softwarefabrik sprechen. Zoomstufe 2 stellt ihn genauer dar.
Der Betriebskreis links übernimmt das neue Release in die Produktionsumgebung, inklusive Einrichtung und Konfiguration. Danach folgen Monitoring und Operations, Optimierung und Reporting sowie Review und Anpassung. Hier arbeiten Betriebsteam, Automatisierung und Agent zusammen.
Entscheidend sind zwei Stellen, an denen sich die Kreise berühren. Die erste ist die graue Zone in der Mitte, die sich Kunde und Entwicklung teilen: Anforderungen gehen hinein, Abnahmen kommen heraus. Die zweite ist die gestrichelte Linie oben, die Lernschleife. Was der Betrieb über die Software lernt, kommt als neue Anforderung zurück in den Kundenkreis.
Zwei Beispiele zeigen die Spannweite. Im einfachen Fall meldet jemand ein Menü-Icon an der falschen Stelle. Der Kundenkreis schrumpft dabei auf einen Satz, der Betriebskreis merkt von der Änderung nichts. Im aufwendigen Fall zeigt das Monitoring zum Beispiel, dass eine Funktion unter Last zu langsam antwortet. Daraus wird über die Lernschleife eine neue Anforderung, die durch alle drei Kreise läuft: Workshop, Architekturentscheidung, Umsetzung, Abnahme, Rollout. Der Weg ist in beiden Fällen derselbe, nur der Umfang ist ein anderer.
Wichtig ist: Eine AI Software Factory ist kein schnellerer Coding-Agent, sondern ein Kreislauf, in dem jeder Schritt einen Verantwortlichen hat.
Zoomstufe 2: Der Engineering-Kreis mit zwei Geschwindigkeiten
Zoomt man in den rechten Kreis hinein, zeigt sich, dass er aus zwei ineinanderliegenden Schleifen besteht, die sehr unterschiedlich schnell laufen.
Die äußere Schleife beginnt mit dem Feature-Set für die Entwicklung, das Kunde und Entwickler gemeinsam festlegen. Es folgen Design- und Architekturentscheidungen, dann das Agentic Coding, danach Test und Evaluation über das gesamte Feature-Set, das Deployment auf die Staging-Umgebung und schließlich Review und Abnahme in der gemeinsamen Zone mit dem Kunden. Diese Schleife ist menschengetaktet. Sie läuft so schnell, wie Menschen Entscheidungen treffen und Ergebnisse abnehmen.
Die innere Schleife, die Agentic Loop (= schnelle Iteration aus Coding, Deployment und Test), läuft zwischen Agentic Coding, dem Deployment auf eine Entwicklungsumgebung und Test und Evaluation des einzelnen Features. Hier arbeiten Agent, Entwickler und Automatisierung, und sie dreht sich in Minuten. Ein Fehler, den hier ein Test oder ein Review-Agent findet, wird behoben, bevor überhaupt ein Mensch auf das Ergebnis schaut.
Der Unterschied zwischen den beiden Schleifen ist der Kern des Modells. Ein Agent darf in der inneren Schleife so oft scheitern, wie er will, weil jeder Fehlversuch nur die Entwicklungsumgebung betrifft und keinen Kunden. Die äußere Schleife dagegen verlässt er nie allein. Henning Teek, der die Architektur unserer Plattform entworfen hat, bringt das auf einen Satz:
„Die menschliche Interaktion mit einer Software Factory sollte so gering wie möglich sein, aber so groß wie nötig, um eine gute Qualität zu bekommen.“
Zoomstufe 3a: Design und Architektur als Entscheidungskaskade
Der Schritt „Design- und Architekturentscheidungen“ sieht in Abbildung 2 aus wie ein Kästchen unter vielen. Vergrößert man ihn, wird daraus eine Kaskade aus vier Entscheidungsarten.
Die Kaskade beginnt bei der fachlichen und betrieblichen Anforderung und läuft über Architekturentscheidungen, technische Entscheidungen, Sicherheitsentscheidungen und Performance-Entscheidungen. Erst an ihrem Ende steht das, womit ein Coding-Agent etwas anfangen kann: technische Anforderungen.
Warum diese Phase menschengetaktet bleibt, steht in der Grafik selbst. Es sind vier verschiedene Arten von Entscheidungen, und in einem echten Projekt haben sie oft vier verschiedene Verantwortliche: den Architekten, das Entwicklungsteam, die Security und den Betrieb. Ein Agent kann jede dieser Entscheidungen vorbereiten, Optionen gegenüberstellen und Widersprüche finden. Treffen muss sie jemand, der für die Folgen geradesteht.
Wie konkret so eine Entscheidung ist, zeigt ein einfaches Beispiel. Eine fachliche Anforderung lautet: Administratoren sollen einen Messenger anbinden können. Die Sicherheitsentscheidung dazu lautet: Das Zugangstoken des Messengers wird nie an den Browser zurückgegeben. Kein Coding-Agent führt diese Regel von sich aus ein, weil sie in keiner fachlichen Anforderung steht. Sie muss in der Kaskade entstehen, bevor die erste Zeile Code geschrieben wird.
Zoomstufe 3b: Agentic Coding, und das Review kommt vor dem Code
Auch der Schritt „Agentic Coding“ ist kein einzelner Arbeitsgang, sondern eine eigene Schleife.
Aus der technischen Anforderung schreibt der Agent zuerst Spezifikation und Implementierungsplan. Dann kommt ein Schritt, den viele Teams überspringen: ein Review durch den Entwickler, bevor eine Zeile Code entsteht. Erst danach implementiert der Agent. Es folgt das Code Review durch Entwickler und Automatisierung. Findet es etwas, geht der Auftrag über die gestrichelte Linie als Nachbesserung zurück an die Implementierung. Ist es zufrieden, wird auf die Entwicklungsumgebung ausgerollt.
Das frühe Review ist der Hebel. Ein Fehler in der Spezifikation kostet im Review fünf Minuten Lesen. Derselbe Fehler im fertigen Code kostet einen kompletten Implementierungslauf, ein Code Review und eine Nachbesserung, und im ungünstigsten Fall merkt ihn niemand, weil der Code sauber aussieht. Deshalb gehören Spezifikation und Plan als eigene Dateien ins Repository, wo sie zusammen mit dem Code geprüft werden, statt als Anlage in einem Chat zu verschwinden.
Zoomstufe 4: Der technische Durchlauf durch fünf Systeme
Auf der untersten Ebene verschwindet die Kreisform. Hier zeigt sich, durch welche Systeme ein einzelnes Ticket tatsächlich läuft.
Die fünf Swimlanes (= Bahnen, je eine pro beteiligtem System) sind Ticketsystem, Source-Code-Repository, Coding-Agent, CI/CD-System und Entwicklungsumgebung. Der Agent holt sich die technische Anforderung aus dem Ticket und den aktuellen Stand aus dem Repository. Daraus entwickelt er zusammen mit dem Entwickler die Spezifikation und den Implementierungsplan. Beides geht als Markdown-Dateien in einen ersten Pull Request, und dort prüft der Entwickler sie. Erst dann schreibt der Agent den Code und öffnet den zweiten Pull Request.
Die CI/CD-Pipeline übernimmt ab hier ohne Menschen: Abhängigkeitsanalyse, dynamische und statische Codeanalyse, Build des Artefakts, Deployment in eine neue Version der Entwicklungsumgebung. Dort testet und validiert der Entwickler. Treten Fehler auf, geht der Weg zurück zur technischen Anforderung im Ticket. Treten keine auf, wird das Ticket automatisch geschlossen.
Ein Detail dieser Grafik halte ich für wichtiger als alle anderen: Der Rückweg bei Fehlern führt ins Ticket und nicht in eine Chat-Sitzung. Damit bleibt das Ticket die eine Stelle, an der steht, was gebaut werden soll und warum der erste Versuch nicht gereicht hat. Wer Fehler im Chat nachbessert, hat nach drei Runden eine funktionierende Software und keine Dokumentation mehr darüber, warum sie so aussieht.
Wo das Modell nicht trägt
Die vier Zoomstufen sind ein Ordnungsschema, keine Stoppuhr. Vor allem die Grenzen zwischen innerer und äußerer Schleife sind in der Praxis nicht trennscharf. Ein kleiner Fehler läuft fast nur durch Zoomstufe 4, die Entscheidungskaskade aus Zoomstufe 3a fällt dabei auf null zusammen. Bei einem neuen Produkt dagegen kann allein die Kaskade Wochen dauern, bevor der erste Agent startet.
Auch die Rollen verschieben sich. Die Symbole in den Grafiken zeigen, wer an einem Schritt arbeitet, nicht, wie viel. Im Requirement Engineering kann ein Agent heute schon einen großen Teil der Nachfragen übernehmen, die Entscheidung über die Anforderung trifft trotzdem der Mensch. Wer das Modell einführt, wird für jeden Schritt neu aushandeln, wo die Grenze liegt, und diese Grenze wird sich mit jedem Modell-Release verschieben. Das bedeutet auch, dass Arbeit sich verlagert: weg vom Schreiben von Code, hin zum Spezifizieren und Prüfen. Wer gerne programmiert, verliert dabei etwas, und das sollte man offen sagen.
Für einen Wegwerf-Prototyp ist das ganze Modell zu schwer. Dort reicht der Agent auf einem isolierten Rechner, und auf die äußere Schleife kann man verzichten. Für Software, die in Produktion geht, gilt das nicht.
Die Empfehlung ist trotzdem klar: von unten nach oben einführen. Zuerst Zoomstufe 4, also Tickets, die Agenten in isolierten Umgebungen starten, und eine Pipeline, die jeden Pull Request prüft. Dann Zoomstufe 3b mit dem Review der Spezifikation vor dem Code. Erst wenn diese beiden tragen, lohnt es sich, Agenten in den Kunden- und den Betriebskreis zu holen.
Wer wissen möchte, wie dieser Weg in der eigenen Organisation aussehen würde, schreibt mir einfach.
