Anthropic hat am 21. August 2026 den AI-Native SDLC Playbook veröffentlicht. Der Text ist lesenswert. Er beschreibt, wie sich der Software Development Lifecycle verändert, wenn Agenten den grössten Teil des Codes schreiben. Die Kernaussage: Code ist nicht mehr der Engpass. Die Engpässe liegen jetzt links und rechts vom Build, also bei Planung, Review, Test und Deployment.

Dem stimme ich zu. Aber beim Lesen ist mir etwas aufgefallen. Requirements Engineering kommt im Playbook fast nicht vor. Und dort, wo es vorkommt, wird es auf einen Prompt reduziert.

Was das Playbook sagt

Das Playbook beschreibt sechs Stages: Plan, Design, Build, Test, Deploy, Maintain. Jede Stage endet mit einem committeten Artefakt, das die nächste Stage liest: intent.md, spec.md, plan.md, der Diff, der PR mit Review-Findings, der Incident Record. Die Idee der versionierten Artefakte als Audit Trail finde ich gut. Sie deckt sich mit dem, was ich im AI Unified Process (AIUP) seit längerem propagiere: Spezifikationen gehören ins Repository, neben den Code.

Für die Anforderungen sind zwei Stages relevant.

In Stage 1 (Plan) beschreibt eine Person ihre Idee in eigenen Worten. Claude stellt dabei die Fragen, die sonst ein Analyst stellen würde: Scope, Nutzer, Constraints, Erfolgskriterien. Das Ergebnis ist ein intent.md. Der Product Owner korrigiert und committet es.

In Stage 2 (Design) werden Requirements und Design in eine einzige Session zusammengelegt. Claude liest das intent.md, wendet die Skills der Organisation an (Brand, Security, Compliance, UX) und schreibt ein spec.md. Der Product Owner schreibt die Spec nicht mehr. Er reviewt sie nur noch.

Die Tabelle „The shifts“ bringt es auf den Punkt. Traditionell: Anforderungen werden in Workshops gesammelt und von Analysten ausformuliert. AI-native: Anforderungen und Design werden in einer Session mit einem Agenten komprimiert.

Was fehlt

Wer Requirements Engineering kennt, vermisst hier einiges.

Es gibt nur einen Stakeholder. Das Playbook spricht vom „Originator“, einer einzelnen Person mit einer Idee. In echten Projekten gibt es mehrere Fachbereiche mit unterschiedlichen und oft widersprüchlichen Interessen. Diese Konflikte zu erkennen und zu lösen ist die eigentliche Arbeit im Requirements Engineering. Ein Brainstorming mit einem Agenten ersetzt das nicht.

Es gibt keine Analyse. Der Schritt von „was jemand will“ zu „was das System tun muss“ ist im Playbook ein einzelner Prompt. Vollständigkeit, Konsistenz, Testbarkeit werden nicht als eigene Aktivitäten behandelt. Das Playbook vertraut darauf, dass das Modell diese Fragen selbst stellt.

Es gibt keine Struktur. Das spec.md ist ein Prosadokument. Kein Use Case, kein Domänenmodell, keine Business Rules. Was drin steht, hängt vom Prompt und von den Skills der Firma ab. Für ein kleines Feature reicht das. Für ein Bestellsystem mit 40 Use Cases und einem Datenmodell mit 60 Entitäten reicht das nicht.

Nicht-funktionale Anforderungen tauchen nur indirekt auf. Sie sind in Skills versteckt (Security, Compliance). Performance, Verfügbarkeit, Datenschutz als explizite, messbare Anforderungen kommen nicht vor.

Traceability ist auf Git-Timestamps reduziert. Das Playbook misst, wie schnell aus einem intent.md ein spec.md wird, und wie oft die Spec nach Build-Start noch geändert wird. Das misst Geschwindigkeit und Rework. Es misst nicht, ob die Spec die Anforderungen abdeckt oder ob ein Test zu einer Anforderung gehört.

Die Messgrössen sind verräterisch. Der Leading Indicator für Stage 1 ist die Zeit bis zum committeten intent.md. Die Erwartung: von Wochen auf Stunden. Das ist ein Ziel für Geschwindigkeit, nicht für Qualität.

Warum das ein Problem ist

Man kann dem Playbook zugutehalten, dass es für grosse Unternehmen geschrieben ist. Dort bedeutet Requirements Engineering oft, dass ein PRD durch drei Gremien wandert und am Ende niemand mehr weiss, was der Fachbereich eigentlich wollte. Dagegen ist „eine Person, ein Agent, am ersten Tag versioniert“ ein echter Fortschritt.

Aber die Grundannahme des Playbooks ist falsch, oder zumindest unvollständig. Sie lautet: Code ist nicht mehr der Engpass, also kann alles davor komprimiert werden.

Ich würde das Gegenteil sagen. Wenn Code billig wird, bleibt nur ein Hebel übrig: die Qualität der Anforderungen. Ein Agent, der in einer Stunde 5000 Zeilen Code aus einer schlechten Spec generiert, produziert in einer Stunde 5000 Zeilen falschen Code. Und der Product Owner, der laut Playbook die Spec nur noch reviewt, sieht die Lücken nicht, weil er die Spec nicht selbst durchdacht hat.

Das Playbook selbst liefert den Beweis. Der Lagging Indicator für Stage 2 zählt Spec-Änderungen nach Build-Start. Wenn diese Zahl relevant genug ist, um gemessen zu werden, dann weiss Anthropic, dass das Problem existiert.

Was stattdessen

Meine Antwort ist der AI Unified Process (AIUP). AIUP stellt Requirements Engineering ins Zentrum und macht es für Agenten nutzbar:

  • Use Cases statt Prosa. Jeder Use Case hat Akteure, Vorbedingungen, Hauptszenario, Alternativszenarien, Nachbedingungen und Business Rules. Ein Agent kann daraus Code und Tests ableiten. Ein Mensch kann es reviewen, weil es eine bekannte Struktur hat.
  • Ein Entity Model vor dem Code. Entitäten, Beziehungen, Datentypen, Validierungsregeln. Das Datenmodell ist das Fundament jeder Business-Applikation, und es entsteht nicht als Nebenprodukt eines Prompts.
  • Explizite nicht-funktionale Anforderungen und Constraints. Messbar, versioniert, im Repository.
  • Traceability von der Anforderung bis zum Test. Ein @UseCase("UC-007") am Test ist mehr wert als ein Commit-SHA in Jira.

Der AI Unified Process übernimmt vom Playbook, was gut ist: Artefakte im Repository, Skills als institutionelles Wissen, Plan Mode vor dem Build, Hooks als Guardrails. Aber es lässt den Schritt zwischen Idee und Code nicht weg. Es macht ihn explizit.

Fazit

Das AI-Native SDLC Playbook ist ein guter Text über Build, Test, Deploy und Maintain. Für Plan und Design ist es dünn. Anthropic hat Requirements Engineering nicht vergessen. Aber sie haben es auf das reduziert, was ein Agent in einer Session leisten kann.

Das reicht für ein Feature. Für ein System reicht es nicht.

Mehr zum AI Unified Process unter unifiedprocess.ai.