Der agentische Software Development Lifecycle: was sich in der Softwareentwicklung wirklich ändert

Innerhalb von drei Jahren haben sich KI-Systeme in der Softwareentwicklung von der Autovervollständigung über Copiloten zu Agenten entwickelt, die mehrstufige Aufgaben selbstständig planen und abschließen. Damit ändert sich nicht ein einzelner Entwicklungsschritt, sondern das Betriebsmodell der Softwareentwicklung als Ganzes. Mit diesem Beitrag eröffnen wir eine Serie zum agentischen Software Development Lifecycle und beschreiben, was sich wirklich ändert, was bleibt und woran sich der Unterschied zwischen einem Werkzeug und einer neuen Arbeitsteilung erkennen lässt.

Arbeitsteilung statt Werkzeugnutzung

Im agentischen Software Development Lifecycle führen koordinierte KI-Agenten die ausführende Arbeit über alle Phasen aus: von der Anforderungsanalyse über Architektur, Code, Test und Deployment bis zum Betrieb. Menschen definieren das Ziel, treffen Entscheidungen, prüfen Ergebnisse und verantworten jede Freigabe. Das ist der Kern der Veränderung, und er lässt sich in einem Satz fassen:

Der Mensch verantwortet das Warum, Agenten übernehmen das Wie.

Der Unterschied zum Copiloten ist dabei strukturell, nicht graduell. Ein Copilot assistiert einer Person bei einem Arbeitsschritt; jeder Vorschlag wird einzeln geprüft und übernommen oder verworfen. Ein Agent übernimmt ganze Aufträge gegen definierte Qualitätskriterien: Er plant Teilschritte, erzeugt Code und Tests, prüft sich gegen die Spezifikation und übergibt ein verifiziertes Ergebnis an ein menschliches Gate. Erst diese Stufe verändert Kostenstruktur und Durchlaufzeit einer Delivery-Organisation, und erst sie erfordert ein neues Betriebsmodell.

Dass diese Stufe erreicht ist, zeigt die Messreihe von Kwa et al. (2025, arXiv:2503.14499): Die Länge der Aufgaben, die KI-Agenten mit 50-prozentiger Erfolgsquote autonom abschließen, verdoppelt sich derzeit etwa alle sieben Monate. Grob gesprochen waren das 2023 einzelne Funktionen, 2024 abgegrenzte Tickets und Tests, 2025 reale Issues end-to-end von der Analyse bis zum Pull Request. Wer dieses Jahr beginnt, baut eine Reife auf, die sich nicht kaufen lässt: Werkzeuge sind jederzeit verfügbar, verifizierte Spezifikationen, ein belastbarer Wissensgraph und eine geübte Organisation entstehen nur im Betrieb.

Sechs Reifegrade und ein Kipppunkt

Um den Weg messbar zu machen, arbeiten wir mit einem Reifegradmodell in sechs Stufen, angelehnt an das Capability Maturity Model (Paulk et al. 1993) und die Delivery-Forschung von DORA (DevOps Research and Assessment; Forsgren, Humble, Kim 2018):

• L0 Manuell: individuelle Heldentaten, undokumentierte Prozesse, keine belastbare Messung.
• L1 Digital: Versionskontrolle und Tickets, manuell deployt; Leitkennzahl ist die Velocity je Team.
• L2 Automatisiert: DevOps-Baseline mit CI/CD und Testautomatisierung; die Menschen bauen und betreiben die Pipeline.
• L3 LLM-gestützt: Copiloten assistieren im Entwickleralltag; der Mensch prüft jeden einzelnen Output, gemessen wird die Akzeptanzrate der Vorschläge.
• L4 Agent-unterstützt: Agenten führen mehrstufige Aufträge end-to-end aus; der Mensch hält die kritischen Gates und verantwortet Freigaben; Leitkennzahl ist die Zykluszeit je Auftrag.
• L5 Agentisch: ein orchestriertes Agentenökosystem über den ganzen Lebenszyklus; Menschen steuern Intent, Architektur und Verantwortung; gemessen wird der Durchsatz je Vollzeitkraft bei stabiler Qualität.

Die meisten Großorganisationen stehen heute auf der DevOps-Baseline (L2), mit LLM-Inseln in einzelnen Teams (L3): Copilot-Lizenzen sind verteilt, doch Prozesse, Qualitätssicherung und Governance sind unverändert. Die Folge ist ein bekanntes Muster: lokale Zeitgewinne einzelner Entwicklerinnen und Entwickler, aber keine messbare Veränderung von Durchlaufzeit, Qualität oder Kosten auf Portfolioebene.

Der Kipppunkt liegt zwischen L3 und L4. Bis L3 genügen Lizenzen und Schulungen; ab L4 tragen Organisation, Qualitätssicherung und Governance die Veränderung. Genau deshalb bleiben Copilot-Programme ohne Arbeit am Betriebsmodell in Pilotinseln stecken, und genau dort entscheidet sich, wer die Produktivitätssprünge realisiert. Ich halte diesen Kipppunkt für die wichtigste Einsicht der letzten drei Jahre: Die Frage ist nicht, welches Modell eine Organisation lizenziert, sondern ob sie bereit ist, Prozesse, Prüfung und Verantwortung neu zu ordnen.

Vier Verschiebungen, die das Betriebsmodell verändern

Code wird erneuerbar, die Spezifikation wird zum Asset. Wenn Agenten Code in Stunden erzeugen, ist Code kein Vermögenswert mehr, sondern ein reproduzierbares Artefakt. Das dauerhafte Asset ist die maschinenlesbare Spezifikation: Regeln, Daten, Schnittstellen und Akzeptanzkriterien in prüfbarer Qualität nach ISO/IEC/IEEE 29148. Wer sie besitzt, kann Code neu generieren lassen, in einer anderen Technologie, mit einem anderen Modell, bei einem anderen Dienstleister. Own the Spec, not the Code. Für Bestandssysteme heißt das, die IST-Spezifikation zuerst zu rekonstruieren, etwa mit App2Spec aus beobachteter Nutzung und mit SLIP aus dem Quellcode.

Kontext wird zum Produktionsfaktor. Agenten sind so gut wie ihr Kontext. Ohne strukturiertes Wissen über Systeme, Fachbegriffe und Regeln raten Modelle: Sie halluzinieren Anforderungen, übersehen Abhängigkeiten und erzeugen Nacharbeit, die den Effizienzgewinn auffrisst. Ein Wissensgraph, der Systeme, Anforderungen, Testfälle, Releases und Vorschriften über typisierte und belegte Beziehungen verbindet, löst das strukturell. Er gehört der Organisation, nicht dem Modellanbieter, und bleibt erhalten, wenn das Modell gewechselt wird.

Verifikation wird zum Engpass. Wenn Generierung billig wird, ist Prüfung der knappe Faktor. Zwei Prinzipien tragen die Antwort: Kein Agent prüft die eigene Arbeit; unabhängige Prüfagenten testen gegen die Spezifikation, scannen Sicherheit und Abhängigkeiten und messen die Abdeckung. Und Prüffälle entstehen aus der Spezifikation, bevor Code generiert wird. Test-first wird von der guten Praxis zur Norm.

Aus Übergaben wird Verantwortung. Die kleinste Wertschöpfungseinheit ist nicht mehr das Spezialistenteam aus acht Rollen, sondern die Zelle: fünf Menschen und eine wachsende Zahl von Agenten, end-to-end verantwortlich für einen fachlichen Schnitt. Der Zellen-Lead verantwortet das Ergebnis, die Domänenexpertin oder der Domänenexperte hält die fachliche Wahrheit, zwei Full-Stack-Entwicklerinnen oder -Entwickler steuern Architektur, Review und die Agenten selbst, die Ops-Expertin oder der Ops-Experte sichert die letzte Meile in die Produktion. Zykluszeiten fallen von Wochen auf Tage, in reifen Zellen auf Stunden, bei unveränderten Quality Gates.

Was bleibt: Menschen entscheiden an jedem Gate

Was sich nicht ändert, ist die Verantwortung. Jede Freigabe an einem Gate bleibt eine menschliche Entscheidung; jeder Agentenschritt dahinter ist protokolliert. Die Arbeitsteilung entlang der vier Phasen sieht so aus:

Diese Struktur ist zugleich die Antwort auf die Regulatorik. Die KI-Verordnung (EU) 2024/1689 fordert Risikomanagement, menschliche Aufsicht und Nachvollziehbarkeit; die Verordnung (EU) 2022/2554 zur digitalen operationalen Resilienz (DORA) verlangt belastbares IKT-Risikomanagement im Finanzsektor. Drei Prinzipien liefern die Bausteine: Der Mensch verantwortet jede Änderung eines Agenten, Richtlinien werden als Compliance as Code in Pipelines erzwungen statt in Dokumenten erinnert, und ein lückenloser Audit-Trail macht jede Agentenaktion, jeden verwendeten Kontext und jede Freigabe rekonstruierbar. Richtig gebaut ist der agentische Software Development Lifecycle deshalb nicht das Compliance-Risiko, für das er oft gehalten wird, sondern die erste Form der Delivery, in der Nachweise als Nebenprodukt der Arbeit entstehen.

Auch die Rollen verschwinden nicht, sie verschieben sich von Ausführung zu Urteilskraft: Entwicklerinnen und Entwickler werden zu Architektinnen und Architekten agentischer Systeme, Fachexpertinnen und Fachexperten zur präzisen Quelle der Spezifikation, Führungskräfte steuern über Zielbilder und Kennzahlen statt über Aufwandsplanung. Kulturell wiederholt sich der DevOps-Moment: KI wird Teammitglied, nicht Werkzeug.

Was die Evidenz sagt und was wir selbst messen

Die wissenschaftliche Evidenz für den Produktivitätseffekt von KI in der Wissensarbeit ist inzwischen belastbar. Im kontrollierten Experiment von Peng et al. (2023, arXiv:2302.06590) sank die Bearbeitungszeit von Programmieraufgaben mit KI-Assistenz um 56 Prozent. Noy und Zhang (2023, Science 381) maßen bei professionellen Schreibaufgaben 40 Prozent weniger Zeit bei 18 Prozent höherer Qualität. Brynjolfsson, Li und Raymond (2025, Quarterly Journal of Economics 140) fanden bei Beschäftigten im Kundensupport 14 Prozent mehr Produktivität, bei Berufseinsteigerinnen und Berufseinsteigern 34 Prozent. Diese Zahlen beschreiben die Copilot-Stufe, also L3. Der agentische Lifecycle setzt darüber an.

Unsere eigenen Werte kennzeichnen wir bewusst als Erfahrungswerte aus ReqPOOL-Projekten seit 2023, projektspezifisch validierbar und keine wissenschaftliche Evidenz. Im agentisch orchestrierten Umsetzungsmodell, also für den reinen Coding-Anteil, sehen wir eine bis zu fünfmal schnellere Delivery und bis zu 80 Prozent geringere Codierkosten. Über Gesamtprojekte inklusive Strategie, Spezifikation und Steuerung liegt der Effizienzgewinn bei 20 bis 45 Prozent. Die Qualität steigt durch systematische statt stichprobenhafte Verifikation um rund 30 Prozent. Der Unterschied zwischen dem Coding-Anteil und dem Gesamtprojekt ist entscheidend, und wir kommunizieren ihn transparent. Effizienz zählt dabei nur bei konstanten Leitplanken: Change Failure Rate, Produktionsstörungen, Defektrate und Testabdeckung dürfen sich nicht verschlechtern.

Wie wir es selbst tun: reqCoder

Wir beschreiben diesen Lifecycle nicht nur, wir arbeiten so. reqCoder ist der vollständige, vollautomatisierte agentische Software Development Lifecycle von ReqPOOL und bei uns intern bereits im Einsatz: von der Spezifikation als maschinenlesbarem Bauauftrag über Implementierung, Test und Abnahme bis zum Deployment. Koordinierte Agenten führen die ausführende Arbeit aus, unsere Expertinnen und Experten validieren im Loop, und jede Freigabe an einem Gate bleibt eine menschliche Entscheidung.

Die Umsetzung läuft in vier einzeln beauftragten Stages: Prototyp (zwei bis vier Wochen) als klickbarer Scope-Nachweis aus der Spezifikation, Beta (vier bis acht Wochen) mit Design, Build und Test entlang der agentischen Pipeline, Deployment (zwei bis sechs Wochen) mit Abnahme gegen die Spezifikation und automatisierten Pipelines, Produktion als überwachter Betrieb mit vollständigem IP-Transfer. Zwischen den Stages liegen Evidenz-Gates: Scope-Nachweis, Schätzung, Qualitätsprüfung der Anforderungen mit reqChecker, Security-Scan, Signoff-Abnahme und Audit-Trail. Generatoren und Verifikatoren sind getrennt, die KI läuft in EU-Rechenzentren, und es gibt kein Training mit Kundendaten. Für Banken, öffentliche Verwaltungen und andere regulierte Organisationen entscheidet genau diese Kette darüber, ob aus einem Experiment ein abnahmefähiges System wird.

Der nächste Schritt

Der agentische Software Development Lifecycle ist kein Werkzeugkauf, sondern ein planbarer Reifegradpfad. Der erste Schritt ist klein und konkret: Standort bestimmen, zwei bis drei Leuchtturmzellen aufsetzen, nach 90 Tagen gegen die Baseline messen. Wie wir den agentischen Software Development Lifecycle in Ihrer Organisation verankern, lesen Sie auf der Seite Agentic Software Development Lifecycle; wie reqCoder aus der Spezifikation Software erzeugt, auf der Seite reqCoder. In den kommenden Beiträgen dieser Serie vertiefen wir einzelne Bausteine dieses Betriebsmodells. Oder Sie sprechen direkt mit uns: In einem Expertengespräch klären wir, wo Ihre Organisation auf dem Reifegradpfad steht.