Agilität im Zeitalter von Agentic AI: Engpassverschiebung, das Ende klassischer Aufwandschätzung und die Neukonfiguration soziotechnischer Entwicklungsprozesse

1. Einleitung und theoretische Problemstellung: Die Illusion des überwundenen Engpasses

Die moderne Softwareentwicklung befindet sich im Übergang von der generativen Code-Vervollständigung (Software Engineering 2.0) hin zum Paradigma des Agentic Software Engineering (ASE) beziehungsweise Software Engineering 3.0 (SE 3.0)¹. Während frühe Sprachmodelle lediglich als reaktive Werkzeuge innerhalb bestehender Entwicklungsumgebungen agierten, zeichnen sich autonome Software-Agenten dadurch aus, dass sie gesamte Code-Repositories inspizieren, mehrstufige Implementierungspläne entwerfen, Kommandozeilen-Werkzeuge aufrufen, zahlreiche Dateien parallel modifizieren, Testsuiten ausführen und selbstständig Pull Requests (PRs) zur Abnahme vorlegen². Aus dieser technologischen Leistungsfähigkeit speist sich in der Praxis häufig die weitreichende Hypothese, dass der historische Hauptengpass der Softwareproduktion – die manuelle Übersetzung fachlicher Anforderungen in ausführbaren Quellcode – endgültig beseitigt sei³. In der logischen Konsequenz dieser Annahme erscheint die klassische agile Aufwands- und Komplexitätsschätzung von Arbeitspaketen (etwa mittels Story Points im Planning Poker) als obsoletes Relikt, da es für die Durchlaufzeit vermeintlich irrelevant wird, ob ein Ticket einfach oder hochkomplex ist, solange ein autonomer Agent die Implementierung übernimmt².

Eine strenge wissenschaftliche Analyse auf Basis der Theory of Constraints (TOC) nach Eliyahu M. Goldratt sowie des Amdahlschen Gesetzes widerlegt jedoch die Annahme eines schlichtweg verschwundenen Engpasses und offenbart stattdessen eine fundamentale systemische Fehleinschätzung¹. Nach der Engpasstheorie wird der Gesamtdurchsatz jedes komplexen Wertschöpfungssystems durch mindestens eine limitierende Restriktion (Constraint) bestimmt; wird dieser primäre Engpass durch technologische Beschleunigung aufgehoben, verschwindet die Systembegrenzung nicht, sondern wandert unmittelbar an eine andere Stelle der Prozesskette³. Das Agile Manifest von 2001 sowie Frameworks wie Scrum und Extreme Programming (XP) entstanden unter einer spezifischen ökonomischen Knappheitsbedingung: Menschliche Programmierarbeit war die langsamste, teuerste und knappste Ressource im Lebenszyklus der Softwareentwicklung¹. Alle klassischen agilen Prinzipien – von der Selbstorganisation über das Timeboxing in mehrwöchigen Sprints bis hin zum Leitsatz „funktionierende Software mehr als umfassende Dokumentation“ – waren rationale Optimierungsantworten auf den Engpass manueller Code-Erzeugung¹.

Mit dem Aufkommen von Agentic AI kollabiert diese ökonomische Grundannahme, wodurch sich das Optimierungsproblem des gesamten Software Development Life Cycle (SDLC) umkehrt⁴. Die reine Code-Implementierung, die historisch rund 60 Prozent der Kapazität eines Sprints beanspruchte, schrumpft durch agentische Automatisierung auf etwa 20 Prozent zusammen⁵. Da jedoch nachgelagerte und vorgelagerte Phasen – insbesondere die präzise Problemformulierung, die Architekturentscheidung, die Code-Verifikation, das Sicherheits-Auditing und die kognitive Systemdurchdringung durch den Menschen – weiterhin an die biologische Informationsverarbeitungskapazität menschlicher Ingenieure gebunden sind, verlagert sich der Engpass mit voller Wucht in die Spezifikations- und Verifikationsphase¹. Werden agile Methoden nicht strukturell an diese neue Knappheit angepasst, führt die ungebremste agentische Code-Generierung nicht zu höherer organisatorischer Agilität, sondern zu einem Kollaps der Qualitätssicherung, zu explodierenden Review-Warteschlangen und zu einem rapiden Verlust der menschlichen Systemkontrolle¹.

2. Empirische Befunde: Das Produktivitätsparadoxon und die Verschuldungstriade

2.1 Amdahls Gesetz und die Telemetrie des Review-Staus

Die theoretische Vorhersage der Engpassverschiebung wird durch großangelegte empirische Telemetriestudien und kontrollierte Feldexperimente der Jahre 2025 und 2026 präzise quantifiziert¹. Gemäß Amdahls Gesetz wird die maximale Beschleunigung eines Gesamtsystems durch denjenigen Teilprozess begrenzt, der nicht parallelisiert oder beschleunigt werden kann¹. In der agentischen Softwareentwicklung bildet die menschliche Überprüfung und Freigabe (Human Approval Gate) diesen seriellen Flaschenhals⁶.

Die umfassende Untersuchung von Faros AI über mehr als 10.000 Softwareentwickler in 1.255 Teams hinweg liefert den empirischen Beleg für dieses Phänomen¹. In Teams mit hoher KI-Adaption steigt zwar die Anzahl abgeschlossener Einzelaufgaben um 21 Prozent und die Rate zusammengeführter (gemergter) Pull Requests um 98 Prozent an¹. Gleichzeitig bearbeiten Entwickler täglich 9 Prozent mehr Aufgaben und 47 Prozent mehr Pull Requests parallel, was auf eine drastische Zunahme von Multitasking und Kontextwechseln hinweist⁷. Dieser lokale Ausstoß an Quellcode führt jedoch auf Systemebene zu einer massiven Verstopfung der Integrationspipeline: Das durchschnittliche Volumen eines Pull Requests wächst um 154 Prozent, während die benötigte Durchlaufzeit für das Code-Review pro Pull Request um 91 Prozent nach oben schnellt⁷.

Darüber hinaus korreliert die ungesteuerte Beschleunigung der Code-Erzeugung mit einer signifikanten Degradation der strukturellen Softwarequalität¹. In der Faros-Telemetrie verzeichnen Teams mit intensiver KI-Nutzung einen Anstieg der Fehlerrate (Bugs) um 9 Prozent pro Entwickler¹. Noch deutlicher zeigt sich das Qualitätsproblem in detaillierten Artefaktanalysen: Eine Untersuchung von 470 GitHub-Pull-Requests durch CodeRabbit belegt, dass KI-generierter Code im Vergleich zu rein menschlichem Code das 1,7-Fache an Mängeln aufweist, darunter 75 Prozent mehr Logikfehler und dreimal so viele Lesbarkeitsprobleme⁸. Bei unstrukturierten, dialogbasierten Entwicklungspraktiken – in der Literatur als „Vibe Coding“ bezeichnet – bricht zudem die Disziplin der Codepflege ein: Der Anteil von Refactoring-Aktivitäten sinkt von 25 Prozent auf unter 10 Prozent, während sich die Anzahl duplizierter Codeblöcke über Millionen geänderter Codezeilen hinweg verachtfacht¹. Das Resultat dieser Dynamik ist ein Nullsummenspiel auf Unternehmensebene: Zwischen der reinen Einführung von KI-Coding-Agenten und der tatsächlichen Auslieferungsgeschwindigkeit oder Produktivität der Gesamtorganisation besteht keinerlei statistisch signifikante Korrelation, was einem Netto-Produktivitätsgewinn von 0 Prozent entspricht⁹.

2.2 Wahrnehmungsverzerrung in gewachsenen Systemen und das Triple-Debt-Modell

Besonders gravierend wirkt sich die Fehlannahme einer mühelosen Implementierung in komplexen, über Jahre gewachsenen Bestandsarchitekturen (Brownfield- und Legacy-Systemen) aus². In einer streng kontrollierten, randomisierten Studie (RCT) des Forschungsinstituts METR führten 16 erfahrene Open-Source-Entwickler insgesamt 246 reale Entwicklungsaufgaben an reifen Repositories durch, mit denen sie bereits tiefgehend vertraut waren¹⁰. Wurde der Einsatz fortschrittlicher KI-Werkzeuge (wie Cursor Pro mit Claude 3.5 und 3.7 Sonnet) randomisiert zugelassen, benötigten die Entwickler für den Abschluss der Aufgaben real 19 Prozent länger als ohne KI-Unterstützung¹. Bemerkenswert ist hierbei die kognitive Dissonanz zwischen subjektiver Wahrnehmung und objektiver Messung: Vor Studienbeginn prognostizierten die Ingenieure eine Beschleunigung um 24 Prozent, und selbst nach Abschluss der verzögerten Aufgaben waren sie weiterhin überzeugt, mit KI rund 20 Prozent schneller gearbeitet zu haben¹.

Diese Diskrepanz zwischen gefühlter Geschwindigkeit („Felt-Speed“) und realer Durchlaufzeit erklärt sich dadurch, dass generative und agentische Systeme sehr schnell oberflächlich plausiblen Code erzeugen („almost correct, but not quite“), dessen subtile Randfall-Fehler, Sicherheitslücken oder Architekturverletzungen erst in aufwendigen Debugging-, Test- und Verifikationsschleifen identifiziert und behoben werden müssen¹. Während Agenten bei isolierten Routineaufgaben enorme Geschwindigkeitsvorteile erzielen – GitHub Copilot schließt beispielsweise 75 Prozent seiner Pull Requests innerhalb von 18,5 Minuten ab, bei einem Median von 12,8 Minuten gegenüber mehr als einem halben Arbeitstag bei menschlichen Entwicklern –, zeigt die statistische Verteilung im 95. Perzentil mit über einer Stunde Bearbeitungszeit einen ausgeprägten „Long Tail“ bei komplexen Systemabhängigkeiten¹¹.

Um die unsichtbaren Folgekosten dieser Hochgeschwindigkeits-Codegenerierung theoretisch zu fassen, erweitert die aktuelle Software-Engineering-Forschung (insbesondere durch Margaret-Anne Storey und Christopher Koch) den klassischen Begriff der technischen Schulden (Technical Debt) zu einem Triple-Debt-Modell, flankiert durch das Konzept der Verifikationsschuld⁶. Die erste Säule dieses Modells bilden die kognitiven Schulden (Cognitive / Comprehension Debt). Während technische Schulden im Quellcode liegen, akkumulieren kognitive Schulden im Gedächtnis und im mentalen Modell des Entwicklungsteams¹². Historisch fungierte das manuelle Schreiben und gegenseitige Reviewen von Code als pädagogischer Prozess, der das Wissen über Systemzusammenhänge im Team verteilte¹². Wenn Agenten Code schneller generieren, als Menschen ihn kognitiv durchdringen können, entsteht eine gefährliche Geschwindigkeitsasymmetrie¹². Empirische Untersuchungen zeigen, dass Entwickler, die Code-Generierung vollständig an KI delegieren, in anschließenden Systemverständnistests Werte von unter 40 Prozent erreichen, während Entwickler, die KI als konzeptionellen Sparringspartner zur Erforschung von Trade-offs nutzen, Werte von über 65 Prozent erzielen¹². Teams mit hoher kognitiver Verschuldung erleben häufig nach wenigen Wochen (in Fallstudien typischerweise um Woche sieben) einen plötzlichen Stillstand: Obwohl alle automatisierten Tests grün sind und der Code syntaktisch sauber wirkt, kann das Team keine einfachen Änderungen mehr vornehmen, ohne unerwartete Seiteneffekte auszulösen, weil niemand mehr versteht, wie das Gesamtsystem intern funktioniert¹³.

Als zweite Dimension treten Intentionsschulden (Intent Debt) hinzu, die im Bereich der Entwicklungsartefakte durch die Erosion explizit dokumentierter Entwurfsbegründungen, fachlicher Randbedingungen und verworfener Alternativen entstehen¹³. Da „Vibe Coding“ auf flüchtigen, unstrukturierten Chat-Dialogen basiert, geht das Warum hinter einer Implementierung verloren¹. Jede nachfolgende Iteration KI-gestützter Weiterentwicklung schleppt dieses Defizit nicht nur mit, sondern potenziert es, da zukünftige Agenten und Menschen den ursprünglichen Systemzweck aus dem bloßen Quellcode nicht mehr rekonstruieren können¹³.

Drittens entsteht Verifikationsschuld (Verification Debt), sobald das Volumen generierter Artefakte schneller wächst als die Prüfkapazität der Organisation⁶. Diese wird psychologisch durch den Mechanismus der kognitiven Kapitulation (Cognitive Surrender nach Shaw und Nave) beziehungsweise Habituation at the Gate verstärkt⁸: Konfrontiert mit riesigen, syntaktisch makellosen Pull Requests erliegen menschliche Reviewer einer trügerischen Sicherheit und winken Agenten-Outputs mit minimaler kritischer Prüfung durch¹¹. So zeigen aktuelle Repository-Analysen, dass akzeptierte Pull Requests von OpenAI Codex im Median zehnmal schneller durchgewunken werden als menschliche Beiträge (0,3 Stunden gegenüber 3,9 Stunden), was auf eine oberflächliche Abnahme statt auf echte Tiefenprüfung hindeutet¹¹. Zudem entsteht durch anbieterinterne Review-Schleifen – etwa wenn copilot-swe-agent[bot] 91 Prozent der GitHub-Copilot-Pull-Requests vorprüft – die Gefahr blinder Flecken und selbstverstärkender Modell-Biases¹¹.

3. Dekonstruktion der Ticket-Schätzung: Warum Story Points kollabieren, die Komplexitätsbewertung jedoch überlebenswichtig wird

3.1 Die Entkopplung von Implementierungsdauer und Systemkomplexität

Vor dem Hintergrund dieser empirischen Befunde lässt sich die Kernfrage, ob das Schätzen der Komplexität von Tickets im Zeitalter von Agentic AI noch sinnvoll ist, differenziert beantworten: Die klassische Schätzung von Story Points als Maß für menschlichen Programmieraufwand ist obsolet, doch die strukturierte Bewertung der Ticket-Komplexität wird wichtiger als jemals zuvor – sie wechselt lediglich ihre Bewertungsdimension¹⁴.

Historisch wurden Story Points in Scrum eingeführt, um von fehleranfälligen Stundenschätzungen wegzukommen und stattdessen eine relative Einschätzung des Aufwands vorzunehmen¹⁵. Dennoch basierte das Konstrukt des Story Points implizit auf einer rein menschlichen Gleichung: Geschätzt wurde eine Kombination aus manueller Schreibarbeit, individueller Einarbeitungszeit (Ramp-up), technischer Unsicherheit und menschlicher Ermüdung¹⁴. Sobald eine Arbeitseinheit von „zwei Wochen menschlicher Programmierarbeit“ auf „45 Minuten agentischer Code-Generierung plus drei Stunden menschlicher Architekturprüfung und Verifikation“ zusammenschrumpft, verliert der klassische Story Point jede Aussagekraft für die Kapazitätsplanung². Zudem haben Organisationen Story Points häufig als Produktivitäts-KPI missbraucht, was bereits vor dem KI-Zeitalter bei der Beseitigung technischer Schulden oder CI/CD-Optimierungen zu Fehlanreizen führte und unter KI-Bedingungen vollends kollabiert, weil „abgebrannte Punkte“ keinerlei Korrelation zur gelieferten Wertschöpfung oder Systemstabilität aufweisen².

Der entscheidende Denkfehler vieler Praxisansätze besteht jedoch darin, aus dem Wegfall des Tipp- und Implementierungsaufwands zu schließen, dass die Komplexität eines Tickets irrelevant geworden sei. In der Informatik ist der zeitliche Aufwand zur Erstellung von Code nicht identisch mit der strukturellen und semantischen Komplexität einer Systemänderung. Wenn ein Agent in wenigen Minuten 2.000 Zeilen Quellcode über zwölf Microservices hinweg generiert, ist der Erstellungsaufwand minimal, die Verifikations-, Integrations- und Verständniskomplexität für das verantwortliche Entwicklerteam jedoch extrem hoch¹⁶. Ohne eine präzise Vorab-Klassifizierung dieser Komplexität fluten Agenten die Review-Warteschlange mit hochgradig vernetzten Änderungen, die die kognitive Aufnahmefähigkeit der Senior-Ingenieure sprengen¹⁴.

3.2 Inversion der Iterationsökonomie: Das Wissbare und das Entdeckbare

Ein weiterer Grund, warum ein einheitliches Schätzverfahren für alle Tickets scheitert, liegt in der fundamentalen Inversion der Iterationsökonomie (Inversion of Iteration Economics)¹⁷. In Anlehnung an das Cynefin-Framework unterscheidet die aktuelle Forschung zum KI-gestützten Software Engineering zwei grundlegende Anforderungsregime, die als Kontinuum existieren¹⁷. Auf der einen Seite steht das Regime des Wissbaren (The Knowable Regime), worunter Anforderungen fallen, deren Zielzustand und Invarianten vorab exakt determiniert werden können und müssen – etwa regulatorische Compliance-Regeln, Datenmodelle, kryptografische Sicherheitsgrenzen, öffentliche API-Verträge oder Hardware-Timing-Restriktionen¹⁷. In diesem Regime ist ein unstrukturiertes „Ausprobieren“ durch den Agenten hochgefährlich; Anforderungen müssen vorab durch formale Spezifikationen und Test-Driven Development (TDD) wasserdicht verankert werden¹⁷. Auf der anderen Seite des Spektrums befindet sich das Regime des Entdeckbaren (The Discoverable Regime), das implizite (tacit) Anforderungen wie Benutzerführung, visuelle Datenaufbereitung oder neuartige Produktinteraktionen umfasst, bei denen Stakeholder erst durch die Reaktion auf ein laufendes Artefakt erkennen, was sie eigentlich benötigen¹⁷.

In der traditionellen Softwareentwicklung war das Bauen von Software teuer und langsam, weshalb Teams versuchten, auch entdeckbare Anforderungen vorab in detaillierten User Stories zu spezifizieren und zu schätzen². Durch Agentic AI kehrt sich diese Ökonomie im entdeckbaren Regime komplett um: Eine implizite Anforderung vorab erschöpfend zu spezifizieren und im Team zu schätzen, kostet heute ein Vielfaches an Zeit und Geld im Vergleich dazu, durch einen Agenten innerhalb weniger Minuten drei funktionsfähige Kandidaten-Prototypen (N-Versionen) generieren zu lassen, diese live zu kritisieren und iterativ zu verwerfen oder zu verschmelzen¹⁸. Wie Fallstudien zeigen – etwa bei fehlgeschlagenen Berichtsmodulen, die zwar alle vorab definierten Akzeptanzkriterien erfüllten, aber am realen Nutzerbedürfnis vorbeigingen –, ist im entdeckbaren Regime das sofortige Bauen und Evaluieren der ökonomisch günstigste Weg, um die eigentliche Spezifikation überhaupt erst zu finden¹⁷.

3.3 Neue Bewertungsmodelle: Tri-modale Backlogs, CIRK-Standard und Risiko-Gates

Anstelle einer pauschalen Abschaffung jeglicher Ticket-Klassifizierung vollzieht sich im Agentic Software Engineering der Übergang von der Aufwandschätzung (Effort Estimation) zur mehrdimensionalen Risiko-, Kontext- und Verifikationsbewertung⁵. In der aktuellen Forschung und fortgeschrittenen Industriepraxis kristallisieren sich hierfür drei komplementäre Steuerungsmechanismen heraus.

Erstens wird das klassische, homogene Product Backlog in eine tri-modale Aufgaben-Taxonomie überführt, die nach dem Grad der agentischen Autonomie und dem Charakter der menschlichen Beteiligung differenziert¹⁹. Die erste Kategorie bilden sogenannte Zero-Point Stories für die vollautonome Ausführung: Aufgaben mit minimaler Systemkopplung und klar determinierten Invarianten – wie Boilerplate-Generierung, isolierte CRUD-Endpunkte, Dokumentations-Updates oder Skript-Migrationen – erhalten den Schätzwert Null, da sie von Agenten ohne nennenswerte menschliche Intervention abgearbeitet und durch automatisierte CI-Pipelines verifiziert werden⁵. Die zweite Kategorie umfasst Validation Stories zur explorativen Hypothesenprüfung im entdeckbaren Regime, bei denen der Agent binnen Minuten Prototypen oder Szenarien erzeugt, der kritische Pfad jedoch in der menschlichen Validierung, im UX-Testing und im Verwerfen unbrauchbarer Optionen liegt; geschätzt wird hier nicht die Bauzeit, sondern die Validierungs- und Experimentierdauer¹³. Als dritte Kategorie verbleiben Standard- beziehungsweise Architektur-Stories für Hochrisiko- und Kernsystemarbeit, die tiefes Domänenwissen, komplexe Refactorings in Legacy-Systemen oder sicherheitskritische Schnittstellen betreffen, bei denen der Mensch das Low-Level-Design führt und der Agent lediglich eng überwachte Teilschritte ausführt².

Zweitens ersetzt der CIRK-Ausführungsstandard (sowie probabilistisches Cycle-Time-Forecasting im Sinne der #NoEstimates-Bewegung) das klassische Planning Poker⁵. Anstatt fiktive menschliche Programmierstunden oder Punkte zu raten, bewertet der verantwortliche Ingenieur ein Work Item (WI) anhand von vier Faktoren: Context Depth (Wie tief und weitverzweigt ist der benötigte Repository- und Domänenkontext?), Iteration Likelihood (Wie hoch ist die Wahrscheinlichkeit mehrfacher Regenerierungs-Schleifen wegen impliziter Anforderungen?), Review Risk (Wie aufwendig ist das menschliche Verständnis- und Sicherheits-Audit des generierten Diffs?) und K beziehungsweise Rollout Risk (Wie gravierend sind potenzielle Fehler im Produktionsbetrieb?)⁵.

Drittens führt das Agentic Agile-V-Framework (nach Christopher Koch) eine verpflichtende Klassifizierung jedes Tickets in risikobasierte Evidenz-Gates (Stufen L0 bis L4) ein⁶. Der Schätzwert eines Tickets definiert hierbei nicht mehr, wie lange ein Entwickler tippt, sondern welches formale Evidence Bundle (Nachweispaket) der Agent und der prüfende Ingenieur vorlegen müssen, bevor eine Änderung in den Hauptentwicklungszweig integriert werden darf⁶.

4. Methodische Referenzrahmen für Agentic Software Engineering (SE 3.0)

4.1 Strukturierte Mensch-Agenten-Dualität (SE4H und SE4A) und Spec-Driven Development

Um die Lücke zwischen unkontrolliertem „Vibe Coding“ und verlässlicher Ingenieurskunst zu schließen, hat die Software-Engineering-Forschung das Konzept des Structured Agentic Software Engineering (SASE / SE 3.0) sowie des Spec-Driven Development (SDD) entwickelt¹. Wie Ahmed E. Hassan et al. formalisieren, lässt sich das Gesamtsystem der Softwareentwicklung in der Ära autonomer Agenten als Funktion vierer Grundsäulen beschreiben²⁰:

SE 3.0 = f(Actors, Processes, Tools, Artifacts)

Der entscheidende Paradigmenwechsel besteht darin, dass jede dieser vier Säulen in zwei komplementäre Modalitäten aufgespalten wird: Software Engineering for Humans (SE4H) und Software Engineering for Agents (SE4A)¹⁸. Klassische Entwicklungsumgebungen (IDEs) und agile Boards wurden ausschließlich für menschliche Kognition und menschliche Lesegeschwindigkeit entworfen¹. In SE 3.0 arbeiten menschliche Ingenieure als „Agent Coaches“, Intent-Architekten und Evidenz-Auditoren in einer Agent Command Environment (ACE), die auf das Verfassen präziser Zielvorgaben, die Überwachung paralleler Agenten-Flotten, die Bearbeitung von Eskalationsanfragen (Consultation Request Packs – CRPs) und die Abnahme von Evidenzpaketen (Merge-Readiness Packs – MRPs) ausgerichtet ist¹. Die autonomen Agenten hingegen operieren in einer Agent Execution Environment (AEE), einer auf Maschineneffizienz, massive Parallelisierung, semantische Code-Suche, strukturelle Editoren und automatisierte Selbstüberwachung optimierten Laufzeitumgebung²⁰. Zwischen beiden Umgebungen entsteht ein strukturierter, bidirektionaler Dialog: Während Menschen über BriefingScripts und MentorScripts die Absicht und die methodischen Leitplanken in die AEE einspeisen, führen die Agenten die Implementierungsschritte aus, eskalieren bei Mehrdeutigkeiten über CRPs an die ACE zurück und legen nach erfolgreicher Ausführung ein formales MRP am menschlichen Approval Gate vor²⁰.

Damit mehrere Agenten und Menschen ohne gegenseitige Code-Überschreibungen zusammenarbeiten können, löst Spec-Driven Development (SDD) nach Jessica Diaz et al. das fundamentale Koordinations- und Vertrauensproblem¹. Wenn der Quellcode das primäre geteilte Artefakt darstellt, erzeugen parallele Agenten unweigerlich konfligierende Implementierungen¹. SDD erhebt daher die Spezifikation zum kanonischen, versionierten und ausführbaren Vertrags-Substrat (Operational Contract Substrate) zwischen Mensch und Maschine¹. Während das Agile Manifest Dokumentation zugunsten funktionierender Software abwertete, kehrt SDD dieses Verhältnis um: Aus einer vierstufigen Spezifikationshierarchie – bestehend aus stabilen Systemspezifikationen (normativer Projektkontext), aufgabenspezifischen Feature-Spezifikationen, abgeleiteten Artefakten (Code, Tests, Infrastruktur) und wiederverwendbaren prozeduralen Skills – werden sämtliche Code-Änderungen mit lückenloser Rückverfolgbarkeit (Traceability) generiert¹.

Gesteuert wird dieses System durch einen doppelten Harness (Steuerungsrahmen) gemäß der Formel Agent = Model + Harness¹. Die Forschung weist hier eine entscheidende ökonomische Asymmetrie nach: Der technische Harness (Kontextfenster-Management, Tool-Wrapper, Modell-Routing) ist flüchtig und verliert an Wert, sobald leistungsfähigere Basismodelle erscheinen¹. Der methodische Harness hingegen – in dem das Team seine Architekturprinzipien, Domänenregeln, Qualitätsnormen und vergangenen Architekturentscheidungen als Code hinterlegt – gewinnt im Zeitverlauf kontinuierlich an Wert und bildet das eigentliche intellektuelle Kapital der Organisation¹.

4.2 Agentic Agile-V und der SCOPE-V-Mikrozyklus

Während SDD und SE 3.0 das strukturelle Fundament legen, operationalisiert das Agentic Agile-V-Framework den konkreten Entwicklungsablauf durch eine Zweischichten-Architektur, die agile Iterationen mit der strengen Verifikationslogik des klassischen V-Modells verschmilzt⁶. Auf der Makroebene stellt Agile-V sicher, dass jedes Produktinkrement lückenlos von der Anforderung über den Entwurf und die Implementierung bis hin zum unabhängigen Verifikationsnachweis rückverfolgbar bleibt⁶. Auf der Mikroebene durchläuft jede einzelne, an einen Agenten delegierte Aufgabe den sechsstufigen SCOPE-V-Zyklus (Specify, Constrain, Orchestrate, Prove, Evolve, Verify)⁶.

Im ersten Schritt, Specify (Spezifizieren), erfolgt die Konvertierung der fachlichen Absicht in einen formal geprüften Task Brief (beziehungsweise ein BriefingScript in SE 3.0), der Zielsetzung, Scope, explizite Nicht-Ziele (Non-Goals), betroffene Module, Abhängigkeiten, Akzeptanzkriterien und geforderte Nachweise definiert²⁰. Hier gilt die eiserne operative Grundregel des Agentic Engineering, einen Agenten niemals direkt aus einem langen Chat-Verlauf heraus implementieren zu lassen, sondern ausschließlich auf Basis eines geprüften, strukturierten Briefings⁶. Empirische Studien zu Kontextdateien belegen, dass entscheidungsrelevante, strukturierte Instruktionen die Erfolgsrate signifikant steigern, während überflüssige oder unstrukturierte Chat-Historien die Agentenleistung aktiv verschlechtern⁶. Darauf folgt zweitens Constrain (Begrenzen), also die Definition harter architektonischer Leitplanken (Guardrails), bevor der Agent die erste Codezeile schreibt²¹. Dazu gehören Verbote unautorisierter Änderungen an öffentlichen APIs, das Sperren nicht betroffener Dateipfade, das Verbot neuer externer Bibliotheksabhängigkeiten ohne explizite Begründung sowie das Untersagen großflächiger Refactorings während einer isolierten Fehlerbehebung²¹.

Im dritten Schritt, Orchestrate (Orchestrieren), wird das prozedurale Arbeitsprotokoll für den Agenten festgelegt, was in SE 3.0 durch LoopScripts gesteuert wird²⁰. Der Agent wird verpflichtet, zuerst das bestehende Repository zu inspizieren, die aktuelle Architektur zusammenzufassen und einen detaillierten Änderungsplan vorzulegen, bevor Editieroperationen freigegeben werden²¹. Anschließend erfolgt die Umsetzung in kleinstmöglichen vertikalen Schnitten (Small Slices) inklusive einer automatisierten Zusammenfassung des Diffs und verbleibender Restrisiken²¹. Im vierten Schritt, Prove (Beweisen), muss der Agent die Korrektheit seiner Lösung durch ein risikoadaptives Evidence Bundle (in SE 3.0 als Merge-Readiness Pack – MRP bezeichnet) belegen¹⁸. Je nach Risikoklasse umfasst dieses Paket Unit-, Integrations- und Regressionstests, statische Codeanalysen, Typprüfungen, Sicherheits-Scans, formale Verifikationen oder in eingebetteten Systemen Hardware-in-the-Loop-Simulationen (HIL)⁶.

Der fünfte Schritt, Evolve (Weiterentwickeln), sorgt dafür, dass nach erfolgreichem Abschluss validierte Erkenntnisse systematisch in das Repository zurückgespielt werden²¹. Korrekturen eines menschlichen Entwicklers verpuffen nicht als einmaliger Fix, sondern werden als explizite oder vom Agenten abgeleitete Regeln (Explicit & Inferred Mentorship) in einem versionierten MentorScript („Mentorship-as-Code“) gespeichert, während veraltete oder schädliche Prompt-Instruktionen bereinigt werden¹⁸. Den Abschluss und zugleich den übergeordneten Rahmen bildet sechstens Verify (Verifizieren): Verifikation wird nicht als nachgelagerter Endpunkt verstanden, sondern als kontinuierlicher Prozess vor der Implementierung (Briefing-Review), während des Patchings, vor dem Merge, nach dem Deployment und im realen Produktionsbetrieb¹⁷. Formale Assurance Spines prüfen dabei deterministisch, ob die vorgelegte Evidenz kryptografisch und zustandsgebunden (State-Bound) exakt zum aktuellen Code-Digest und zur eingefrorenen Governance-Policy passt²².

5. Transformation der agilen Zeremonien und Rollenprofile

Die Integration autonomer Agenten als vollwertige – wenn auch nicht-menschliche und nicht haftbare – Teammitglieder erzwingt eine tiefgreifende Rekonfiguration sämtlicher agiler Zeremonien¹⁴. Wie die zwölfmonatige empirische Langzeitstudie des agentischen Scrum-Teams „Relentless Raptors“ (bestehend aus einem menschlichen Product Owner und acht spezialisierten KI-Agenten) belegt, wird Prozess-Governance in hybriden Teams nicht etwa überflüssig, sondern zur kritischen Überlebensbedingung²³. Menschliche Teams kompensieren schwache formale Prozesse kontinuierlich durch informelle Kommunikationskanäle wie Flurgespräche, Körpersprache, implizites Domänenwissen und soziales Gespür für überlastete Kollegen²³. Da KI-Agenten über keinerlei informelle Kanäle oder „Ambient Awareness“ verfügen, führt schwache Governance bei Agenten unmittelbar zu lautlosem Systemversagen (Silent Failure)²³.

Diese Beobachtung wird durch quantitative Varianzanalysen (nach Dochkina, 2026) untermauert: Beim Einsatz leistungsfähiger Sprachmodelle erklärt die Wahl des Koordinations- und Prozessprotokolls 44 Prozent der Varianz in der Ergebnisqualität, während die Wahl des konkreten KI-Modells lediglich 14 Prozent ausmacht²³. Nicht das beste Modell gewinnt, sondern die disziplinierteste soziotechnische Orchestrierung²⁴.

5.1 Vom Backlog Refinement zum Briefing Engineering und zur Intent-Architektur

Im traditionellen Scrum verbrachten Product Owner und Entwickler Stunden im Backlog Refinement damit, Epics in kleinteilige User Stories zu schneiden und im Team zu schätzen². In einer KI-zentrierten Lieferkette erweist sich dieses Vorgehen als kontraproduktiv, da das Aufteilen und Schätzen von Stories durch Personen, die das Low-Level-Design nicht selbst verantworten, zu massiven Reibungsverlusten und Intent Debt führt¹³. Das klassische Refinement transformiert sich daher zum Briefing Engineering (BriefingEng) und zur Intent-Architektur¹⁸.

An die Stelle isolierter Tickets tritt dabei das Konzept der Kontextkapsel (Context Capsule): Product Owner formulieren keine erschöpfenden technischen Einzel-Tickets mehr („Jira Hell“), sondern definieren übergeordnete Geschäftsabsichten (High-Level Intents), harte Invarianten und messbare Wert-Hypothesen, während spezialisierte Analyse-Agenten das Backlog in Echtzeit auf Abhängigkeiten, historische Fehlermuster und technische Schulden prüfen². Um gleichzeitig das Entstehen kognitiver Schulden auf Seiten der Ingenieure zu verhindern, wird die klassische Trennung zwischen entwerfendem Tech Lead und ausführendem Entwickler zugunsten eines Dev-Owned Low-Level Design (LLD) ohne Handoff-Verlust aufgehoben⁵. Derjenige Ingenieur, der einen Arbeitsstrang (Work Item) grob nach dem CIRK-Standard bewertet, erstellt mithilfe von KI-Templates und Repository-Kontext selbst das Low-Level-Design, diskutiert dieses im Peer-Walkthrough, schneidet die Arbeitspakete und steuert anschließend die Agenten bei der Implementierung⁵. Da der Kontext niemals die Person wechselt, bleibt das beim Design aufgebaute mentale Modell während der gesamten Ausführung und Verifikation intakt⁵. Geschichten (Stories) existieren in diesem Prozess weiterhin als Einheiten für Traceability, Tests und Reviews, doch das kollektive Schätzritual entfällt zugunsten eines zweistufigen Human Gates: Der verantwortliche Ingenieur friert zunächst nur die strukturellen Überschriften und Schnittstellen (Headlines) ein, und erst nach menschlicher Freigabe dieses ersten Gates generieren Agenten über das Model Context Protocol (MCP) die detaillierten BriefingScripts und Testgerüste²⁰.

5.2 Das Ende starrer Sprints: Dual-Track Continuous Flow und Agenten-Budgets

Das zweiwöchige Sprint-Raster von Scrum wurde für den biologischen Rhythmus menschlicher Arbeit konzipiert¹⁴. Wenn autonome Agenten jedoch 24 Stunden am Tag arbeiten und Implementierungszyklen im Minuten- oder Stundentakt abschließen, wirkt eine starre Zwei-Wochen-Timebox wie eine künstliche Bremse, die schnelle Validierung verhindert und am Sprint-Ende riesige Review-Halden auftürmt²⁵. In der Praxis löst sich der monolithische Sprint daher zugunsten von Zwei Geschwindigkeits-Spuren (Two Velocity Lanes) beziehungsweise einem Continuous Flow mit harten Review-Gates auf²⁵. Dabei werden Explorations- und Verifikationstakt gezielt entkoppelt: Während auf der schnellen Ausführungsspur (AEE) kontinuierlich Prototypen im entdeckbaren Regime sowie Zero-Point-Stories generiert und innerhalb von weniger als 48 Stunden am Kunden oder Domänenexperten validiert werden¹⁷, läuft auf der Governance-Spur (ACE) die streng getaktete Prüfung der Merge-Readiness Packs und die Architektur-Kohärenzsicherung²⁰.

Da die Grenzkosten der Code-Generierung gegen Null tendieren, unterliegen Teams zudem der Versuchung, unbegrenzt viele parallele Arbeitsstränge zu starten („More starts, fewer finishes“)³. Im erneuerten Planning wird folglich nicht mehr die menschliche Tipp-Kapazität geplant, sondern ein striktes Agenten- und Verifikationsbudget festgelegt¹⁴. Das Team entscheidet verbindlich, wie viele Agenten-Workstreams gleichzeitig aktiv sein dürfen, wie hoch das Token- und Compute-Budget bemessen ist und welcher Senior-Ingenieur welchem Agenten-Stream als verantwortlicher „Handler“ (Agent Coach) fest zugewiesen wird²⁰. Diese explizite Budgetierung schützt sowohl vor unkontrolliert explodierenden Cloud- und Token-Kosten als auch vor der kognitiven Überlastung der menschlichen Prüfer³. „Nein“ zu neuen Features zu sagen und den explodierenden Lösungsraum durch harte Restriktionen einzugrenzen, wird im Planning somit deutlich wichtiger als das Einplanen weiterer Tickets³.

5.3 Daily Stand-up als System-Puls und Eskalations-Triage

Das klassische 15-minütige Daily Scrum, in dem Entwickler reihum berichten, woran sie gestern programmiert haben und woran sie heute programmieren werden, verliert in hybriden Mensch-Agenten-Teams seine Funktion, da der Fortschritt von Code-Commits und Burndown-Charts durch Agenten in Echtzeit automatisiert erfasst und prognostiziert wird²⁵. Das Stand-up wandelt sich stattdessen zum täglichen „System-Puls“ (System Pulse) und zur Eskalations-Triage²⁰.

In reifen SE-3.0-Umgebungen sind Agenten so konfiguriert, dass sie bei unklaren Anforderungen, widersprüchlichen Architekturregeln oder hochriskanten Trade-offs nicht blind drauflos halluzinieren, sondern die Ausführung an einem Prozess-Gate anhalten und ein strukturiertes Consultation Request Pack (CRP) an das menschliche Team eskalieren²⁰. Der tägliche System-Puls dient primär dazu, diese eskalierten Architekturentscheidungen im Team synchron zu klären und blockierte Agenten-Flotten wieder freizugeben²⁰. Parallel dazu fungiert die Zeremonie als Schutzmechanismus für die menschliche Aufmerksamkeit: Da Entwickler im KI-gestützten Modus bis zu 47 Prozent mehr Pull Requests pro Tag parallel berühren⁷, verschiebt sich das XP-Prinzip der „nachhaltigen Geschwindigkeit“ (Sustainable Pace) hin zu einer nachhaltigen kognitiven Last (Sustainable Cognitive Load)³. Im System-Puls prüft das Team daher gezielt, wo sich Merge-Readiness Packs in der Verifikations-Warteschlange stauen und wo menschliche Reviewer durch zu hohe Kontextwechsel-Frequenzen Gefahr laufen, in Cognitive Surrender zu verfallen³.

5.4 Sprint Review und Definition of Done: Evidenzbasierte Abnahme statt oberflächlicher Plausibilität

Keine agile Struktur muss so radikal verschärft werden wie die Definition of Done (DoD) und das Sprint Review¹⁴. In der klassischen Agilität galt eine User Story oft als erledigt, wenn die Software im Demo-System ausführbar war und grundlegende Akzeptanztests bestand¹. Unter Agentic AI führt diese schwache DoD direkt in schwere Qualitätskrisen: Empirische Fehlerprotokolle zeigen, dass Agenten häufig oberflächliche Lösungen generieren, die gemockte Unit-Tests problemlos bestehen, aber an der Modellgrenze, im realen Browser oder unter Produktionslast kollabieren¹⁸. Zudem kann ein KI-Agent im Gegensatz zu einem menschlichen Entwickler weder juristisch noch organisatorisch für Produktionsausfälle oder Sicherheitslücken haftbar gemacht werden¹⁴.

Die erneuerte Abnahmelogik folgt daher dem strengen Grundsatz, dass Agenten-Output niemals akzeptiert wird, weil er plausibel aussieht, sondern ausschließlich, weil er verifizierbare Evidenz vorlegt, die seinem Risikolevel entspricht⁶. Jedes von einem Agenten bearbeitete Ticket erfordert vor der Abnahme ein vollständiges Merge-Readiness Pack (MRP), das End-to-End-Tests in realen statt gemockten Umgebungen, Mutations- und Regressionstests, Sicherheits-Audits sowie ein Diff-Summary mit ausgewiesenen Restrisiken umfasst¹⁸. Um Anbieter-Biases – wie die 91-prozentige Selbst-Review-Quote innerhalb desselben Bot-Ökosystems¹¹ – zu durchbrechen, verlangen moderne Governance-Pipelines zudem eine unabhängige Zweitmeinung durch ein konkurrierendes Sprachmodell (Cross-Model Adversarial Review), die gezielt nach stillen Performance-Verletzungen und Logikfehlern sucht⁴. Darüber hinaus beinhaltet die neue DoD ein verbindliches menschliches Comprehension Gate: Der verantwortliche Ingenieur muss im Review in der Lage sein, die Architektur- und Zustandslogik des generierten Codes ohne Rückgriff auf den Agenten zu erklären, um das Einschleusen von Cognitive Debt zu verhindern³. Im entdeckbaren Anforderungsregime dient das Review schließlich nicht mehr der bloßen Abnahme eines einzelnen gebauten Inkrements, sondern der vergleichenden Auswahl und N-Versionen-Synthese mehrerer parallel vom Agenten generierter Lösungsentwürfe, etwa indem das Team anweist, die Benutzeroberfläche aus Entwurf 1 mit der Backend-Logik aus Entwurf 2 zu kombinieren¹⁸.

5.5 Sprint Retrospektive: Diagnostik maschineller Fehlermodi und Evolution des Harness

Die klassische Sprint Retrospektive konzentrierte sich fast ausschließlich auf zwischenmenschliche Teamdynamik, Kommunikation und psychologische Sicherheit¹⁴. In einem hybriden Mensch-Agenten-System greift diese Agenda zu kurz; die Retrospektive muss zu einer soziotechnischen Fehlerdiagnostik und einer Evolutionszeremonie für den methodischen Harness ausgebaut werden¹. Im Zentrum der neuen Retrospektive steht die diagnostische Frage, woran die eingesetzten Agenten im abgelaufenen Zyklus gescheitert sind, wo sie architektonisch gedriftet sind und welche impliziten Annahmen in den Spezifikationen fehlten¹⁴.

Anstatt Fehlverhalten von Agenten durch spontane manuelle Code-Korrekturen zu überdecken, analysiert das Team systematisch die aufgezeichneten Reasoning Traces und Ausführungsprotokolle der Agenten²⁶. Jedes identifizierte Defizit mündet unmittelbar in den Evolve-Schritt des SCOPE-V-Zyklus, indem das Team seine versionierten MentorScripts, Architektur-Regelwerke und BriefingScript-Vorlagen im Sinne von „Mentorship-as-Code“ aktualisiert¹⁸. Konventionen, die ein Agent im letzten Zyklus ignoriert oder umgangen hat, werden aus bloßen Textdokumenten entfernt und als harte, automatisierte Prozess-Gates – etwa als Linter-Regeln, Architektur-Fitness-Funktionen oder CI-Blocker – in die Pipeline eingebaut, da Agenten informelle Konventionen systematisch umgehen³. Durch diese Institutionalisierung des Lernens in ausführbaren Artefakten wird sichergestellt, dass kritisches Prozesswissen nicht zwischen verschiedenen Agenten-Sitzungen verloren geht, sondern den methodischen Harness der Organisation dauerhaft stärkt¹.

6. Synthese und Implikationen für die Engineering-Governance

Die wissenschaftliche Untersuchung der Agilität im Zeitalter von Agentic AI führt zu einem eindeutigen Befund: Die Annahme, das Schätzen und Klassifizieren von Aufgaben sei hinfällig, weil autonome Agenten den Implementierungsengpass beseitigt hätten, greift einseitig zu kurz und führt in der Praxis direkt in das empirisch nachgewiesene Produktivitätsparadoxon¹. Zwar hat sich die Ökonomie der reinen Code-Erzeugung radikal gewandelt – wodurch das Schätzen menschlicher Tipp-Geschwindigkeit in Form traditioneller Story Points tatsächlich zur nutzlosen Bürokratie („Agile Theater“) verkommt². Doch nach den Gesetzen der Engpasstheorie und Amdahls Gesetz ist der Flaschenhals nicht aus der Softwareentwicklung verschwunden; er hat sich lediglich von der syntaktischen Implementierung hin zur Spezifikationspräzision, zur Architekturentscheidung, zur Verifikationskapazität und zur menschlichen Kognition verlagert¹.

Für Technologieorganisationen und Software-Engineering-Teams vollzieht sich damit erstens ein fundamentaler Übergang von Labor Agility zu Decision Agility: Agilität im Zeitalter von SE 3.0 misst sich nicht mehr daran, wie schnell ein Team Zeilen von Quellcode produziert oder Story Points abbrennt, sondern wie präzise es Probleme formuliert, nicht-wertschöpfende Optionen frühzeitig verwirft und generierte Systeme verifiziert². Die primäre Wertschöpfung des Ingenieurs verlagert sich vom Schreiben imperativer Programmlogik hin zum Briefing Engineering und zur Kuratierung des methodischen Harness¹. Zweitens erfordert diese Transformation den konsequenten Ersatz klassischer Aufwandsschätzungen durch eine Risiko- und Kontext-Klassifizierung: Teams sollten das Schätzen menschlicher Programmieraufwände in Story Points einstellen und stattdessen jedes Arbeitspaket vorab nach seinem Anforderungsregime (wissbar vs. entdeckbar), seiner Kontexttiefe und seinem Verifikationsrisiko gemäß CIRK-Standard beziehungsweise den Risikostufen L0 bis L4 klassifizieren¹⁷. Diese Klassifizierung bestimmt unmittelbar das erforderliche Evidence Bundle und schützt die Organisation vor dem unbemerkten Aufbau von Verifikations- und Intentionsschulden⁶.

Drittens erzwingt die Natur autonomer Systeme eine vertragliche Formalisierung statt informeller Konversation: Da Agenten keine informellen menschlichen Korrekturmechanismen besitzen und Konventionen ohne harte technische Schranken umgehen, führt unstrukturiertes „Vibe Coding“ im Teammaßstab zum Kollaps der Wartbarkeit¹. Erfolgreiche Mensch-Agenten-Kollaboration erfordert die Einführung von Spec-Driven Development (SDD) und SCOPE-V, bei denen Agenten ausschließlich auf Basis versionierter Spezifikationsverträge (BriefingScripts, MentorScripts) agieren und ihre Ergebnisse durch reproduzierbare Merge-Readiness Packs beweisen müssen¹. Viertens schließlich rückt der aktive Schutz des menschlichen Systemverständnisses in das Zentrum der Engineering-Governance: Die größte langfristige Gefahr agentischer Softwareentwicklung liegt nicht in syntaktisch fehlerhaftem Code, sondern in der schleichenden Aushöhlung des menschlichen Architekturverständnisses durch Cognitive Debt und Cognitive Surrender¹². Agile Zeremonien müssen daher als kognitive Schutzmechanismen neu interpretiert werden: Durch Dev-Owned Low-Level Design, den Einsatz von KI zur konzeptionellen Exploration statt zur blinden Delegation sowie durch harte Verständnis-Gates in der Definition of Done stellen Organisationen sicher, dass die Geschwindigkeit der Maschinen nicht die Urteilskraft und Verantwortungsfähigkeit der Menschen überrollt⁶.

Quellenverzeichnis