The Software Development Lifecycle Is Dead

20. Februar 2026 · Jan Musiedlak

TL;DR

AI-Agenten haben den klassischen SDLC nicht beschleunigt — sie haben ihn aufgelöst. Aus sequenziellen Phasen wird ein enger Loop: Intent + Context → Agent builds → Observe → Repeat. Was bleibt: Context Engineering und Observability.

Reasoning Seed

Spannung: Wenn der Loop Intent → Agent → Observe den SDLC ersetzt — wie definieren wir dann Engineering-Qualität?

Einordnung: Context Engineering ersetzt klassisches Coding als Kernkompetenz — das verändert, welche Rollen wir in Produktteams besetzen und wie wir Fractional-Kapazität einsetzen.

Wesentliche Insights

1 — Prozesskollaps statt Prozessbeschleunigung

AI-Agenten machen den SDLC nicht schneller — sie eliminieren die sequenziellen Handoffs. Requirements, Design, Implementation, Testing, Review, Deployment: Alle Phasen fallen in einen simultanen Generierungs- und Verifikationszyklus zusammen. Tane stellt den alten Ablauf (Requirements → Design → Code → Test → Review → Deploy → Monitor) dem neuen gegenüber: Intent + Context → Agent → Build + Test + Deploy → Observe → Loop.

2 — Von Execution zu Context Engineering

Die Aufgabe des Engineers verschiebt sich vom Code-Schreiben zum Bereitstellen von Kontext und Richtung. Tanes Schlüsselsatz: “The SDLC is dead. The new skill is context engineering. The new safety net is observability.” Die Qualität agent-getriebener Entwicklung hängt vollständig von der Kontextqualität ab — nicht von Prozess oder Zeremonie.

3 — Zeremonie als Liability

Sprint Planning, Estimation, Pull-Request-Reviews — alles Prozessrituale, die im agent-getriebenen Workflow zum Hindernis werden. Tane nennt die PR-Queue explizit einen “Fake Bottleneck”, der nur existiert, weil menschliche Rituale auf maschinelle Workflows gezwungen werden. Wenn Agenten hunderte PRs täglich generieren, wird Human Review zum Engpass statt zur Qualitätskontrolle.

4 — Observability als Bindegewebe

Monitoring ist die einzige Phase, die überlebt — aber sich fundamental transformieren muss. Traditionelle Dashboards für menschliche Interpretation reichen nicht, wenn Agenten hunderte Änderungen täglich deployen. Die Observability-Schicht wird zum Feedback-Mechanismus, der die gesamte Schleife antreibt — nicht eine Phase am Ende, sondern das Bindegewebe des gesamten Systems.

5 — AI-native Engineers als Existenzbeweis

Engineers, die nach dem Launch von Cursor ihre Karriere begonnen haben, kennen Sprint Planning und mehrtägige Pull-Request-Reviews gar nicht. Sie “bauen einfach Dinge” — direkt von Beschreibung zu ausgeliefertem Feature. Tane sieht das nicht als Defizit, sondern als empirische Validierung seiner These.

6 — Jede SDLC-Phase einzeln betrachtet

Requirements: Werden fluide — Nebenprodukt der Iteration, nicht Vorab-Festlegung
System Design: Von präskriptiver Planung zu Echtzeit-Entdeckung mit dem Agenten
Implementation: Agenten schreiben Features mit Error Handling, Types, Edge Cases — Engineers steuern und reviewen
Testing: Simultan mit Code generiert, TDD wird Default-Verhalten des Agenten
Deployment: Continuous Deployment hinter Feature Flags, mit progressiven Rollouts und automatischen Rollbacks

Einordnung

Die Kommentierung erfolgt aus der Perspektive von Product Design und Design Operations — also aus einer Disziplin, die im Originaltext nicht vorkommt. Das ist zugleich die Stärke und die Grenze dieser Einordnung: Sie kann beurteilen, was der Prozesskollaps für interdisziplinäre Produktarbeit bedeutet, aber nicht, wie sich die technischen Implikationen (CI/CD, Agent Validation, Observability-Infrastruktur) im Detail auswirken. Ein Staff Engineer würde die Machbarkeit der Tight-Loop-These anders bewerten; ein Organisationsentwickler würde stärker nach den institutionellen Bedingungen fragen, unter denen solche Veränderungen überhaupt stattfinden können.

Kritische Einordnung

Was hält stand

Die Beobachtung, dass sequenzielle Phasen kollabieren, deckt sich mit der Praxis vieler AI-augmented Teams
Der Shift von Execution zu Context ist empirisch beobachtbar — auch in unserer eigenen Arbeit
Observability als Feedback-Mechanismus statt Dashboard-Theater ist ein starker, praxisnaher Punkt
Das “Tight Loop”-Modell beschreibt akkurat, wie viele von uns heute bereits arbeiten

Was man einordnen muss

Tane schreibt aus der Perspektive von Greenfield-Softwareentwicklung. Regulierte Umgebungen (Govtech, Finanz, Medizin) haben Review-Pflichten, die nicht optional sind
Die Abschaffung von Code Review ist die provokanteste These — adversarial Agent Validation ist noch nicht industriereif
“AI-native Engineers” sind bisher eine sehr kleine Kohorte; die Generalisierung ist gewagt
Das Modell setzt hohe Codebase-Qualität und gute Kontextinfrastruktur voraus — die meisten Organisationen haben beides nicht
Product Design fehlt komplett: “Design” wird nur als System Design (Architektur) adressiert — User Research, UX, Service Design kommen nicht vor
Kein Wort über Organisationsstruktur, Teamtopologien oder wie Rollen sich institutionell anpassen

Diskussionsfragen

01 Context Engineering als Design-Kompetenz: Wenn Kontext die zentrale Ressource wird — ist das nicht genau das, was gute Designer und Product People schon immer gemacht haben? Nutzerkontext, Businesskontext, technische Constraints zusammenbringen? Wie positionieren wir das als Lab?

02 Wo bleibt Product Design? Tane behandelt nur Architektur. Was passiert mit User Research, UX, Service Design in einer agent-getriebenen Welt? Kollabieren diese Phasen ebenfalls — oder werden sie wichtiger?

03 Govtech-Realitätscheck: Unsere Govtech-Projekte haben Dokumentationspflichten, Barrierefreiheitsanforderungen, Auditierbarkeit. Wie würden wir die “Tight Loop” adaptieren, ohne die regulatorischen Anforderungen zu verletzen?

04 Fake Bottleneck oder echte Qualitätssicherung? Ist die PR-Queue wirklich ein reines Ritual — oder gibt es Kontexte, in denen menschliche Reviews eine Funktion haben, die Agenten (noch) nicht abdecken können?

05 Observability als Geschäftsmodell: Wenn Observability das Bindegewebe wird, gibt es hier eine Opportunity? Können wir “Design Observability” als Dienstleistung denken — die Fähigkeit, zu messen, ob ein Produkt tut, was es soll?

Quellen

Glossar

Context Engineering Die Kompetenz, einem KI-Agenten den richtigen Kontext bereitzustellen — statt selbst Code zu schreiben. Umfasst das Formulieren von Intent, das Strukturieren von Anforderungen und das Kuratieren relevanter Informationen für den Agenten.

Observability Die Fähigkeit, das Verhalten eines Systems aus seinen Outputs zu verstehen. Im agent-getriebenen Workflow wird Observability vom Monitoring-Dashboard zum zentralen Feedback-Mechanismus, der den gesamten Build-Observe-Zyklus antreibt.

Feature Flag Ein Mechanismus, der es erlaubt, Funktionen im laufenden Betrieb ein- oder auszuschalten — ohne neues Deployment. Ermöglicht progressive Rollouts und automatische Rollbacks bei Problemen.

Tight Loop Ein komprimierter Entwicklungszyklus, in dem Intent, Build, Test, Deploy und Observe nahezu simultan ablaufen. Ersetzt den sequenziellen SDLC mit seinen getrennten Phasen und Handoffs.

Kuratiert von Jan Musiedlak · Panoptia Februar 2026

Reaktionen

David Latz 26.02.2026

Zu Diskussionsfrage 02

Tane beschreibt den Kollaps des SDLC aus Engineering-Sicht — aber Product Design kommt nicht vor. Dabei verschiebt sich genau hier der Hebel: Wenn Code durch AI-Agenten zur Commodity wird, liegt der Differenziator bei Product Adoption, Product Market Fit und dem Erkennen echter User Needs. Das ist Product Design, und sein Gewicht steigt.

Für die Design-Rolle bedeutet das eine massive Verbreiterung. In eine Richtung tiefer in die Umsetzung — der Coding Designer, der direkt am Produkt iteriert. In die andere Richtung stärker an den Anfang: herausfinden, was wir bauen. Weil die Baukosten fallen, steigen die relativen Kosten falscher Richtungsentscheidungen.

Discovery ist dabei AI-augmentierbar — virtuelle User, Deep Research, Synthese im großen Maßstab — aber nicht ersetzbar. Direkte Interaktion mit echten Menschen, beobachten wie sie mit einer Lösung umgehen, verstehen wie sich ihr Kontext verändert: das bleibt menschlich. AI beschleunigt Discovery, indem sie mehr Qualität in der gleichen Zeit ermöglicht, nicht indem sie den Kontakt ersetzt.

Das Stingray-Modell (Board of Innovation) bildet diese Realität besser ab als der Double Diamond: Problem- und Lösungsraum werden simultan exploriert — Train, Develop, Iterate — mit AI als Beschleuniger in jeder Phase. Der Double Diamond mit seinen wochenlangen Discover-Phasen verliert gegen diesen engeren Loop.

Eigene Perspektive beitragen? Anleitung auf GitHub