Die agentische Engineering-Pipeline für den SDLC

Die meisten Softwareprojekte beginnen in einem System, das es längst gibt. Es wurde vor Jahren entworfen und hat sich seither mit Daten gefüllt, deren Entstehung niemand mehr genau kennt. Dazu kommen Annahmen, die selten so aufgeschrieben sind, wie sie tatsächlich gelten. Solche gewachsenen Systeme, im Fachjargon Brownfield, sind der eigentliche Arbeitsplatz der allermeisten Entwicklerinnen und Entwickler; auf die grüne Wiese kommt kaum jemand. An agentische Werkzeuge werden gerade hier die größten Erwartungen gestellt, und sie liefern hier zugleich besonders oft plausible, aber falsche Ergebnisse.

Ich habe in den vergangenen Monaten eine agentische Engineering-Pipeline für den SDLC ausgearbeitet und in Workshops erprobt. Es ist ein durchgehendes Vorgehen für den Software-Entwicklungszyklus mit Agenten, zugeschnitten auf genau diesen Einsatz. Sie beschreibt, wie ein Team mit Agenten arbeitet, wenn es ein neues Feature in ein bestehendes System bringen will, ohne das Brownfield zu beschädigen. Dieser Text ist der Auftakt einer Serie und nimmt sich die Pipeline als Ganzes vor: warum sie so aussieht, wie sie aussieht, und welche Prinzipien sie stützen. Die folgenden Beiträge gehen dann in die einzelnen Rollen, in die Business-Analyse, ins UX, in die Entwicklung, in den Test und in den Betrieb.

Warum das Brownfield ein eigenes Problem ist

Das DORA-Team von Google Cloud hat im April 2026 einen Bericht zum Return on Investment KI-gestützter Softwareentwicklung vorgelegt, den ich an anderer Stelle ausführlich besprochen habe (Der ROI hängt am Fundament). Eine Zahl daraus ist für dieses Thema die wichtigste. Im Greenfield, also bei neuen Systemen ohne Altlast, beziffert der Bericht die Produktivitätswirkung KI-gestützter Entwicklungswerkzeuge auf 35 bis 40 Prozent. Im Brownfield, im gewachsenen System, sind es rund zehn Prozent. Der Faktor zwischen beiden Welten liegt bei drei bis vier. Für Organisationen, die ihr Geld mit der Pflege bestehender Software verdienen, ist das die zentrale Wirtschaftlichkeitsaussage.

Ein Sprachmodell arbeitet nur mit dem Kontext, den es im Moment der Anfrage bekommt, und der fällt in beiden Welten verschieden aus. Im Greenfield ist er klein und überschaubar. Im Altsystem ist er groß, über viele Orte verstreut, und ein guter Teil davon steht nirgends geschrieben. Ein Teil dieses Wissens steckt in einer Datenbank, deren Spaltennamen aus einer veralteten Fachsprache stammen. Eine Ablauflogik bildet eine längst vergessene regulatorische Auflage ab, ohne das irgendwo zu vermerken. Der Rest existiert nur im Kopf der Kollegin, die das Modul vor Jahren gebaut hat. Ein Agent, der diesen Kontext nicht hat, produziert plausiblen Code, der genau dort falsch ist, wo man es von außen nicht sieht.

Zu diesem wirtschaftlichen Befund kommt ein methodischer. Christopher Potts und Moritz Sudhof von der Stanford University haben in der Arbeit „A paradox of AI fluency" knapp 27.000 reale KI-Dialoge ausgewertet (arXiv:2604.25905). Ihr auffälligstes Ergebnis betrifft die Sichtbarkeit von Fehlern. Bei geübten Anwendern werden 59 Prozent der Fehler im Dialog selbst sichtbar, bei ungeübten nur 12 Prozent. Bei ungeübten Anwenderinnen und Anwendern bleiben demnach 88 Prozent der Fehler im Dialog unsichtbar. Was danach mit diesen Fehlern geschieht, misst die Studie nicht. Für die Arbeit im Brownfield genügt aber schon dieser Befund: Wo der Dialog keine Korrektur auslöst, wandert ein Fehler leichter bis ins produktive System. Ungesteuertes Agentic Coding in einem gewachsenen System geht kurzfristig schneller. Die Schäden, die es dabei anlegt, fallen erst Wochen oder Monate später auf.

Die Pipeline setzt hier an. Sie soll die unsichtbaren Fehler sichtbar machen, bevor sie in das gewachsene System gelangen. Dass der Agent dabei schneller tippt, zählt weniger.

Die Pipeline in einem Bild

Ein Feature wandert durch sechs Phasen, und an den Übergängen zwischen den Rollen steht jeweils ein Prüfpunkt.

Zuerst wird der Kontext bekannt gemacht. Bei einem Bestandssystem heißt das, aus dem vorhandenen Code, aus Tickets, aus alter Dokumentation und aus den Daten herauszuziehen, was über den betroffenen Bereich bekannt ist. In dieser Phase wird nur gelesen, nichts verändert.

Danach exploriert das Team gemeinsam mit dem Agenten. Bevor es über eine Lösung nachdenkt, stellt es Fragen und sucht nach Widersprüchen.

Die Ergebnisse werden als Markdown-Dateien im Repository festgehalten: was gefunden wurde, was offen blieb und wo sich Quellen widersprachen.

Aus diesem Verständnis entsteht eine Struktur: ein Epic, das das Ziel beschreibt, und Tickets, die je ein bis drei Stunden Arbeit umfassen, testbar und nachvollziehbar.

Vor dem Code steht ein Umsetzungsplan, der die Reihenfolge, die Teststrategie, die Risiken und die betroffenen Dateien festlegt.

Zuletzt setzt der Agent den Plan um, Ticket für Ticket, und dokumentiert seinen Fortschritt im Plan, im Epic und in den Tickets selbst.

Der Ablauf ist vertraut. Wer einen klassischen Entwicklungsprozess kennt, erkennt die Stationen wieder. Das Neue steckt in den Regeln, die zwischen den Phasen gelten.

Das Brownfield muss erst lesbar werden

Im Greenfield kann man mit Phase zwei beginnen, weil es nichts gibt, das man vorher lesen müsste. Im Brownfield ist die erste Phase die wichtigste und gleichzeitig die, die am häufigsten unterschlagen wird. Sie heißt Kontext-Extraktion und beantwortet die Frage, was das System an der Stelle, an der wir es ändern wollen, heute tatsächlich tut.

Die Antwort steckt an mehreren Orten, und ein guter Durchlauf liest sie alle. Der Code zeigt, was passiert, aber nicht, warum. Das Warum einer Entscheidung steht in der Versionsgeschichte. Die Tickets verraten, welche Anforderung einmal dahinterstand, oft in einer Sprache, die seither veraltet ist. Und die Daten selbst halten fest, was die Theorie verschweigt: dass ein Feld, das laut Dokumentation immer gefüllt sein müsste, in einem erheblichen Teil der Bestandsdatensätze leer ist, weil sich die Sachbearbeitung über Jahre mit Freitext-Notizen beholfen hat. Ein neues Pflichtfeld, eingeführt ohne diesen Befund, lässt einen großen Teil des Datenbestands an der Regel scheitern.

Ein besonderer Fall der Kontext-Extraktion tritt im Bestandssystem fast immer auf und ist fast nie dokumentiert: Begriffe, die in mehreren Systemen leben. Ein Begriff wie „Partner" oder „Vorgang" kann in dem System, das wir ändern, etwas anderes bedeuten als in dem System nebenan, mit dem es Daten austauscht. Solange diese Beziehung nirgends benannt ist, ist sie ein Risiko für jede Migration und jede Koexistenz zweier Systeme. Die Pipeline verlangt deshalb, dass ein Begriff, der über Systemgrenzen hinweg existiert, im Glossar des Tickets sein Pendant im anderen System bekommt, auch dann, wenn das aktuelle Feature gar keine systemübergreifende Wirkung hat. Wo kein Pendant bekannt ist, steht ein Strich und ein Vermerk als offene Frage. So wird aus einer unsichtbaren Annahme ein geklärter Fakt oder wenigstens eine sichtbare Lücke. Die meisten Bestandssysteme leben dagegen mit der stillen Mehrdeutigkeit.

Diese erste Phase produziert noch keine Lösung und soll es nicht. Ihr Artefakt ist ein Bild des Ist-Zustands, belegt und datiert, mit klar markierten Lücken. Erst auf diesem Bild lässt sich verantwortlich entscheiden, was das neue Feature tun soll.

Erstes Prinzip: Menschen bleiben in Rollen

Eine verbreitete Erzählung verspricht, dass der Agent das ganze Team ersetzt: eine Person, ein Sprachmodell, und alles von der Anforderung bis zum Deployment läuft durch denselben Chat. Das klingt verlockend, weil es billig ist, hält einer näheren Betrachtung aber nicht stand.

Jede Rolle steht für eine eigene Sicht auf dasselbe Feature. Eine Business-Analystin urteilt anders als ein Entwickler, ein Tester schaut anders hin als ein UX-Designer, und der Betrieb stellt Fragen, die in der Entwicklung niemand stellt. Über diese Unterschiede findet ein Team die Fehler, die einer einzelnen Perspektive entgehen. Bündelt man alle Rollen in einer Person und stattet diese Person mit einem Agenten aus, der jede Rolle imitieren kann, bekommt man nur die Imitation der Perspektiven. Die echte Reibung zwischen Menschen, die aus verschiedener Erfahrung heraus unterschiedlich urteilen, entsteht so nicht.

Im gewachsenen System kommt ein zweiter Grund hinzu. Die Constraints eines Brownfield-Systems sind oft Erfahrungswissen, das nirgends im Code steht. Eine erfahrene Architektin erkennt auf den ersten Blick, dass eine Stelle heikel ist, weil sie an einem ähnlichen System schon erlebt hat, was dort schiefgehen kann. Diese Erfahrung hat ein Agent nicht. Er arbeitet mit Trainingsmustern, und die bilden einen Durchschnitt der Welt ab, in dem das Spezifische dieses einen Systems untergeht. Die Übersicht über das gewachsene Ganze, das Gespür dafür, welche Änderung an einer Stelle drei Stellen weiter etwas auslöst, bleibt Sache des Menschen.

Zur Qualität kommt das Recht. Der EU AI Act, die Verordnung (EU) 2024/1689, sieht menschliche Aufsicht insbesondere für Hochrisiko-KI-Systeme vor. Für eine agentische Pipeline folgt daraus keine pauschale gesetzliche Pflicht zur Freigabe jedes einzelnen Outputs. Als Governance-Regel bleibt sie sinnvoll: Jeder bedeutsame Output braucht eine menschliche Freigabe, bevor er angenommen wird. So steht am Ende eine Person mit Namen für eine Auslieferung gerade. Ein Chatverlauf, den niemand mehr rekonstruieren kann, leistet das nicht.

Die Pipeline kennt deshalb feste Rollen, jede mit eigenem Auftrag. Die Business-Analyse klärt, was gebaut werden soll und auf welcher Faktenbasis. UX beschreibt, wie sich das Feature für die Nutzerinnen und Nutzer anfühlt und welche Zustände es kennen muss. Die Entwicklung übersetzt die fachliche Struktur in Code, der Test prüft, ob das gelieferte Verhalten zur Zusage passt, und der Betrieb entscheidet, ob und wie eine Änderung auf die echte Infrastruktur wirken darf. Alle nutzen denselben Agenten, nur eben anders, mit eigenen Fragen und eigenen Grenzen.

Wie verschieden die Rollen auf dasselbe Feature schauen, zeigt ein konkreter Fall. Eine Pflichtangabe soll eingeführt werden, und jede Rolle stellt dazu ihre eigene Frage:

• Die Business-Analyse will wissen, ob die fachliche Plausibilität an der richtigen Stelle erzwungen wird und was mit den Bestandsdaten passiert.
• UX fragt, wie die Sachbearbeiterin merkt, dass eine Pflichtangabe fehlt, und ob die Meldung in Geschäftssprache erklärt, warum.
• Die Entwicklung sucht die Stellen im gewachsenen Code, an denen dieselbe Speicherlogik hängt, und klärt, welche davon mitgeändert werden muss.
• Der Test interessiert sich für den Negativfall, den die fröhliche Lösung gern vergisst: was beim Speichern ohne Pflichtangabe passiert.
• Der Betrieb prüft, ob sich die Änderung zurückrollen lässt, falls das gewachsene System sich anders verhält als erwartet.

Jede dieser Fragen kennt einen anderen Weg, auf dem das Feature scheitern kann, und keine ist überflüssig. Die Serie behandelt jede Rolle einzeln. Die Grundentscheidung bleibt in allen Phasen dieselbe: Jede Rolle gehört einem Menschen, der Agent verstärkt sie nur.

Zweites Prinzip: Jede Phase exploriert, bevor sie festlegt

Die größte Versuchung im agentischen Arbeiten ist der frühe Sprung zur Lösung. Man tippt eine Aufgabe, der Agent antwortet sofort mit Code, und es fühlt sich nach Fortschritt an. Im Brownfield ist dieser Sprung gefährlich, weil die Lösung auf einem Verständnis beruht, das niemand geprüft hat.

Die Pipeline kehrt die Reihenfolge um, sodass jede Phase mit Exploration beginnt. In der Business-Analyse heißt das, ein Quelleninventar aufzubauen: Welche Tickets, Confluence-Seiten, Architecture Decision Records, Runbooks und Altdokumente sagen etwas über den betroffenen Bereich? Jede Quelle bekommt einen Stand mit konkretem Datum, an dem die Aussage galt. Vage Angaben wie „aktuell" oder „neueste Version" reichen dafür nicht, denn eine Confluence-Seite, die seit drei Jahren niemand angefasst hat, sieht im System genauso frisch aus wie eine von gestern, und im gewachsenen System ist das ein Risiko.

Auf das Inventar folgt die eigentliche analytische Arbeit. Jede Aussage wird etikettiert: als belegbarer Fakt, als plausible, aber unbelegte Annahme, als offene Frage oder als Widerspruch zwischen zwei Quellen, die beide Recht zu haben scheinen. Diese Etiketten halten die riskanten Stellen sichtbar, die eine glatte Zusammenfassung verwischt.

Diese Haltung gilt nicht nur in der Analyse. Die Entwicklung liest sich erst in den Code ein, bevor sie schreibt; der Test arbeitet die Akzeptanzkriterien durch, bevor er Szenarien entwirft; der Betrieb stellt eine Hypothese über die Ursache auf, bevor er eine Änderung vorschlägt. Im Werkzeug ist diese lesende Phase verankert: Such- und Lese-Operationen sind frei erlaubt, schreibende und wirkende Operationen brauchen eine Freigabe. Das Gefälle ist gewollt. Lesen soll jederzeit möglich sein, ein verändernder Eingriff eine bewusste, genehmigte Entscheidung.

Exploration ist außerdem iterativ. Eine Phase liefert selten beim ersten Durchlauf ein verlässliches Bild. Man findet einen Widerspruch, geht zurück in die Quellen, klärt ihn, findet dabei eine neue offene Frage. Dieses Hin und Her gehört dazu; so entsteht Verständnis im Brownfield überhaupt erst. Die Pipeline lässt diese Schleifen zu, weil sie ihr Ergebnis in Artefakten festhält, wo es auch nach dem Ende einer Sitzung erhalten bleibt.

Drittes Prinzip: Der Zustand gehört in Artefakte

Ein Sprachmodell hat kein Gedächtnis. Es arbeitet allein mit dem Kontext, den man ihm in diesem einen Moment mitgibt. Was im Chatverlauf weiter oben stand, wirkt nur deshalb noch, weil der Client es bei jedem Aufruf erneut mitschickt, und dieser Verlauf kann mit zunehmender Länge an Wirkung verlieren. Der Effekt wird als Context Rot diskutiert und kann einsetzen, bevor das technische Limit des Kontextfensters erreicht ist. Wird der Projektzustand allein im Chat gehalten, geht er deshalb leicht wieder verloren.

Die Pipeline hält den Zustand deshalb außerhalb des Chats, in versionierten Artefakten. Diese Regel nenne ich den Artefakt-Kontrakt: Was während einer Agent-Sitzung entsteht und nicht in ein dauerhaftes Artefakt überführt wird, gilt als nicht passiert. Als Artefakte dienen Markdown-Dateien im Repository für Kontext, Befunde, Pläne und Testausgaben, Tickets für Zuschnitt, Status und Verantwortlichkeit, freigegebene Spezifikationsseiten für Entscheidungen sowie Pull Requests für Diff, Tests und Review-Entscheidung.

Das hat drei Folgen, die zusammen den Wert ausmachen. Eine neue Sitzung kann auf den Artefakten aufsetzen, ohne die frühere Diskussion zu kennen, was im Brownfield mehr zählt als im Neubau, weil Bestandsarbeit selten an einem Tag fertig wird und oft mehrere Personen sie sich teilen. Ein Epic, ein Plan, ein Befund lassen sich von einem Menschen lesen und bewerten, bevor daraus Code entsteht. Und das Fortschrittsprotokoll dokumentiert, was wann und warum entschieden wurde; diese Spur unterstützt in regulierten Kontexten die Nachweis- und Rechenschaftspflichten.

Ein Artefakt entsteht im Bestandssystem ohne Zusatzaufwand und bleibt verlässlich: die Versionsgeschichte. Was im Repository steht, bindet stärker als jede Erinnerung. Eine Commit-Nachricht hält das Warum einer Änderung fest, die Provenienz einer Zeile lässt sich nachvollziehen, und der Stand vor einem Commit lässt sich gegen den danach vergleichen. Diese Information entsteht beim Arbeiten von selbst und veraltet nicht, anders als eine separat gepflegte Notizdatei, die niemand aktualisiert, wenn sich der Code ändert. Ein Agent, der vor einer Änderung die Historie der betroffenen Datei liest, steht auf festerem Grund als einer, der rät. Deshalb verlangt die Pipeline, Git als verbindliche Quelle der Wahrheit zu nutzen.

Der Compliance-Rahmen, an dem sich die Pipeline orientiert, treibt diese Artefakt-Pflicht weiter. Jedes KI-erzeugte Artefakt wird als KI-erzeugt markiert, mit einer nachvollziehbaren Referenz auf die Operation, die Person und das Modell, das es produziert hat. Das ist die Transparenzanforderung des EU AI Act in der täglichen Praxis: ein konkreter Vermerk an jedem einzelnen Stück generierten Inhalts. Wer später wissen will, ob eine Spezifikation von einer Person geschrieben oder von einem Modell vorgeschlagen und nur durchgewunken wurde, findet die Antwort im Artefakt.

Viertes Prinzip: Jeder Rollenübergang hat ein Quality Gate mit Pflichtartefakten

Der Kern der Pipeline liegt in den Übergängen. Zwischen zwei Rollen wechselt nicht einfach die Arbeit den Besitzer. Es steht ein Prüfpunkt dazwischen, ein Quality Gate, und dieses Gate hat zwei Bestandteile: eine kurze, beantwortbare Frage und ein Artefakt, das die Antwort belegt. Ohne das Artefakt ist die Frage nicht beantwortbar, und ohne eine bejahte Antwort beginnt die nächste Phase nicht.

Dahinter steht die Verschiebung der Fehlerkosten. Ein Fehler, der in der Analyse gefunden wird, kostet eine Korrektur im Text. Derselbe Fehler, der erst im Betrieb auffällt, kostet eine Korrektur im laufenden System, dazu die Suche nach der Ursache und die Wiederherstellung. Je riskanter und wirkungsvoller ein Schritt ist, desto früher braucht er Belege, einen Plan und eine menschliche Entscheidung; die Gates sind die Stelle, an der sie fällt.

Am Ende der Discovery steht die Frage, ob die Quellen solide sind. Sind Lücken und Widersprüche sichtbar gemacht, oder wurde glatt zusammengefasst? Das Pflichtartefakt ist das etikettierte Quelleninventar. Erst wenn ein Mensch bestätigt, dass die Wissensbasis belegt und ehrlich ist, beginnt das Strukturieren.

Bevor ein Ticket in die Umsetzung geht, prüft eine Definition of Ready, ob es klein und testbar ist, mit Akzeptanzkriterien und ausdrücklichen Nicht-Zielen. Diese Prüfung ist im Altsystem besonders streng. Sie verlangt zum Beispiel, dass das Outcome eines Tickets in Nutzersicht formuliert ist und nicht in Systemsicht. „Die Sachbearbeiterin kann einen Schaden auch ohne vollständige Angaben speichern, bekommt aber eine fachliche Meldung" ist ein prüfbares Outcome. „Das System validiert das Schadensfeld" ist keines, weil es sich nicht aus Nutzersicht testen lässt und die Verantwortung für den Erfolg von der Fachseite an die Technik verschiebt. Eine zweite Regel desselben Gates: Keine technische Vorgabe im Anforderungsticket. Architektur, Datenmodell, Framework-Wahl, Spaltennamen erscheinen nicht im fachlichen Ticket, weil eine technische Vorgabe an dieser Stelle die spätere Machbarkeitsprüfung wertlos macht und die häufigste Ursache dafür ist, dass die Entwicklung ein Ticket zurückgibt.

Vor dem ersten Code steht ein Plan-Review. Es prüft die Reihenfolge der Arbeit, die Teststrategie, die Risiken und die betroffenen Dateien. Erst nach diesem Review beginnt der Agent zu schreiben. Das ist zusätzlicher Aufwand. Ein Plan, der vor der Umsetzung geprüft wurde, fängt aber die Fehler ab, die ein Agent sonst über zwanzig Tool-Calls hinweg in den Code einbaut, bevor irgendjemand merkt, dass die Richtung falsch war.

Das Test-Gate fragt, ob die Tests die Akzeptanz abdecken, ob eine bewusste Testlücke dokumentiert ist und ob der Pull Request mit einem Testnachweis bewertet werden kann. Als Beleg zählt hier ein Ergebnis: ein Browser-Test, der das Verhalten ausführt, ein Trace, ein Screenshot. Dass der Agent etwas behauptet, reicht im Gate nicht; gezeigt werden muss, dass es funktioniert.

Am schärfsten ist das Apply-Gate im Betrieb. Es trennt die Diagnose von der Wirkung. Der Agent darf eine Pipeline-Änderung, eine Infrastruktur-als-Code-Anpassung oder eine Monitoring-Regel als Pull Request vorbereiten. Aber die Genehmigung eines Pull Requests ist nicht die Genehmigung des Apply. Rollback, Zeitfenster, verantwortliche Person, Beobachtung und Freigabe werden vor der Wirkung entschieden, und der Start auf der echten Infrastruktur bleibt eine menschliche Aktion, auch wenn der Agent sie technisch ausführen könnte. Die Frage des Gates lautet: Ist die Wirkung reversibel, gibt es einen Rollback und eine Beobachtung, und ist das Apply vom Code-Review getrennt?

Unter diesen menschlichen Gates liegt eine maschinelle Schicht, die niemand händisch durchgehen muss. In einem ausgereiften Aufbau prüfen automatische Kontrollpunkte jeden Pull Request, bevor ein Mensch ihn überhaupt sieht: eine Eingangsprüfung, eine Policy-Prüfung, eine statische Sicherheitsanalyse, eine Erkennung von Prompt Injection, ein Red-Team-Durchlauf, eine Sandbox-Ausführung und ein abschließendes Gate mit Bericht. Diese Kontrollpunkte laufen als deterministische Skripte, und sie laufen bewusst vor den teuren, nichtdeterministischen KI-Stationen. So verbraucht kein Modell Rechenzeit auf offensichtlichem Müll, und das Gating wird beweisbar, weil ein Skript ein nachvollziehbares Ergebnis liefert, während eine Modellantwort das nicht garantiert. Die menschlichen Gates bleiben für die Fragen zuständig, die ein Urteil verlangen. Alles, was sich automatisch prüfen lässt, erledigen davor schon die Skripte, und erst beide Ebenen zusammen ergeben die nötige Kontrolle.

Fünftes Prinzip: Keine Entscheidung verlässt sich auf eine einzige Modellantwort

Ein Sprachmodell ist ein statistischer Apparat. Es gibt das wieder, was in seinen Trainingsdaten häufig vorkam, und sein Ton bleibt dabei gleich sicher, ob das im konkreten Fall stimmt oder nicht. Eine einzelne Modellantwort ist deshalb erst eine Hypothese. Im Brownfield, wo das Spezifische zählt und der Durchschnitt der Trainingswelt oft danebenliegt, wiegt diese Unterscheidung schwer.

Die Pipeline begegnet dem mit einer einfachen Disziplin: Für jede wichtige Entscheidung wird eine zweite und, wo es darauf ankommt, eine dritte Meinung eingeholt, und zwar von einem anderen Modell. Verschiedene Modelle sind auf verschiedenen Daten trainiert, mit eigenen Stärken und blinden Flecken. Kommen zwei unabhängige Modelle zum selben Befund, steigt die Verlässlichkeit. Gehen sie auseinander, weiß der Mensch, dass die Sache nicht eindeutig ist und jemand genauer hinsehen muss. Auch dieser zweite Fall bringt ihn weiter.

In der Analyse lässt sich dieselbe Quelle von mehreren Modellen zusammenfassen und die Ergebnisse vergleichen, um zu sehen, wo sie sich in Quellentreue, Genauigkeit und Annahmen unterscheiden. Im Code-Review prüft einen Patch nicht nur das Modell, das ihn geschrieben hat, sondern auch ein zweites, das ihn nicht kennt und deshalb nicht in die eigene Logik verliebt ist. Bei der Verifikation lässt sich ein Modell ausdrücklich darauf ansetzen, einen Befund anzugreifen und zu widerlegen; was einen ernsthaften Widerlegungsversuch übersteht, steht danach stichhaltiger da.

Dahinter steht Modell-Governance. In einem ausgereiften Setup überlässt man die Modellwahl nicht dem Zufall: Die Modelle werden über abstrakte Stufen angesprochen, von günstig bis Spitzenklasse, mit hinterlegten Budget-Profilen und Routing-Regeln; die Markennamen bleiben außen vor. Wer eine teure Stufe nutzen will, muss das begründen, und bei manchen Entscheidungen kommt eine menschliche Freigabe dazu. So bleibt die Zweit- oder Drittmeinung eine gezielte Maßnahme für die Fälle, in denen das Risiko sie rechtfertigt, statt zum stillen Kostentreiber zu werden. Für eine triviale Umformatierung braucht es keine drei Modelle, bei einer Architekturentscheidung im Brownfield-Kontext sieht das anders aus.

Der zweite Blick erhöht nicht nur die Genauigkeit, er härtet das System auch gegen eine spezifische Schwäche agentischer Aufbauten. Wenn der Kontext, mit dem ein Modell arbeitet, manipulierbar ist, etwa durch eine Prompt Injection in einer gelesenen Datei, dann ist ein zweites Modell mit anderem Verhalten eine zusätzliche Hürde für den Angriff. Ein Verteidigungsmodell, das auf mehreren Ebenen prüft, ist schwerer auszuhebeln als eine einzelne Instanz, die man einmal überlistet.

Sechstes Prinzip: Compliance gehört in jede Phase

In vielen Projekten kommt Compliance zuletzt. Erst wird gebaut, dann wird geprüft, ob das Gebaute den Regeln genügt, und am Ende werden Vermerke nachgetragen. Im agentischen Arbeiten hält diese Reihenfolge nicht mehr, und zwar wegen der Geschwindigkeit. Wenn ein Agent in Minuten produziert, wofür ein Mensch Tage brauchte, ist eine nachgelagerte Prüfung längst überrollt, bevor sie greift. Compliance muss an den Stellen sitzen, an denen die Arbeit ohnehin durchläuft, also in den Phasen und Gates der Pipeline selbst.

Der regulatorische Rahmen für deutsche und europäische Teams umfasst mindestens den EU AI Act und die Datenschutz-Grundverordnung. Der EU AI Act, Verordnung (EU) 2024/1689, folgt einem risikobasierten Ansatz. Je nach Einsatzfall und Risikoklasse entstehen Pflichten zu Transparenz, technischer Dokumentation, Protokollierung, menschlicher Aufsicht und Cybersecurity, insbesondere bei Hochrisiko-KI-Systemen und bestimmten generativen KI-Anwendungen. Die Datenschutz-Grundverordnung, Verordnung (EU) 2016/679, regelt die Verarbeitung personenbezogener Daten und verlangt unter anderem Zweckbindung und Datenminimierung. Daneben müssen Teams interne Sicherheitsvorgaben sowie einschlägige AI-Security-Rahmen berücksichtigen; für generative KI betreffen diese typischerweise Bedrohungsmodellierung, Datenklassifizierung, Modellsicherheit, Prompt-Schutz, Lieferkette und Incident Response.

In die Pipeline übersetzt, ergeben sich daraus konkrete Regeln, die in den Phasen verankert sind. An der Wurzel steht die Datenminimierung: In der Entwicklung gehören personenbezogene Daten nicht in die Artefakte. Beispieldaten in Pflichtartefakten verwenden ausschließlich Platzhalter aus einem Muster-Schema, also keine realen Personennamen, Firmen oder Vorgangsnummern. Workshop-Material, Schulungsexporte und Pull Requests landen schnell in öffentlicheren Kontexten, etwa in einer geteilten Seite, einem Spiegel auf einer Code-Plattform oder einer Präsentation. Wird von Anfang an anonymisiert, erspart das die spätere Suche, bei der ohnehin meist ein Treffer übrig bleibt.

Die Barrierefreiheit wird im Bestandssystem leicht vergessen. In einem reifen Aufbau orientiert sich die Pipeline an den Web Content Accessibility Guidelines in der Stufe AA und an der europäischen Norm EN 301 549, soweit sie für den Einsatzfall einschlägig sind. Ein UX-Zustand, der einen Fehlerfall festhält, beschreibt auch, wie dieser Fehler für eine Person wahrnehmbar wird, die einen Screenreader nutzt. Für bestimmte Produkte und Dienstleistungen gelten solche Anforderungen in der EU seit dem 28. Juni 2025 verbindlich, in Deutschland über das Barrierefreiheitsstärkungsgesetz. Für öffentliche Stellen greifen Barrierefreiheitsanforderungen bereits länger.

Zur Nachvollziehbarkeit gehört, dass jede Aussage in einem Artefakt ihre Quelle mit Datum nennt, jedes KI-erzeugte Stück seinen Erzeuger-Vermerk, und dass der Tokenverbrauch nachvollziehbar bleibt. Diese Spur unterstützt den Audit-Trail, den Regulierung, Rechenschaftspflichten oder interne Governance je nach Einsatzfall verlangen können. In der Pipeline entsteht sie als Nebenprodukt des ohnehin geforderten Artefakt-Kontrakts.

Für Brownfield-Systeme kommt der Bestandsschutz vor Migrationszwang hinzu, den ich für eine der wichtigsten Regeln überhaupt halte. Ein neues Feature migriert oder validiert bestehende Daten nicht automatisch. Neue Pflichten gelten für neu angelegte oder aktiv bearbeitete Datensätze, der Bestand bleibt lesbar und speicherbar. Ohne diese Trennung schleppt man eine Datenmigration als Nebenbedingung in ein Feature-Ticket. Eine Datenmigration ist aber ein Vorhaben für sich, mit eigenen Beteiligten, Risiken und Zeitfenstern; als Nebenpunkt geführt, verfälscht sie den Zuschnitt und blockiert die Übergabe an die Entwicklung. Oft entscheidet gerade diese Regel darüber, wie lange ein Feature im Brownfield braucht.

Wie die Prinzipien zusammenwirken

Die sechs Prinzipien sind keine Liste, aus der man sich die bequemen heraussucht. Sie greifen ineinander, und das in einer bestimmten Reihenfolge.

Eine Übergabe zwischen zwei Personen findet nur an einem Gegenstand statt, den beide lesen, also brauchen die Rollen die Artefakte. Ein Artefakt ohne Prüfpunkt ist nur eine Datei, die niemand verbindlich bewertet hat, weshalb die Artefakte die Gates voraussetzen. Ein Gate wiederum prüft nur das, was eine ehrliche Voruntersuchung an Befunden, Lücken und Widersprüchen geliefert hat. Die Zweit- und Drittmeinung schärft die menschliche Entscheidung an den Rollen, ohne sie zu ersetzen. Und die Compliance hat ohne alle vier kein Material, an dem sie wirken kann.

Das Ergebnis ist eine Artefaktkette, in der jedes Glied vom vorherigen abhängt. Aus einem etikettierten Quelleninventar entsteht ein solides Epic, aus dem Epic Tickets, die eine Definition of Ready bestehen, aus den Tickets ein prüfbarer Plan, aus dem Plan ein Pull Request, der den Test übersteht, und daraus erst ein Apply-Entscheid, der verantwortbar ist. Überspringt ein Team ein Glied, kann es das nächste nicht ehrlich abschließen. Man kann so tun, aber das Auslassen rächt sich dort, wo das System am stärksten beansprucht wird, und das ist im gewachsenen System fast immer die Produktion.

Ein verbreiteter Einwand: Klingt das nicht nach einer Rückkehr zum Wasserfall, nach schwergewichtigem Prozess, nach dem, was die agile Bewegung überwinden wollte? So einfach ist es nicht. Die Pipeline hat Phasen und Übergänge, aber sie ist nicht starr. Innerhalb jeder Phase wird iterativ gearbeitet, mit Schleifen und Selbstkorrekturen. Die Tickets sind klein, ein bis drei Stunden, und durchlaufen die Umsetzung einzeln. Vom klassischen Wasserfall unterscheidet sie die Verbindlichkeit weniger, prüfbarer Artefakte an den richtigen Stellen; auf die Menge der Dokumente kommt es nicht an. Welche agilen Annahmen unter agentischen Werkzeugen weiter gelten und welche ihre Steuerungsfunktion verlieren, habe ich an anderer Stelle behandelt. Hier genügt, dass die Methode genauso viel Iteration vorsieht wie zuvor, nur besser belegte.

Was diese Serie als Nächstes behandelt

Dieser Text hat die Pipeline als Ganzes und ihre Prinzipien beschrieben. Er hat bewusst auf der Ebene des Vorgehens gehalten und die einzelnen Rollen nur gestreift. Jede Rolle bietet genug Substanz für einen eigenen Beitrag, und in der Praxis steckt der Wert im Detail.

Die folgenden Beiträge gehen deshalb in die Tiefe. Die Business-Analyse zeigt, wie aus einem Quelleninventar eine belegte Wissensbasis wird, wie das Etikettieren von Aussagen funktioniert und woran man erkennt, dass eine Discovery reif für die Strukturierung ist. UX nimmt sich vor, wie ein Feature in eigenen Worten beschrieben wird, wie eine Team-Vorlage mit Akzeptanzkriterien und Zuständen entsteht und warum die Beschreibung der Fehlerfälle oft mehr verrät als die der Happy Paths. Die Entwicklung nimmt die Kaskade aus Recherche, Epic, Tickets, Plan und abschließender Umsetzungsschleife auseinander und zeigt, wie ein Agent über viele Schritte hinweg autonom arbeiten kann, ohne die Kontrolle zu verlieren. Der Test handelt davon, wie aus Akzeptanzkriterien Szenarien werden und wie ein Browser-Beleg eine Behauptung ersetzt. Und der Betrieb behandelt die Trennung von Diagnose und Wirkung, das Apply-Gate und die Frage, was ein Agent auf echter Infrastruktur überhaupt vorbereiten darf und wo die Grenze liegt.

Wer die Pipeline ausprobieren will, bevor die Detailbeiträge erscheinen, kann mit einer einzigen Regel anfangen, die alle anderen nach sich zieht: Halte den Zustand in versionierten Artefakten. Schreibe das Quelleninventar, das Epic, den Plan und die Testausgabe in das Repository. Sobald diese Artefakte da sind, stellt sich die Frage nach den Gates fast von selbst, weil ein Artefakt danach verlangt, geprüft zu werden, bevor das nächste darauf aufsetzt. Und sind die Gates erst da, folgt die Frage nach den Rollen, weil eine Prüfung jemanden braucht, der prüft.

Abkürzungen funktionieren im Brownfield nicht, dafür sind diese Systeme zu alt und zu eng mit allem anderen verflochten. Auf die Selbstsicherheit eines einzelnen Modells in einem flüchtigen Chat kann man sich hier nicht verlassen. Die rund zehn Prozent Produktivitätsgewinn, die der DORA-Bericht für Brownfield-Arbeit nennt, sind kein Naturgesetz; sie beschreiben die Größenordnung einer Rechnung unter bestimmten Annahmen. Mit der richtigen Pipeline lässt sich diese Zahl bewegen. Wie weit, weiß ich nicht, und ich werde mich hüten, eine Zahl zu nennen, die ich nicht belegen kann. Was ich aus den Workshops mitnehme, ist die Verschiebung der Arbeit vom schnellen Tippen hin zu den Übergängen, an denen ein Mensch prüft, was der Agent vorgelegt hat. Ob das im eigenen System etwas ändert, zeigt sich erst, wenn man es an einem echten Feature versucht.