Agentic SDLC: Was Coding-Agenten in jeder Phase des Lebenszyklus ändern

Warum KI in der Softwareentwicklung den ganzen Lebenszyklus betrifft

In den meisten Teams beginnt Softwareentwicklung mit KI im Editor, und dort setzt auch die erste Messung an: Lizenzen, Sessions, Tokens und übernommene Vorschläge. Diese Sicht reicht nicht mehr, sobald Agenten ganze Diffs und Pull Requests liefern. Die Implementierung wird schneller, und vor und hinter ihr staut sich die Arbeit. Aufgaben kommen unterspezifiziert an, während Review, Testpipelines und Release-Prozesse mehr Änderungen erhalten, als sie bewältigen können.

Der DORA-Report 2025 zur KI-gestützten Softwareentwicklung stellt fest, dass der Einsatz von KI den Durchsatz der Software-Delivery inzwischen verbessert, anders als im Vorjahr, die Instabilität der Delivery aber weiterhin erhöht. Der Report sieht KI vor allem als Verstärker, der die vorhandenen Stärken und Schwächen einer Organisation vergrößert. Ein Review- oder Release-Prozess, der schon vorher am Limit lief, zeigt seine Schwächen früher.

AWS betrachtet mit dem AI-Driven Development Life Cycle (AI-DLC), beschrieben im Juli 2025, ebenfalls den ganzen Lebenszyklus. Dort erstellt die KI Pläne, stellt Rückfragen und setzt erst nach menschlicher Validierung um, verteilt auf drei Phasen: Inception, Construction und Operations. Das Team prüft die Vorschläge der KI gemeinsam in Sitzungen, die AWS Mob Elaboration und Mob Construction nennt, Pläne und Designartefakte liegen im Projekt-Repository, und an die Stelle von Sprints treten kürzere Zyklen namens Bolts. Die Open-Source-Workflows der Methode stellen inzwischen eine Initialisierungs- und eine Ideation-Phase voran, laufen in mehreren Coding-Agenten und halten an menschlichen Freigabepunkten an.

Sie brauchen keine benannte Methode, um KI in Ihren Entwicklungsprozess zu bringen. Halten Sie für jede Phase zwei Dinge fest: wie die Arbeit zwischen Agenten und Menschen aufgeteilt ist und welches Artefakt an die nächste Phase geht, samt Verantwortlichem. Das meinen wir mit einem Agentic SDLC oder AI SDLC: der Prozess, den Sie bereits haben, mit ausdrücklich getroffenen Entscheidungen. Das sind die Übergabeartefakte und ihre Verantwortlichen.

• Spezifikation, verantwortet von der Person, die die Aufgabe schreibt
• Plan, verantwortet vom Engineer, der für die Änderung einsteht
• Diff (der Pull Request), verantwortet vom Engineer, der die Aufgabe delegiert hat
• Testbericht, erzeugt von der CI und gelesen von einer benannten Person
• Review-Protokoll, verantwortet vom benannten Reviewer
• Release Notes, verantwortet vom Release-Verantwortlichen
• Incident-Bericht und Folge-Issues, verantwortet vom Service-Team

Von der Anforderung zum Diff: Planung, Design und Implementierung

Probleme, die in den frühen Phasen entstehen, werden später teuer, denn niemand kann einen Diff gegen Anforderungen prüfen, die nie aufgeschrieben wurden. Diese Phasen entscheiden, ob das Ergebnis eines Agenten die Zeit eines Reviewers wert ist.

Anforderungen und Planung

Agenten sind nützlich, bevor jemand Code schreibt. Sie können ein Issue mit der Codebasis und ihrer Historie abgleichen, die betroffenen Module auflisten, die offenen Fragen stellen und Akzeptanzkriterien entwerfen. Was gebaut wird, für wen und wann es fertig ist, entscheiden Menschen. Die Übergabe ist die Spezifikation, und jede Aufgabe sollte so geschnitten sein, dass ein Diff entsteht, den ein Reviewer in einem Durchgang lesen kann.

Design

Bei allem, was eine Modulgrenze überschreitet, lassen Sie den Agenten vor der ersten Änderung einen Plan vorlegen: zu ändernde Dateien, Schnittstellen und Datenstrukturen, Migrationsreihenfolge und wie die Änderung getestet wird. Ein Agent kann auch einen Wegwerf-Prototyp bauen, um eine Designfrage günstig zu klären. Menschen geben Pläne frei, die öffentliche APIs, Datenmodelle, Sicherheitsgrenzen oder den Code eines anderen Teams berühren, und lehnen Pläne ab, die mehr anfassen, als die Aufgabe braucht. Der freigegebene Plan liegt im Repository oder im Pull Request, damit der Reviewer den Diff daran messen kann.

Implementierung

Hier leisten Agenten den größten Teil der Arbeit, und hier zählt der Harness am meisten. Der Agent schreibt die Änderung, führt Build, Lint und Tests aus einem sauberen Checkout aus und arbeitet Fehler ab, während unabhängige Aufgaben parallel in isolierten Arbeitsumgebungen laufen. Der Engineer, der die Aufgabe delegiert hat, bleibt verantwortlich: Er steuert die Session, startet sie neu, wenn sie sich vom Auftrag entfernt, oder übernimmt von Hand. Der Pull Request hält fest, was ausgeführt und was nicht geprüft wurde.

Task       PAY-412  Retry failed webhook deliveries
Spec       docs/specs/PAY-412.md, approved by the task writer
Plan       approved in the pull request before the first edit
Agent      tool, model and harness revision
Ran        lint, unit and integration tests: passing
Not run    load test against the provider sandbox
Risk       retries pile up during a long provider outage
Owner      engineer who delegated the task
Reviewer   named person, merges after CI passes

Spec-Driven DevelopmentHarness Engineering

Vom Diff in die Produktion: Testen, Review, Release und Betrieb

Die späteren Phasen müssen aufnehmen, was die Implementierung liefert. Ihre Kapazität bestimmt stärker als die Geschwindigkeit des Agenten, wie schnell Änderungen bei den Nutzern ankommen.

Testen

Agenten schreiben Tests schnell. Das hilft und ist zugleich das größte Risiko dieser Phase. Ein Test, den derselbe Agent geschrieben hat wie den Code, teilt dessen Lesart der Aufgabe, einschließlich der Missverständnisse. Achten Sie auf aktualisierte Snapshots, gelockerte Assertions und übersprungene Tests, die einen roten Build grün machen. Gut sind Agenten darin, einen gemeldeten Fehler vor dem Fix als fehlschlagenden Test nachzustellen und Code mit Tests abzusichern, den sie gleich ändern werden.

Menschen entscheiden, was getestet werden muss, und halten die entscheidenden Akzeptanztests außerhalb der Reichweite des Agenten. Die Übergabe ist der Testbericht: CI-Ergebnisse, den Akzeptanzkriterien zugeordnet, dazu alles, was von Hand geprüft wurde.

Review

Das Review läuft als erste Phase voll, wenn Agenten Diffs schneller liefern, als Menschen sie lesen können. Ein Agent kann einen ersten Durchgang in frischem Kontext oder mit einem anderen Modell übernehmen, den Diff mit dem Plan und Ihren Konventionen abgleichen und ihn für den Reviewer zusammenfassen. Die Freigabe bleibt bei einem benannten Reviewer, der dafür einsteht, was gemergt wird. Das Review-Protokoll samt Befunden bleibt am Pull Request.

Release

Agenten können Release Notes aus gemergten Pull Requests entwerfen, prüfen, ob Migrationen und Feature Flags zum Plan passen, und die Deployment-Änderung vorbereiten. Wann und für wen ausgerollt wird und ob ein Rollback nötig ist, entscheidet der Release-Verantwortliche im Rahmen Ihres bestehenden Change Managements. Die Übergabe sind die Release Notes: was sich geändert hat, bekannte Risiken und der Rollback-Weg.

Betrieb und Wartung

Im Betrieb beginnen Agenten am besten mit lesender Arbeit: Sie führen während eines Incidents Logs, Traces und die letzten Deployments zusammen und schlagen Fixes als gewöhnliche Pull Requests vor. Wiederkehrende Wartung passt gut zu Agenten, weil Dependency-Updates, Deprecations und kleine Migrationen gleichförmig und überprüfbar sind. Incident-Leitung, Änderungen an der Produktion und die Kommunikation mit Kunden bleiben bei Menschen. Folge-Issues aus dem Incident-Bericht gehen zurück in die Planung.

KI-Code-Review

Fertige Workflows über mehrere Phasen

Manche Teams übernehmen einen fertigen Workflow, statt jede Übergabe selbst zu entwerfen. Ein Beispiel ist pstack, ein Cursor-Plugin von Lauren Tan, veröffentlicht im Repository cursor/plugins unter der MIT-Lizenz. Seine Playbooks decken wiederkehrende Engineering-Arbeit ab, von Untersuchungen und Bugfixes bis zu Features, Refactorings und Performance-Arbeit, und einige bringen Pull Requests durch CI und Review-Kommentare bis zum Merge. Weitere Skills lassen mehrere Modelle gezielt nach Fehlern in einem Diff suchen, und eine beim Setup geschriebene Regel ordnet Rollen wie Coding, Beurteilung und Review jeweils ein Modell zu.

Ein fertiger Workflow bringt eine feste Vorstellung davon mit, wo ein Mensch eingreift. Die Prinzipien in pstack weisen den Agenten an, bei umkehrbarer Arbeit weiterzumachen und vor unumkehrbaren Aktionen zu fragen, und die README zeigt einen nächtlichen Lauf, der einen ganzen Stack von Pull Requests mergt. Ein Schwester-Playbook baut und verifiziert einen Stack und überlässt Review und Merge einem Menschen. Ob ein Merge auf einen Branch, von dem aus deployt wird, als umkehrbar gilt, entscheidet Ihre Organisation.

Playbooks instruieren den Agenten und erzwingen nichts. Wenn wir mit einem Team einen fertigen Workflow einführen, ordnen wir jeden Schritt seiner Phase zu, lassen ihn an Ihren Freigabepunkten anhalten und passen Schritte an, schränken sie ein oder lassen sie weg, wenn sie mehr Autonomie voraussetzen, als Ihr Setup gewährt. Die eingebauten Freigabepunkte der AI-DLC-Workflows helfen ebenfalls, ersetzen Ihre eigenen aber nicht. Freigabepunkte, die halten müssen, gehören in Systeme, die der Agent nicht selbst ändern kann.

• Berechtigungen und Zugangsdaten des Agenten, auf die Aufgabe begrenzt
• Branch Protection und verpflichtende Reviews
• CI-Checks, die einen Merge blockieren, wenn sie fehlschlagen
• Deployment-Freigaben für die Produktion

pstack-Workflows in Ihren Repositoriespstack auf Cursorpstack: Quellcode und README

Rollen, die sich verändern

Stellenbezeichnungen müssen sich selten ändern. Es ändert sich, wofür Menschen ihre Woche verwenden und welche Artefakte sie verantworten.

• Wer Aufgaben schreibt, liefert Briefings, die ein Agent ohne Rückfrage ausführen kann, mit Akzeptanzkriterien und einer Liste dessen, was nicht dazugehört.
• Engineers, die delegieren, verantworten jeden Diff, den sie einem Agenten übergeben, auch die Entscheidung, eine Session neu zu starten oder selbst zu übernehmen.
• Reviewer verbringen mehr Zeit mit Review und brauchen kleine Diffs, den freigegebenen Plan und den Testbericht.
• Das Plattformteam verantwortet den Harness: Anweisungen, Build- und Testbefehle, Berechtigungen, Hooks, Modell-Defaults und Budgets.
• Security- und Release-Verantwortliche legen fest, welche Aufgabentypen unbeaufsichtigt laufen dürfen, und genehmigen Ausnahmen.

Versionieren Sie den Harness mit einem Änderungsprozess, und begrenzen Sie, wie viele Agenten-Pull-Requests auf einen einzelnen Reviewer warten können. Das DORA AI Capabilities Model, ein Begleitdokument zum Report 2025, zählt hochwertige interne Plattformen zu den sieben Fähigkeiten, die die positive Wirkung von KI nachweislich verstärken. Der Harness gehört zu dieser Plattform.

Kennzahlen, die weiterhin taugen

Die Software-Delivery-Kennzahlen von DORA beschreiben weiterhin das Ergebnis. Change Lead Time, Deployment Frequency und Failed Deployment Recovery Time messen den Durchsatz, Change Fail Rate und Deployment Rework Rate die Instabilität. DORA wendet sie auf Ebene einer Anwendung oder eines Services an, und das passt zur Einführung von Agenten: Es geht darum, ob ein Service als Ganzes besser liefert.

Diese Kennzahlen bewegen sich langsam und haben viele Ursachen. Ergänzen Sie Messgrößen, die näher an der Arbeit der Agenten liegen, und erfassen Sie sie je Aufgabentyp.

• Kosten pro akzeptierter Änderung: Modell- und Tool-Kosten eines Aufgabentyps, geteilt durch die Änderungen, die gemergt wurden und gemergt blieben.
• Review-Zeit pro Agenten-Pull-Request, von der Review-Bereitschaft bis zur Freigabe.
• Nacharbeit: Folge-Commits, die eine Agenten-Änderung kurz nach dem Merge korrigieren.
• Reverts und Agenten-Pull-Requests, die ohne Merge geschlossen wurden.
• Zeit für Briefings und Pläne, damit der Aufwand vor der Implementierung sichtbar bleibt.

Berichten Sie nach Team und Aufgabentyp, nie nach einzelnen Engineers. Bugfixes, Refactorings und Dependency-Updates verhalten sich unterschiedlich, und ein Durchschnitt über alle verdeckt, wo Agenten helfen. DORA warnt, dass Kennzahlen, die zum Ziel erklärt werden, dazu verleiten, sie zu schönen, und Einzelbewertungen kosten zusätzlich Vertrauen. Lassen Sie Codezeilen, Annahmequoten von Vorschlägen und die Zahl der Pull Requests weg, denn sie alle können steigen, ohne dass die Delivery besser wird.

LLM-Kostenoptimierung

Governance für unbeaufsichtigte Läufe und Freigaben

Legen Sie Governance je Aufgabentyp fest. Ein Dependency-Update in einem gut getesteten Service und eine Schemamigration in einem Zahlungssystem brauchen unterschiedliche Regeln, auch mit demselben Tool und Modell. Ein unbeaufsichtigter Lauf ist sinnvoll, wenn sich die Aufgabe schriftlich übergeben lässt, die Testsuite selbstständig und ohne Flakiness läuft und ein Mensch jede Änderung vor dem Merge reviewt. Der Lauf selbst braucht auf die Aufgabe begrenzte Berechtigungen, eine isolierte Arbeitsumgebung und eng gefasste Zugangsdaten. Alles, was Produktion, Daten oder Zugriffe verändert, braucht eine benannte Person für die Freigabe, durchgesetzt außerhalb des Agenten.

• Merges in geschützte Branches: ein benannter Reviewer, durchgesetzt über Branch Protection und verpflichtende Reviews.
• Deployments in die Produktion und Rollbacks: der Release-Verantwortliche, über Ihre Deployment-Freigaben.
• Schema- und Datenmigrationen: das verantwortliche Team, mit einem getesteten Rollback-Weg.
• Neue Tools, Modelle, MCP-Server oder Zugangsdaten für Agenten: Plattform- und Security-Team.

Audit-Trail

Halten Sie für jede Änderung fest: das Briefing, den freigegebenen Plan, die Agenten-Konfiguration (Tool, Modell und Harness-Revision), den Testbericht, das Review-Protokoll und wer gemergt hat. Legen Sie das beim Pull Request ab, wo es die Session-Historie jedes Tools überdauert. Unsere Regel lautet: Der Agent schlägt vor, deterministische Checks und Menschen entscheiden. Runmill, das Open-Source-Projekt unseres Gründers, folgt ihr: Über Pushes, Pull Requests und Merges entscheidet deterministischer Code, nie der Agent.

Sicherheit von Coding-AgentenAutonome Software Factory

Einen Agentic SDLC Phase für Phase einführen

Dafür brauchen Sie weder einen neuen Prozess noch eine Reorganisation. Das DORA AI Capabilities Model zählt das Arbeiten in kleinen Batches zu seinen sieben Fähigkeiten, und eine Einführung profitiert von derselben Disziplin.

1. 1

   Eine Phase und einen Aufgabentyp wählen

   Wählen Sie Arbeit mit verlässlichen Tests und kleinem Schadensradius, etwa kleine Bugfixes, Testabdeckung für einen Service oder Dependency-Updates.

2. 2

   Übergaben festhalten

   Benennen Sie das Artefakt, das der Agent erhält, das Artefakt, das er zurückgibt, und wer jeweils verantwortlich ist.

3. 3

   Baseline erheben

   Erfassen Sie die DORA-Kennzahlen des Services sowie Review-Zeit, Nacharbeit und Kosten für diesen Aufgabentyp, bevor sich etwas ändert.

4. 4

   Mit unveränderten Checks starten

   Lassen Sie Review und CI, wie sie sind, und protokollieren Sie für jeden Lauf Tool, Modell und Harness-Revision.

5. 5

   Vergleichen und entscheiden

   Weiten Sie auf den nächsten Aufgabentyp oder eine benachbarte Phase aus, verbessern Sie den Harness oder hören Sie auf. Unbeaufsichtigte Läufe kommen zuletzt.

Wie Cloudsail unterstützt

Wir arbeiten mit jeweils einem Team in dessen eigenen Repositories. Wir sind anbieterunabhängig, und kein Modell- oder Tool-Anbieter bezahlt uns.

• Wir halten Phasen, Übergabeartefakte und Verantwortliche für einen Aufgabentyp fest und weiten dann aus.
• Wir richten Harness und Freigabepunkte ein, versioniert und mit einem Verantwortlichen.
• Wir führen Workshops remote oder vor Ort in Deutschland und Polen durch, auf Englisch, Deutsch oder Polnisch, als Team-Sessions an Ihren Repositories und Ihrem Backlog.
• Wir messen die Wirkung, indem wir gemergte Änderungen gegen zurückgehaltene Tests nachspielen, und berichten die Kosten pro akzeptierter Änderung je Aufgabentyp.

Einführung von Coding-AgentenHarness EngineeringEvaluierungen auf Ihren Repositories