# claxton-anthropic-ai-native-sdlc-playbook-2026-08-21

## Veille

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.

## Titre Article

The AI-Native SDLC playbook: How to transform your software development lifecycle with AI—stage by stage

## Date

2026-08-21

## URL

https://claude.com/blog/the-ai-native-sdlc-playbook

## Keywords

AI-native SDLC, software development lifecycle, plays, intent.md, spec.md, plan.md, CLAUDE.md, REVIEW.md, bands.yaml, committed artifact, audit trail, plan mode, auto mode, hooks, skills, subagents, parallel sessions, git worktrees, feedback loop, continuous evals, agentic PR review, separation of duties, managed settings, sandbox, MCP, claude-code-action, Agent SDK, control bands, Western Electric rules, OpenTelemetry, DORA, Claude Tag, leading indicators, lagging indicators, governance as code

## Authors

Louis Claxton (Anthropic, équipe Applied AI), sur le blog claude.com ; contributions créditées à Jim Blackhurst, Will Steuk et Jamal Arif.

## Ton

Profil: ausführlicher Unternehmensleitfaden mit operativem Ziel, „Wir“-Stimme des Applied-AI-Teams eines Anbieters, das den Einsatz seiner eigenen Produkte beschreibt, präskriptives und prozedurales Register, hohes technisches Niveau, gerichtet an Platform Leads, Tech Leads sowie Compliance-/Sicherheitsteams großer, teils regulierter Organisationen. Die Struktur ist eher die eines **Handbuchs** als eines Essays: Jeder *Play* folgt demselben Raster — was sich ändert, Voraussetzungen, Infrastruktur, Ausführungsschritte, Governance-Erwägungen, ein Frühindikator und ein Spätindikator —, und fast jeder wird von einem Artefakt begleitet, das im Original gezeigt wird (`intent.md`, `plan.md`, `CLAUDE.md`, `SKILL.md`, `settings.json`, `bands.yaml`, ein GitHub-Actions-Workflow). Das Vokabular ist der internen Kontrolle entlehnt — *control objectives*, *separation of duties*, *approval gates*, *audit trail*, *blast radius* — und dient dazu, Agenten-Praktiken in die Kategorien eines Auditors zu übersetzen. Die Rhetorik verfährt durch systematische binäre Gegenüberstellung, jeder Play eröffnet mit einem Paar *Traditional* / *AI-native*. Der Text steht zu seiner kommerziellen Rolle, ohne sie zu verschleiern: Die genannten Produkte (Claude Code, Claude Design in Beta, Claude Tag in öffentlicher Beta, Code Review in *Research Preview*, Cowork) sind seine eigenen, und der Schlussabschnitt verlinkt auf fünfzehn Dokumentationsseiten. Dennoch bleibt er bezüglich seiner eigenen Grenzen zurückhaltend — vom Skill heißt es, er erzwinge nichts, und die managed settings werden als Ausgangspunkt zum Anpassen angeboten, nicht als wortgetreu zu übernehmende Empfehlung.

## Pense-betes

- **Drei Konsequenzen, sobald der Bau nicht mehr der begrenzende Faktor ist**: (1) Der Engpass verschiebt sich auf die Phasen, die weiterhin mit menschlicher Geschwindigkeit ablaufen (Planung, Review/Test, Deployment); (2) Kontrollen werden unanwendbar — jede Zeile zu lesen ergab Sinn, solange ein Mensch sie geschrieben hatte; (3) die Governance-Kosten steigen, da Ausnahmen über periodische Ausschüsse laufen. Gegebenes Beispiel: ein für menschlichen Durchsatz dimensioniertes Sicherheitsteam, vor dem entweder die Review-Warteschlange wächst oder Code unzureichend geprüft ausgeliefert wird.
- **Der rote Faden ist das committete Artefakt**, nicht das Werkzeug: Jede Phase endet mit einem Schreibvorgang in die Versionskontrolle, die nächste beginnt mit dessen Lesen, und die Commit-Kette **ist** der Audit-Trail. `.md` dominiert vorgelagert, weil Product Owner und Agent dieselbe Datei lesen; ab der Bauphase ist das Artefakt der Code und seine Spuren.
- **Kaskadierende Auslöser**: Ein akzeptiertes `intent.md` löst den Anforderungs-/Design-Durchgang aus, eine genehmigte `spec.md` löst den Plan-Modus aus, ein gemergter PR löst die Pipeline aus, ein in der Produktion überschrittenes Band schreibt das nächste `intent.md`. Teams beginnen damit, jede Phase manuell anzustoßen; der Zielzustand ist die Schleife, in der jedes akzeptierte Artefakt das nächste Gate scharf schaltet.
- **Skill vs. Hook — die Unterscheidung trägt das gesamte Kontrollgebäude**: Der Skill macht die Einhaltung der Richtlinie wahrscheinlich, ohne eine Session zur Einhaltung zu zwingen; der Hook ist deterministisch und blockiert die Aktion. Eine Richtlinie, die immer gelten muss, benötigt einen Hook oder einen Review-Durchgang hinter dem Skill. Korollar: Ein Hook, der eine menschliche Genehmigung *anfordert*, gehört ins Deployment, nicht in den Bau, wo er einen Menschen wieder auf den kritischen Pfad jeder parallelen Session setzen würde.
- **Legacy-Systeme**: Für jedes Artefakt wird **ein** System als Quelle der Wahrheit benannt (das Repository oder Jira/ServiceNow, wobei die `.md`-Dateien Arbeitskopien sind), wobei alles andere nur einen Link vorhält. Einfaches **Verketten** — das Artefakt trägt die Datensatz-ID, der Datensatz trägt die Commit-SHA — wird als Mindesteinstiegsniveau angeboten.
- **Test**: Die Feedback-Schleife (Tests, Build, Screenshot-Diff) läuft während der gesamten Aufgabe; der Verifier-Subagent ist ein abschließender Durchgang mit frischem Kontext, sodass das Urteil nicht von den Annahmen gefärbt ist, die den Code hervorgebracht haben. Für einen Fix wird zuerst der fehlschlagende Test geschrieben, committet und dem Agenten dann per Hook das Bearbeiten dieses Tests verwehrt. Evals sind das KI-native Gegenstück zu QA-Gates: **20 bis 50 reale Aufgaben**, die bei jeder Änderung an `CLAUDE.md`, einem Skill oder einem Hook erneut abgespielt werden, wobei jeder Vorfall zu einem dauerhaften Eval wird.
- **Maintain, Schließung der Schleife**: **Die Erkennung bleibt deterministisch** (gleitender Mittelwert und Standardabweichung, Western-Electric-Regeln, ein versioniertes und getestetes Skript, ohne beteiligtes Modell); Claude wird erst hinzugezogen, wenn ein Band überschritten wird, und die Stufe legt fest, was möglich ist — 1σ protokolliert, 2σ diagnostiziert nur lesend, 3σ schlägt vor (ein PR oder ein vorab genehmigtes Runbook). Rollback wird als der Pfad benannt, der in der Pipeline **am häufigsten geübt** sein muss.
- ⚠️ **Was der Beitrag nicht quantifiziert**: keine quantifizierten Ergebnisse, weder Zeitersparnis noch Adoptionsrate. Die Zahlen des Leitfadens sind **Implementierungsparameter** (20-50 Evals, zwei oder drei parallele Sessions zum Einstieg); die Ergebnisse bleiben selbst zu messende Metriken, wobei jeweils deren Quelle benannt wird (git log, PR-Metadaten, OpenTelemetry-Export, DORA, Incident-Tracking-Tool).
- **Zum Verknüpfen**: [[sfeir-sdlc-ia-cycle-11-phases-2026-06-16]] (eine konkurrierende Gliederung in elf Phasen) und [[sfeir-code-review-anneau-contraintes-2026-07-30]] (der Ring von Einschränkungen um den Agenten, wo Hooks und Review hier zwei getrennte Ringe sind).

## RésuméDe400mots

Louis Claxton vom Applied-AI-Team von Anthropic veröffentlichte am 21. August 2026 einen Umsetzungsleitfaden für einen „KI-nativen“ Software-Entwicklungszyklus. Ausgangspunkt ist ein Ungleichgewicht: Organisationen schreiben heute Code in einer vor einem Jahr unvorstellbaren Geschwindigkeit, aber die umgebenden Prozesse — Freigabetore, Reviews, Übergaben, Richtlinien — haben sich nicht mitbewegt. Der traditionelle SDLC wurde für eine Welt konzipiert, in der das Schreiben von Code die längste und teuerste Phase war; seine Kontrollen gehen zudem davon aus, dass jede Aktion von einem Menschen ausgeführt wird.

Daraus ergeben sich drei Konsequenzen. Der Engpass verschiebt sich auf die Phasen, die weiterhin mit menschlicher Geschwindigkeit ablaufen, vor und nach dem Bau. Kontrollen werden unanwendbar: Jede Zeile zu lesen ergab Sinn, solange eine Person sie geschrieben hatte. Und die Governance-Kosten steigen, da Ausnahmen über periodische Ausschüsse laufen.

Die Antwort behält die Kontrollziele bei und ändert ihre Umsetzung. Der Prozess wird zu einer Schleife, mit KI an jedem Punkt eingebettet, gegliedert in sechs Phasen — Plan, Design, Build, Test, Deploy, Maintain —, aufgeteilt in *Plays*, die alle demselben Raster folgen, bis hin zu den Metriken. Der rote Faden ist das committete Artefakt. Die Absicht wird von ihrem ursprünglichen Urheber als `intent.md` festgehalten; Anforderungen und Design verschmelzen zu einer einzigen Session, die `spec.md` erzeugt, eingeschränkt durch die Skills für Marke, Sicherheit, Compliance und UX; der Bau beginnt im Plan-Modus und fixiert `plan.md`, bevor jeglicher Code geschrieben wird. Die Commit-Kette dient als Audit-Trail.

Institutionelles Wissen wird zu versionierten Dateien: `CLAUDE.md` für den Repository-Kontext, Skills für übergreifende Richtlinien, `REVIEW.md` für die Review-Doktrin, `bands.yaml` für Produktionsschwellenwerte. Governance gliedert sich in zwei Schichten, wobei der Skill als beratende Kontrolle fungiert und der Hook als deterministische Schicht, die blockiert oder eine Genehmigung anfordert. Ein Beispiel für *managed settings* schlüsselt Feld für Feld auf, was jede Einstellung an Kontrolle bringt, vom Verweigern des Lesens von Secrets bis zur Durchsetzung einer Mindestversionsgrenze.

Die Maintain-Phase schließt die Schleife: Ein deterministisches Skript überwacht eine Metrik, und das Überschreiten eines Bands ruft Claude ohne Menschen im Aufrufpfad auf, auf einem durch die Stufe festgelegten Autonomiegrad. Was der Agent findet, wird als `intent.md` neu formuliert und in den Zyklus zurückgespeist. Claude Tag, in öffentlicher Beta auf Slack, erweitert das Muster auf Vorfälle, die per Chat eingehen. Es werden keine quantifizierten Ergebnisse vorgelegt: Der Leitfaden liefert zu messende Metriken und benennt jeweils deren Quelle.

## GrapheDeConnaissance

- Anthropic —publie→ The AI-Native SDLC playbook (DOCUMENT, 0.97)
- Louis Claxton —a_créé→ The AI-Native SDLC playbook (DOCUMENT, 0.95)
- The AI-Native SDLC playbook —affirme_que→ le goulot se déplace du build vers les étapes restées à vitesse humaine (AFFIRMATION, 0.94)
- SDLC AI-native —est_variante_de→ SDLC (METHODOLOGIE, 0.92)
- SDLC AI-native —utilise→ artefact committé (CONCEPT, 0.93)
- artefact committé —permet→ piste d'audit (CONCEPT, 0.9)
- intent.md —fait_partie_de→ SDLC AI-native (METHODOLOGIE, 0.92)
- spec.md —est_basé_sur→ intent.md (DOCUMENT, 0.91)
- plan.md —est_basé_sur→ spec.md (DOCUMENT, 0.9)
- Plan mode —permet→ plan accepté avant toute écriture de code (CONCEPT, 0.93)
- CLAUDE.md —s_applique_à→ contexte du dépôt lu à chaque session (CONCEPT, 0.92)
- Claude Skills —s_applique_à→ politique appliquée pendant l'écriture du code (CONCEPT, 0.9)
- hooks —améliore→ Claude Skills (TECHNOLOGIE, 0.88)
- Louis Claxton —affirme_que→ une skill est un contrôle consultatif, rien n'oblige une session à la suivre (AFFIRMATION, 0.92)
- REVIEW.md —s_applique_à→ passes de revue bugs, sécurité et conformité au spec et au plan (CONCEPT, 0.89)
- séparation des tâches —s_applique_à→ l'agent qui écrit le code ne peut pas l'approuver (AFFIRMATION, 0.93)
- evals continues —s_applique_à→ configuration d'agent versionnée, testée comme du code (CONCEPT, 0.9)
- Louis Claxton —recommande→ collecter 20 à 50 tâches réelles pour constituer la suite d'evals (AFFIRMATION, 0.88)
- Louis Claxton —recommande→ démarrer à deux ou trois sessions parallèles par ingénieur (AFFIRMATION, 0.87)
- git worktrees —permet→ sessions Claude Code parallèles isolées (CONCEPT, 0.9)
- bands.yaml —permet→ paliers d'autonomie 1σ, 2σ, 3σ (CONCEPT, 0.9)
- détection de bande de contrôle —affirme_que→ la détection reste entièrement déterministe, sans modèle impliqué (AFFIRMATION, 0.92)
- MCP —permet→ déploiement et rollback exposés comme outils cadrés par environnement (CONCEPT, 0.89)
- managed settings —réduit→ surface d'action de l'agent en environnement régulé (CONCEPT, 0.89)
- Claude Tag —s_applique_à→ réponse à incident depuis un canal Slack (CONCEPT, 0.88)
- DORA —mesure→ performance de livraison, indicateur retardé du play CI/CD (MESURE, 0.85)

---
Canonical: https://www.thekb.eu/de/fiches/claxton-anthropic-ai-native-sdlc-playbook-2026-08-21/