Ausführlicher Leitfaden von **Anthropic** von **Louis Claxton** (Applied-AI-Team), veröffentlicht am **21. August 2026** im claude.com-Blog: eine angegebene Lesezeit von **40 Minuten**, rund **64.000 Zeichen**, präsentiert als Sammlung von *Plays*, die aus der Arbeit des Teams mit seinen Kunden stammen. (A) Die Diagnose: Da Code nicht mehr der Engpass ist, verschiebt sich dieser auf die Phasen vor und nach dem Bau (Planung, Review/Test, Deployment); zeilenweise Kontrollen greifen nicht mehr, sobald der Agent den Großteil des Diffs schreibt, und die Governance-Kosten steigen, da Ausnahmen weiterhin über periodische Ausschüsse laufen. (B) Die Antwort: sechs Phasen (Plan, Design, Build, Test, Deploy, Maintain), organisiert als **Schleife** statt als Kette, jede endet mit einem **committeten Artefakt**, das die nächste Phase liest — `intent.md`, `spec.md`, `plan.md`, der Diff und seine Tests, der PR und seine Befunde, der Vorfallbericht. (1) Institutionelles Wissen wird zu versionierten Dateien: `CLAUDE.md`, Skills, `REVIEW.md`, `bands.yaml`. (2) Governance gliedert sich in zwei Schichten, wobei der Skill als beratende Kontrolle positioniert ist und der Hook als deterministische Schicht dahinter. Funktionstrennung wird als Invariante festgelegt — der Agent, der den Code schreibt, kann ihn nicht genehmigen —, und der Beitrag schließt mit *„The loop keeps running. Human judgement stays above it.“* Der Korpus enthält bereits [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] zur Sicherheitsseite desselben Zyklus sowie [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] zur selben Sechs-Phasen-Gliederung aus Sicht eines Wettbewerbers.
#AI-native SDLC#software development lifecycle#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
SFEIR-Analyse (Stimme eines Beratungsunternehmens, „die Lesart eines Ingenieurs“), die zwei zu oft vermischte Frameworks artikuliert: den **SDLC** (Software Development Life Cycle — *die Software korrekt und zuverlässig bauen*) und den **PDLC** (Product Development Life Cycle — *das richtige Produkt bauen und am Markt erfolgreich sein*). Zentrale These: Die beiden Zyklen sind keine Konkurrenten, sondern **verschachtelt** — der SDLC ist die Teilmenge des PDLC, **untergebracht in dessen Entwicklungsphase**; wenn ein Produktteam die „Build“-Phase erreicht, läuft darin ein vollständiger SDLC-Zyklus (Design → Build → Test → Review → Deployment) ab. Der SDLC ist standardisiert (**ISO/IEC/IEEE 12207**, Ausgaben 2017 und 2026), mit seiner Modell-Genealogie (Waterfall 1970, V-Modell, iterativ/spiralförmig, **Agile 2001**, **DevOps/DevSecOps ab 2009**) und seinen **DORA**-Metriken (Durchsatz, Stabilität, MTTR, Change-Failure-Rate). Der PDLC, als übergeordneter Zyklus, reicht von **Ideation/Discovery** bis zum **Marktrückzug** (nicht zu verwechseln mit dem marketingbezogenen **PLC** von Theodore Levitt, 1965, der eine *kommerzielle Kurve* beschreibt, keine *organisierte Arbeit*: „der PLC beobachtet eine Kurve; der PDLC organisiert Arbeit“). **Wendepunkt**: Der SDLC adressiert nativ **nur eines von vier Risiken** — über **Marty Cagans „Four Big Risks“**-Framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business Viability → PM) — eine Organisation, die im SDLC exzellent, aber gegenüber dem PDLC blind ist, produziert „Software, die niemand will“ — John Cutlers **„Feature Factory“** (Erfolg gemessen am Output, nicht am Outcome). **Warum KI alles verändert**: Generative KI **komprimiert den SDLC** (Google/JetBrains-Daten, Mai 2026: **~85 % der Entwickler** nutzen regelmäßig Coding-Agenten, **~41 % des neuen Codes** ist KI-generiert; die Implementierung schrumpft von Wochen auf Stunden), sodass sich der **Engpass stromaufwärts verlagert** — die Entscheidung, *was* gebaut werden soll (Marty Cagan, April 2026: „wenn die Kosten der Auslieferung einbrechen, verlagert sich der Engpass zur Discovery“). Konsequenzen: DORA 2025 (~5.000 Fachleute, 90 % KI-Adoption) zeigt eine **positive Korrelation mit dem Durchsatz, aber eine negative mit der Stabilität** (mehr unvalidierte Features bedeuten Instabilität und Nacharbeit); Andrew Ng (AI Startup School, Juli 2025) berichtet von Teams, die das **Verhältnis „1 PM auf 4 Ingenieure“ zu „2 PMs auf 1 Ingenieur“ umkehren**; und mit **Spec-driven Development** wird die Grenze zwischen PDLC/SDLC **durchlässig** (die Produktspezifikation wird direkt von Agenten ausführbar). **Was ein CIO mitnehmen sollte**: Ein augmentierter SDLC wird zum **Marktstandard, nicht zum Differenzierungsmerkmal** — die Schnittstelle zum Produkt muss instrumentiert, **ausführbare Spezifikationen** als Input verlangt, technische Metriken mit Outcome-Metriken abgeglichen und die Rolle des „Feature-Lieferanten“ **abgelehnt** werden. Für einen CPO: Die Verlagerung des Engpasses zur Discovery ist zugleich eine **Aufwertung** (Produkturteil wird wieder knapp) und eine **Handlungsaufforderung** (Discovery industrialisieren, um mit dem SDLC gleichzuziehen). SFEIRs eigenes Framework („Designing and building in the agentic era“ — **11-Phasen-Zyklus** + **Software Factory 10x**) wird als Antwort auf der Engineering-Seite positioniert, wobei die **Verknüpfung der beiden Zyklen** als nächster Hebel gilt. Fazit: „während Code zur Commodity wird, verschiebt sich die Marge hin zu Produkturteil und Governance.“
Ein arXiv-Paper (cs.SE) von Martin Monperrus, das für den SDLC eine radikale These vertritt: Coding-Agenten haben eine Fähigkeitsschwelle überschritten, sodass menschliches Code-Review keine notwendige Komponente einer Qualitätspipeline mehr ist. Zwei Thesen: (1) autonome LLM-basierte Systeme erreichen alle Ziele des Reviews (Fehlererkennung, Qualität, Compliance) bei geringeren Kosten und höherem Durchsatz; (2) das hybride Modell „der Agent schreibt, der Mensch reviewt“ ist nicht haltbar — es gewährleistet weder echte Qualität noch skaliert es mit der KI-Geschwindigkeit und erzeugt ein „trügerisches Sicherheitsgefühl“. Monperrus stellt der inspection de Fagan (1976) eine multi-agentenbasierte adversarial verification pipeline gegenüber (Generator-Agent + unabhängige Reviewer-Agenten + Tests/formale Methoden + abstimmungsbasierter Konsens). Der Mensch konzentriert sich auf die Spezifikation, architektonische Trade-offs, die Freigabe kritischer Domänen sowie Grenzfälle. Empfehlungen: zunächst Pilotierung an risikoarmen Komponenten, Messung Agent vs. Mensch, explizite Ablehnungsentscheidungen.
Atlassian-Datenstudie (Inside Atlassian), die den tatsächlichen Ertrag eines **AI-native SDLC** misst, der von **Rovo Dev** angetrieben wird. Bei 3.400 Repositories von 2.500 Kunden (ein Quasi-Experiment mit Propensity-Score-Matching) mergen adoptierende Repositories **19 % mehr PRs pro Monat**; bis zu **37–51 %** bei Repositories mit geringer/mittlerer Aktivität und **59–87 %**, wenn **3 bis 5 Mitglieder** des Teams das Tool nutzen. Auf der Effizienzseite sparen Entwickler **2–3 Std./Woche** (≈10 % der 24 Stunden, die für Coding und Review aufgewendet werden), d. h. 20–30 Stunden/Woche, die bei einem Team von 10 reinvestiert werden. Die These: Solows (1987) „Produktivitätsparadox“ auflösen, indem man von **Nutzungsmetriken** (Tokens) zu **Wirkungsmetriken** (Durchsatz, eingesparte Zeit, Fehlerquote, Zufriedenheit) übergeht. Empfehlung: mit einem **Team** (nicht einer Einzelperson) beginnen und 2–3 Monate später messen.