Agentic Coding: Warum der Software Development Lifecycle neu gedacht werden muss

Zuletzt aktualisiert am: 29. April 2026

Mit modernen agentischen Entwicklungssystemen wie Anthropics Claude Code und vergleichbaren AI-Engineering-Plattformen hat die Softwareindustrie einen Punkt erreicht, an dem sich substanzielle Teile des klassischen Entwicklungszyklus massiv beschleunigen lassen. In professionellen Entwicklungsumgebungen ist es inzwischen realistisch, den Implementierungsumfang eines traditionellen Zwei-Wochen-Sprints innerhalb weniger Stunden technisch zu erzeugen – einschließlich großer Teile der zugehörigen Testartefakte. Doch diese neue Geschwindigkeit führt in vielen Organisationen zu einer fundamentalen Fehlinterpretation:Schneller Code bedeutet nicht automatisch bessere Software.

Jeder erfahrene Software Engineer, Architekt oder Quality Engineer weiß: Geschwindigkeit korreliert nicht automatisch mit Wartbarkeit, Skalierbarkeit, Robustheit oder Nachhaltigkeit. Im Gegenteil – ohne strukturelle Anpassung des Software Development Lifecycle (SDLC) kann Agentic Coding zu Qualitätsverlust, Integrationschaos und organisatorischen Dysfunktionen führen. Viele Teams beobachten bereits erste Symptome: QA wird als vermeintlicher Flaschenhals wahrgenommen, Merge-Konflikte und Integrationsprobleme nehmen deutlich zu, Architektur driftet schneller auseinander, technische Schulden wachsen trotz höherer Entwicklungsgeschwindigkeit, und fachliche Inkonsistenzen häufen sich.

Die häufige Schlussfolgerung lautet: „Unsere Qualitätssicherung kann mit der Entwicklungsgeschwindigkeit nicht mehr mithalten.“ Doch häufig liegt die Ursache nicht in einer ineffizienten Qualitätssicherung, sondern darin, dass bestehende Delivery- und Qualitätsprozesse nicht auf die neue Entwicklungsgeschwindigkeit ausgelegt sind. Unternehmen, die Agentic Coding professionell einsetzen wollen, müssen akzeptieren, dass derSoftware Development Lifecycle im Zeitalter agentischer Entwicklung neu definiert werden muss.

1. Agentic Coding verändert nicht nur Implementierung – sondern das gesamte Engineering-Modell

Der größte Irrtum aktueller Diskussionen besteht darin, Agentic Coding auf reine Codegenerierung zu reduzieren. Professionelles Agentic Coding im Enterprise-Kontext hat nichts mit sogenanntem „Vibe Coding“ gemein – der Praxis, unstrukturiert per Prompt Code erzeugen zu lassen und das Ergebnis ohne systematische Validierung zu verwenden. Es ist vielmehr ein strukturierter Engineering-Ansatz mit klar definierten Qualitäts- und Steuerungsmechanismen.

Professionelles Agentic Coding bedeutet insbesondere:

  • deterministische und nachvollziehbare Engineering-Prozesse
  • strukturierte Spezifikationsketten
  • qualitätsgesicherte Artefaktproduktion
  • kontrollierte Kontextübergaben
  • systematische Validierung auf jeder Ebene des SDLC

Damit verschiebt sich der Engpass in der Softwareentwicklung fundamental: Nicht mehr Implementierung ist der primäre kosten- und zeitdominante Faktor – sondern Engineering-Qualität. Die zentrale Frage lautet künftig nicht mehr: „Wie schnell können wir Code schreiben?“ Sondern: „Wie stellen wir sicher, dass maschinell erzeugte Artefakte korrekt, wartbar, architekturkonform und langfristig evolvierbar sind?“

2. Warum klassische agile Delivery-Modelle unter Agentic Coding an Grenzen stoßen

Viele agile Teams arbeiten heute implizit mit einer inkrementellen Interpretation klassischer Entwicklungsmodelle.

Auch wenn Scrum oder Kanban eingesetzt werden, durchlaufen Teams innerhalb eines Sprints faktisch wiederkehrende Engineering-Aktivitäten, die klassischen Entwicklungsphasen entsprechen – wenn auch iterativ, überlappend und nicht streng sequenziell. Dazu zählen insbesondere:

  • Anforderungsanalyse
  • Spezifikation
  • Architektur- und Designentscheidungen
  • Implementierung
  • Reviews (z. B. Architektur-, Design- und Code-Reviews)
  • Verifikation und Validierung

Reviews sind dabei ein eigenständiger Engineering-Schritt, da sie nicht primär funktionale Korrektheit prüfen, sondern Qualität auf anderen Ebenen absichern – insbesondere Architekturkonformität, Wartbarkeit, Sicherheitsaspekte, Verständlichkeit und Einhaltung technischer Standards.

Im Zeitalter agentischer Entwicklung wird deutlich: Diese Phasen müssen explizit und qualitätsgesteuert modelliert werden. Denn wenn die technische Implementierung gegenüber Spezifikation, Validierung und Qualitätssicherung signifikant an Aufwand verliert, verschiebt sich der Qualitätshebel vollständig auf die vorgelagerten Phasen. Hier bietet das V-Modell eine überraschend moderne Grundlage.

3. Warum das V-Modell im Agentic-Zeitalter relevanter wird als je zuvor

Das klassische V-Modell strukturiert Entwicklung in sieben aufeinander aufbauende Ebenen: (1) Business Requirements, (2) Business Specification, (3) System Requirements, (4) Technical Requirements, (5) Technical Specification, (6) Component Specification und (7) Implementation.

Historisch wurde das V-Modell oft als zu schwergewichtig kritisiert. Unter Agentic Coding entsteht jedoch eine neue Realität:Je präziser und strukturierter die Vorphasen sind, desto hochwertiger wird das maschinell erzeugte Ergebnis.Agentische Systeme liefern umso bessere Resultate, je präziser und strukturierter ihre Eingaben und Kontextgrundlagen sind.

Damit wird das V-Modell nicht zum bürokratischen Relikt, sondern zur idealen Grundlage für deterministische AI-Steuerung, phasenweise Qualitätsgates, formalisierte Kontextübergaben, messbare Spezifikationsqualität und reproduzierbare Entwicklungsprozesse.

4. Source Code allein ist keine ausreichende Source of Truth mehr

Eine zentrale Erkenntnis aus agentischer Softwareentwicklung lautet:Source Code allein reicht nicht mehr als Wissensbasis für nachhaltige Softwareentwicklung.AI-Systeme arbeiten nur dann hochwertig, wenn ihr Kontext vollständig, konsistent und strukturiert vorliegt.

Für nachhaltige Qualität benötigt professionelle agentische Entwicklung zusätzlich mindestens folgende Artefaktklassen:

System Landscape & Context Artifacts
Dokumentieren Systemgrenzen, fachliche Domänen, Integrationspartner, Verantwortlichkeiten und Systemkontexte.

Architecture Artifacts
Architekturprinzipien, ADRs, Patterns, Layering, Quality Attributes und Constraints.

Interface Artifacts
API-Spezifikationen, Event Contracts, Message Schemas und Consumer/Provider Agreements.

Data Artifacts
Domänenmodelle, Datenflüsse, Schemas, Validierungsregeln und Ownership-Definitionen.

Runtime & Deployment Artifacts
Deployment-Modelle, Infrastruktur-Topologien, Security-/Runtime-Constraints und Observability-Vorgaben.

Diese Artefakte sind essenziell, damit AI-generierte Lösungen systemisch konsistent, architekturkonform und operativ tragfähig bleiben. In der Gesamtdarstellung des agentischen V-Modells (Abschnitt 7) sind sie als „Essential Artifacts“ visualisiert.

5. Das agentische V-Modell: Qualität durch AI-gesteuerte Quality Gates

Im professionellen agentischen SDLC wird jede Phase des V-Modells zu einem qualitätsgesicherten Übergabepunkt. Die folgende Darstellung zeigt den Prozess exemplarisch für die Business Requirement- und Business Specifications-Phase:

Abb. 1: AI-gestützter Quality-Gate-Prozess in der Business-Requirement- und -Specification-Phase. Von der Rohanforderung über AI Review und Impact Analysis bis zur validierten Business Specification mit abgeleiteten Acceptance Test Scenarios.

Business Requirement Phase

Rohanforderungen werden zunächst ein AI-gestütztes Review , das systematisch auf fachliche Lücken, Inkonsistenzen, Widersprüche, Glossar- und Terminologieverstöße, Naming- und Formatverletzungen sowie unklare Formulierungen prüft (siehe Abbildung). Erst nach mehreren Review-Schleifen passiert eine Anforderung das erste Quality Gate.

Business Specification Phase

Auf Basis validierter Anforderungen, bestehender Business-Dokumentation und gepflegter Dokumentation kritischer Geschäftsprozesse erzeugt ein agentisches System eine strukturierte Impact Analysis: Welche Prozesse sind betroffen? Welche Randbedingungen greifen? Welche Risiken entstehen? Welche Seiteneffekte sind zu berücksichtigen?

Darauf basierend entsteht eine Business Specification, die Use Cases, User Journeys, Prozessmodelle (BPMN/Process Flows), Business Rules und Functional Scenarios mit zugehörigen Acceptance Criteria umfasst.

Frühe Testableitung als Engineering-Prinzip

Bereits auf Business-Ebene werden daraus Acceptance Test Scenarios abgeleitet: Zerlegung in Test Conditions, risikobasierte Testfallermittlung, Anwendung etablierter Testdesign-Techniken und Strukturierung nach standardisierten Testprinzipien. Testbarkeit entsteht vor Implementierung – nicht erst danach.

6. Traceability als Kontrollmechanismus des agentischen SDLC

Mit zunehmender Automatisierung des SDLC wird Traceability von einer klassischen Governance-Anforderung zu einem operativen Steuerungsmechanismus des gesamten Engineering-Prozesses. Im agentischen SDLC bildet sie die Grundlage für deterministische KI-Orchestrierung, präzise Impact Analysen, kontrollierte Artefaktgenerierung und konsistente Änderungspropagation. Ein agentisch orchestrierter SDLC ist nur dann beherrschbar, wenn zwischen sämtlichen Engineering-Artefakten eine durchgängige Traceability besteht. Die folgende Abbildung zeigt diese Wirkungskette über alle Engineering-Ebenen:

Abb. 2: Traceability über alle Engineering-Ebenen – von der User Journey über Business Process Model, System Requirements und Technical Specification bis zur Implementation. Jede Ebene beantwortet eine spezifische Leitfrage und erzeugt nachvollziehbare Artefakte.

Durchgängige Traceability stellt sicher, dass jede Implementierung auf validierte Anforderungen zurückführbar ist, technische Entscheidungen fachlich begründet werden können, Testaktivitäten systematisch ableitbar bleiben und Änderungen konsistent über alle Artefaktebenen propagiert werden. In regulierten Domänen ermöglicht sie darüber hinaus jederzeit belastbare Audit- und Compliance-Nachweise.

Ohne durchgängige Traceability erzeugt Agentic Coding zwar schnell funktionierenden Code, jedoch ohne belastbare Einordnung in fachliche Zusammenhänge, Systemkontext und architektonische Gesamtstruktur.Die Folge sind Inkonsistenzen, Architekturdrift und technische Schulden, die sich mit zunehmender Automatisierung verstärken. Insbesondere in regulierten und komplexen Enterprise-Domänen ist Traceability daher keine optionale Dokumentation, sondern eine fundamentale Voraussetzung für professionelle, kontrollierte und auditierbare agentische Softwareentwicklung.

7. Wenn das V-Modell agentisch orchestriert ist, schrumpft Delivery von Wochen auf Stunden

Ist das agentische V-Modell vollständig operationalisiert, kann sich der operative Durchlauf klar abgegrenzter Sprint-Increments von Tagen oder Wochen auf wenige Stunden reduzieren. Die folgende Darstellung zeigt das Gesamtmodell mit allen sieben Phasen, den zugehörigen Quality Gates und den Essential Artifacts als Wissensgrundlage:

Abb. 3: Das agentische V-Modell im Gesamtüberblick. Sieben Phasen mit AI-gestützten Quality Gates, von Business Requirements bis Implementation. Am unteren Rand: die Essential Artifacts, die als Wissensgrundlage für alle Phasen dienen.

Ein exemplarischer Ablauf:

  • Business Requirement & Business Specification: 30 Min
  • System Requirement: 10 Min
  • Technical Requirement: 15 Min
  • Technical Specification: 10 Min
  • Component Specification: 10 Min
  • Implementation: 5 Min
  • Testing / Reporting / Evaluation: 30 Min
  • Buffer für Bugfixing / Synchronisation / Retro Prep: 10 Min
Abb. 4: Exemplarischer Ablauf eines agentischen Sprints (ca. 2 Stunden, eine Person). Die Zeitangaben beziehen sich auf ein klar abgegrenztes, modularisiertes Sprint-Increment – nicht auf ein komplettes Epic oder Feature-Set.

8. Neue organisatorische Konsequenzen

Sprint-Zuschnitt muss neu gedacht werden

In hochgradig agentischen Delivery-Modellen verschiebt sich der optimale Zuschnitt von Sprint-Arbeitspaketen hin zu kleineren, klar abgegrenzten und stärker individualverantworteten Umsetzungseinheiten. Denn unkoordinierte parallele agentische Codeproduktion erhöht das Risiko für Merge-Konflikte, unkoordinierte Architekturänderungen, Spezifikationsinkonsistenzen und Integrationsinstabilität.Größere Vorhaben sollten daher modularisiert werden in: in parallelisierte Modulsprints, gefolgt von dedizierten Integrationssprints.

9. Das neue Berufsbild im Software Engineering

Agentic Coding verschiebt den Wertbeitrag innerhalb von Entwicklungsteams fundamental.

Die klassische Trennung zwischen Business Analyst, Software Engineer, QA Engineer und Architect beginnt zunehmend zu verschwimmen.

Es entsteht ein neues Zielprofil: der AI-augmented Systems Engineer – ein Professional mit kombinierter Expertise in Requirement Engineering, Software Architecture, Quality Engineering, Test Design, Systems Thinking und AI Orchestration.Sein zentraler Wertbeitrag liegt nicht primär im Schreiben von Code, sondern in der Definition hochwertiger Spezifikationen, der Bewertung architektonischer Implikationen, der Validierung maschinell erzeugter Artefakte, der Steuerung komplexer AI-Workflows und der Sicherstellung systemischer Qualität.

10. Grenzen und Voraussetzungen agentischer Entwicklung

Agentic Coding entfaltet seinen Nutzen nur unter bestimmten Voraussetzungen: hohe Reife der bestehenden Engineering-Artefakte, disziplinierte Architektur- und Dokumentationspflege, standardisierte Delivery-Prozesse, hohe Kompetenz der steuernden Engineers sowie eine geeignete Toolchain und Governance.

Diese Voraussetzungen decken sich mit Prinzipien, die mgm seit über zwei Jahrzehnten in der Entwicklung geschäftskritischer Systeme verfolgt: strukturierte Architektur, standardisierte Prozesse und hohe Engineering-Disziplin.Ohne diese Voraussetzungen kann Agentic Coding bestehende organisatorische und technische Defizite nicht kompensieren – sondern häufig beschleunigt verstärken.

11. Fazit

Agentic Coding ist keine bloße Beschleunigung klassischer Entwicklung.Es ist ein Paradigmenwechsel des gesamten Software Engineerings. Organisationen, die Agentic Coding lediglich auf bestehende Delivery-Modelle aufsetzen, werden kurzfristig mehr Output erzielen – mittelfristig jedoch erhebliche Qualitäts- und Integrationsprobleme erzeugen.

Organisationen hingegen, die ihren SDLC neu denken, Quality Gates etablieren und Engineering als orchestrierten Spezifikations-, Validierungs- und Steuerungsprozess verstehen, können erstmals erreichen: drastisch höhere Delivery-Geschwindigkeit bei gleichbleibender oder höherer Qualität, systematische Nachvollziehbarkeit und skalierbare Enterprise-Entwicklung mit AI.

Nachhaltiger Wettbewerbsvorteil entsteht im Zeitalter agentischer Entwicklung nicht durch individuelle Implementierungsgeschwindigkeit, sondern durch die Qualität, Steuerbarkeit und Skalierbarkeit des zugrunde liegenden Engineering-Systems. Organisationen, die diesen Wandel früh gestalten, werden deutlich profitieren.

Lilia Gargouri
Lilia Gargouri ist Diplom Informatikerin, erfahrene Softwareentwicklerin und Head of Quality Assurance bei mgm technology partners. Mit tiefgreifender Expertise in der Testautomatisierung, einem starken Innovationsfokus und strategischem Weitblick entwickelt sie skalierbare und effiziente QA-Prozesse für komplexe langlebige Geschäftsanwendungen. Als Mitglied des German Testing Board engagiert sie sich aktiv für die Weiterentwicklung internationaler Softwarequalitätsstandards.