← Field Notes ·

The Software Development Lifecycle Is Dead

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.

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

Kritische Einordnung

Was hält stand

Was man einordnen muss

Diskussionsfragen für das nächste Lab

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.