# Anthropics „AI-Native SDLC Playbook" — Zusammenfassung, Einordnung, Abgleich mit diesem Repo ## Fragestellung Auftrag (präzisiert durch `docs/intent/anthropic-agentic-sdlc-guideline.md`): Identifiziere per Web-Suche die aktuelle Anthropic-Guideline zu einem agentic-SDLC-/Software-Factory-Ansatz, fasse die Primärquelle(n) zusammen, ordne sie extern ein (Reaktionen/Vergleiche, soweit auffindbar), gleiche sie mit dem Ist-Zustand dieses Repos ab (`agents/`-Rollen, Herdr-Orchestrierung, Build-/Test-/Deploy-Praktiken) und leite daraus Empfehlungen als Diskussionsgrundlage ab — ausdrücklich keine Umsetzung. ## Methode - Web-Suche (mehrere Anfragen, u. a. „Anthropic agentic SDLC software factory guideline 2026", „Anthropic 'software factory'", „'AI-Native SDLC' Anthropic playbook") zur Identifikation der Primärquelle. - Direktes Abrufen der Primärquelle (`claude.com/blog/...`) zur Extraktion von Struktur, Stufen, Artefakten und Rollen. - Abrufen von vier unabhängigen Sekundärquellen (Kommentar/Kritik) zur externen Einordnung. - Repository-Lektüre (read-only) von `AGENTS.md`, `CLAUDE.md`, `docs/herdr-orchestration.md`, `agents/catalog.json`, `agents/planner.md`, `agents/admin.md`, `agents/reviewer.md`, `agents/researcher.md` als Grundlage für den Ist-Abgleich. - Kein Zugriff auf zahlungspflichtige/interaktive Inhalte (z. B. der vollständige `academy.claude.com`-Kurs) — dort blieb es bei den über die Suche sichtbaren Kursbeschreibungen. ## Primärquelle **„The AI-Native SDLC Playbook"**, Anthropic/Claude, veröffentlicht am 21.08.2026, Autor laut abgerufener Seite Louis Claxton. Blog: Begleitender Kurs: Der vage Erinnerungswert „vier Buchstaben" aus dem Intent-Dokument passt zu **SDLC** — plausibler Treffer, aber nicht durch den Nutzer verifiziert; als Annahme markiert. ### Kernprinzip (belegt) Zentrale These der Quelle: Schnellere Code-Erzeugung durch Agenten verschiebt den Engpass weg vom Schreiben von Code hin zu Planung, Design-Abstimmung, Security-Review, Test, Freigabe und Incident-Response. Der klassische, weitgehend lineare SDLC wird durch eine **nicht-lineare Schleife** ersetzt, in der KI an jedem Punkt eingebettet ist. ### Sechs-Stufen-Schleife mit Artefaktkette (belegt) | Stufe | Artefakt | Menschlicher Checkpoint | |---|---|---| | Plan | `intent.md` | Product Owner prüft/genehmigt | | Design | `spec.md` | Product Owner löst markierte Bedenken auf | | Build | `plan.md` + Diff | Tech Lead prüft höher-riskante Änderungen | | Test | Testergebnisse/Build-Logs | Code Owner prüft PR | | Deploy | Merged PR | Release Manager autorisiert Produktion | | Maintain | neues `intent.md` aus Monitoring | Service Owner triagiert Befunde | Jede Stufe endet mit einem versionierten, git-committeten, sowohl maschinell ausführbaren als auch menschenlesbaren Markdown-Artefakt; die nächste Stufe beginnt mit dem Lesen dieses Artefakts. Dadurch entsteht eine durchgehende Audit-Spur (Anfrage, Agenten-Output, Freigaben, Änderungen) im selben Repository wie der Code. Zitiertes Kernprinzip zur Rollenverschiebung: „Die menschliche Aufmerksamkeit verschiebt sich mit den Artefakten, die geprüft werden müssen. Menschen bleiben für jede Entscheidung verantwortlich, die Urteilsvermögen erfordert." (sinngemäße Übersetzung aus der extrahierten Quelle.) ### Genannte Rollen (belegt) Product Owner, Engineers/Tech Leads, Platform Engineers, Security-Teams, Release Manager, Service Owner, Code Owner, sowie „Policy Owner" für Compliance/UX/Brand/Security-Richtlinien. Plattform-Engineering wird ausdrücklich als Betreiber des Gesamtprozesses benannt: Der Playbook definiert den Prozess, Plattform-Engineering betreibt ihn organisationsweit. ### Genannte Werkzeuge (belegt) Claude Code (Plan-Modus, Auto-Modus, parallele Sessions, Subagents), Claude Enterprise, Claude Tag (Slack/Teams-Anbindung für Incidents), Claude Security (geplantes Scanning), Claude Design, Claude Cowork, sowie Skills, Hooks und MCP-Server als Erweiterungsmechanismen. Policy wird nach Aussage der Quelle je Stufe „as code" über Skills/Hooks durchgesetzt, nicht allein über manuelle Reviews. ### Zielgruppe (belegt) Die Quelle richtet sich ausdrücklich an Engineering-, Plattform- und Security-Leads großer (insbesondere regulierter) Unternehmen, deren Freigabe-Gates, Reviews und Übergaben noch auf menschlichem Tempo laufen, während Codegenerierung bereits agentisch beschleunigt ist. ## Externe Einordnung (Sekundärquellen) Vier unabhängige Kommentare wurden ausgewertet; alle beziehen sich ausschließlich auf Anthropics Playbook, keiner stellt einen direkten Vergleich zu einem konkurrierenden Anbieter (OpenAI, Google, GitHub Copilot o. ä.) an — das ist selbst ein Befund (siehe Unsicherheiten/Lücken unten). 1. **Waydev** (): Kritisiert eine fehlende Mess-Infrastruktur. Der Playbook fordert laut Artikel an jeder Stufe Metriken, liefert aber keine Anleitung, wie Signale aus Git, CI, PR-Metadaten und Incident-Trackern tatsächlich korreliert werden. Zitat (aus der Quelle wiedergegeben): „Every play ends the same way" mit Metrik-Anforderungen, aber „Zero of them correlated in a typical engineering org today." Empfehlung des Artikels: Baseline- Metriken vor der Skalierung von Agenten etablieren (kommerziell interessengeleitet — der Artikel bewirbt Waydevs eigenes Produkt als Lösung). 2. **getaibook.com** (): Reine Zusammenfassung ohne Kritik. Betont die Verschiebung von späten QA-Gates zu kontinuierlicher Qualitätsintegration während der Implementierung („custom eval suites from 20 to 50 real-world tasks") und die durchgehende Audit-Spur. Kein Vendor-Vergleich. 3. **Port.io** (): Formuliert die Kritik zugespitzt: Anthropic liefere „das Ziel und die Karte", aber nicht „das Fahrzeug" — der Playbook beschreibt das Was, nicht das Wie der Operationalisierung. Konkrete Lücken laut Artikel: (a) wie aus einem Signal (Ticket, Alert, Slack-Nachricht) überhaupt ein strukturiertes `intent.md` entsteht, bleibt offen; (b) wie der „named policy owner" identifiziert und benachrichtigt wird, bleibt offen; (c) Risikoeinschätzung („blast radius") setzt Infrastrukturwissen voraus, das der Playbook nicht liefert; (d) keine eingebaute Sichtbarkeit, ob Teams den Playbook über viele Repositories hinweg tatsächlich befolgen. Auch hier interessengeleitet (Port bewirbt eine eigene, Vendor-agnostische „Agentic SDLC Platform" als fehlende Schicht). 4. **Dr. Harish Kotadia / agenticaiarch.com** (): Ordnet den Playbook in ein eigenes Governance-Framework ein und benennt zwei aus fachlicher Sicht gewichtige Lücken: (a) **Autonomie-Kalibrierung** — der Playbook definiert technische Gates und Review-Schichten, sagt aber nicht, wie viel Autonomie ein Agent an welchem Gate erhalten soll; (b) **Kostenrechnung** — laut Artikel enthält der Playbook keine Dollar-Beträge; Metriken wie Zykluszeit und DORA-Kennzahlen werden erfasst, aber Tokenverbrauch über parallele Sessions, Verifikations- Agenten und selbstauslösende Maintain-Schleifen hinweg bleibt unberücksichtigt. Empfehlung: „Kosten pro abgeschlossener Aufgabe" von Beginn an als Kennzahl führen. **Zusammengefasste externe Kritik (Schlussfolgerung, nicht direkt aus einer einzelnen Quelle zitiert):** Der wiederkehrende Tenor aller vier Kommentare ist derselbe — der Playbook beschreibt überzeugend das Zielbild (Artefakte, Stufen, Rollen, Checkpoints), lässt aber die Operationalisierung (Instrumentierung/Messung, Signalverarbeitung, Autonomie-Dosierung, Kostenkontrolle, Compliance-Nachweis über viele Repos) bewusst offen bzw. Sache der jeweiligen Organisation. ## Abgleich mit dem Ist-Zustand dieses Repos Der Abgleich bezieht sich auf den Stand von `AGENTS.md`, `docs/herdr-orchestration.md`, `agents/*.md` und `agents/catalog.json` zum Zeitpunkt dieser Recherche (03.09.2026), einschließlich der laut `git status` bereits im Arbeitsbaum vorhandenen, aber noch nicht committeten Änderungen an `agents/catalog.json`, `agents/claude-settings/*.json`, `agents/planner.md`, `agents/tests/roles.sh` und `docs/herdr-orchestration.md`. ### Wo dieses Repo bereits strukturell nah am Playbook-Prinzip liegt - **Artefaktkette existiert bereits in einer Vorform.** `planner` erzeugt `docs/intent/.md` (≈ `intent.md`), `researcher` erzeugt `docs/research/.md`, `reviewer` erzeugt bei Systemaudits `docs/review/.md` — alle versioniert im selben Repo wie der Code, git-getrackt, menschenlesbar. Das entspricht dem Playbook-Prinzip „jede Stufe committet ein Artefakt, die nächste Stufe liest es". Anders als im Playbook gibt es aber (Stand dieser Recherche) keine feste Kopplung `spec.md`/`plan.md` — der Planner-Vertrag deckt nur die Plan-Stufe ab; ein separates Design-Artefakt fehlt. - **Rollentrennung mit exklusivem Dateibesitz** (Administrator, Reviewer, Planner, Researcher, Agent-Manager, Orga) entspricht der Playbook-Idee getrennter Verantwortlichkeiten (Product Owner/Tech Lead/Code Owner/Release Manager/Service Owner), wenn auch anders geschnitten: dieses Repo trennt nach **Werkzeug-/Fähigkeitsgrenze** (wer darf was lesen/schreiben/aktivieren), der Playbook trennt zusätzlich nach **organisatorischer Rolle** (wer ist fachlich rechenschaftspflichtig). - **Reviewer-Pflicht ab Risikoschwelle** (`docs/herdr-orchestration.md`, Abschnitt „Reviewer als Standardschritt ab Risikoschwelle": Diffs an Boot/Netzwerk/Firewall/sshd/Secrets/Rollen/Katalog lösen Pflicht-Review aus) entspricht der Playbook-Logik risikoabhängiger Gates statt pauschaler Reviews an jeder Stelle. - **Explizite Aktivierungsfreigabe getrennt vom Build** (`agents/admin.md`: „Ein Build oder eine Evaluierung ist keine Aktivierungsfreigabe") und der in `CLAUDE.md` dokumentierte Verify-Pfad (`nix flake check` → `drvPath`-Eval → Build → `diff-closures` → `dry-activate` → ggf. `test` vor `switch`) entsprechen der Playbook-Idee, dass jede Stufe ihre eigene Prüfung hat, bevor die nächste beginnt. - **Eskalationskette mit definiertem Fixer-Routing** (Administrator für Infrastrukturhürden, Agent-Manager für Rollenlücken) und der Rückfrage-Kanal-Pilot bei `orga` entsprechen in etwa dem Playbook-Prinzip klar benannter „Policy Owner", an die eine Blockade geroutet wird. ### Wo dieses Repo strukturell anders/schmaler ist als der Playbook - **Kein explizites Design-/Spec-Artefakt zwischen Intent und Umsetzung.** Der Playbook trennt Plan (`intent.md`) und Design (`spec.md`) als zwei eigene, freigegebene Stufen. Hier geht der Planner direkt von der Nutzer-bestätigten Rohfassung zum fertigen `intent.md`; ein separates Architektur-/Schnittstellen-Review vor dem Build-Auftrag an Administrator oder Agent-Manager ist nicht vorgesehen. Bei einem Einzelnutzer-System mit drei Hosts ist das plausibel bewusst schlank gehalten — im Playbook-Kontext großer, regulierter Organisationen wäre das eine der benannten Lücken. - **Keine formalisierte Kosten-/Token-Metrik**, obwohl `docs/herdr- orchestration.md` bereits Modell-/Reasoning-Profile je Rolle mit expliziter Eskalationsbegründungspflicht führt (`sol`/`high` nur bei „gemessenem Qualitätsbedarf"). Das ist in der Zielrichtung deckungsgleich mit Kotadias Kritikpunkt „keine Dollar-Zeichen im Playbook", aber dieses Repo hat ebenfalls keine tatsächliche Zahl (Tokens, Kosten pro Auftrag) hinterlegt — die Eskalationsregel ist eine Prompt-Norm, keine gemessene Kennzahl. - **Keine durchgehende Metrik-/Observability-Schicht über die Agent-Pipeline** (Waydevs Kritikpunkt am Playbook trifft strukturell ebenso auf dieses Repo zu): Es gibt Regressionstests (`agents/tests/roles.sh`) für Rollenkonsistenz, aber keine laufende Erfassung von Zykluszeit, Fehlerrate pro Rolle, Reviewer-Fund-Rate o. ä. - **Kein `nixosTest`/VM-Testlayer** — in `CLAUDE.md` selbst als bekannte Lücke benannt („Es gibt in diesem Repo noch keine `nixosTest`/VM-Tests"). Der Playbook-Stufe „Test" entspricht hier im Wesentlichen Evaluierung + Build + `dry-activate`, nicht automatisierte funktionale Tests. - **Autonomie ist rollenweise, nicht gate-weise kalibriert.** Der Playbook (laut Kotadias Kritik ohnehin selbst unvollständig) und dieses Repo lösen Autonomie unterschiedlich: Hier ist Autonomie an die Rolle gebunden (`sandbox: read-only/scoped-write/per-assignment/helper-only` in `agents/catalog.json`) und zusätzlich an Selbstschließungsbedingungen, nicht an eine graduelle Punktzahl pro Entscheidungspunkt. - **Kein spezialisierter Deploy-/Release-Manager-Agent.** Aktivierung bleibt laut `agents/admin.md` und `CLAUDE.md` ausdrücklich menschlich freigegeben und wird vom Administrator ausgeführt, nicht von einer eigenen Release-Rolle mit eigenem Vertrag — beim aktuellen Umfang (drei Hosts, ein Operator) vermutlich angemessen, wäre aber im Playbook-Sprachgebrauch eine fehlende „Deploy"-Spezialisierung. ## Empfehlungen (Diskussionsgrundlage, keine Umsetzung) Diese Empfehlungen sind Vorschläge für ein mögliches späteres, separates Umsetzungsgespräch — keine Entscheidung und keine Bewertung, ob der Aufwand im Verhältnis zum Nutzen für ein Ein-Personen-/Drei-Host-System steht. 1. **Design-Zwischenstufe erwägen, aber nicht zwingend als neue Rolle.** Statt eines vierten Artefakttyps könnte der bestehende `planner`-Vertrag optional ein kurzes „Abgrenzungs-/Schnittstellen-Review" vor dem endgültigen Intent-Schreiben anbieten, wenn ein Vorhaben mehrere Hosts oder die Rollen-/Katalog-Grenze selbst berührt — nur für diese Fälle, nicht generell. 2. **Leichte Kennzahlenerfassung statt volle Observability-Schicht.** Anstelle einer Waydev-artigen Plattform: der Reviewer könnte bei Systemaudits künftig auch grob erfassen, wie oft Blocker/Eskalationen pro Rolle auftreten (aus `agents/tests/roles.sh`-Historie oder Pane- Transkripten ableitbar), um die Eskalationskette selbst zu beobachten, ohne eine neue Infrastruktur einzuführen. 3. **Token-/Kostenbewusstsein von Prompt-Norm zu grober Messung weiterentwickeln.** Die bestehende Regel „`sol`/`high` nur bei gemessenem Qualitätsbedarf" hat aktuell keine Messgrundlage. Ein minimaler Schritt wäre, bei Eskalationen den konkreten Anlass (welcher Fehler, welches Routineprofil hat versagt) im jeweiligen Rollenbericht festzuhalten, statt einer neuen Kennzahleninfrastruktur. 4. **`nixosTest`/VM-Tests bleiben die konkreteste, bereits im Repo selbst benannte Lücke** (unabhängig vom Playbook) — sie deckt sich mit der Playbook-Erwartung, dass die Test-Stufe mehr liefert als Evaluierung und `dry-activate`. Empfehlung: als eigenständiges, vom Playbook-Thema unabhängiges Vorhaben behandeln, nicht als Teil einer Playbook-Angleichung. 5. **Playbook-Terminologie nicht 1:1 übernehmen.** Die Rollen dieses Repos sind bewusst nach Werkzeug-/Sandbox-Grenze geschnitten, nicht nach Organisationsrolle (Product Owner, Release Manager, …) — das passt zum Ein-Personen-Kontext. Eine Umbenennung oder Eins-zu-eins-Übernahme der Playbook-Rollen wird nicht empfohlen; falls überhaupt etwas übernommen wird, eher das Prinzip „Artefakt pro Stufe, nächste Stufe liest es", nicht die Rollenbezeichnungen. 6. **Vor jeder Umsetzung: erneuter, engerer Recherche- oder Planungsauftrag** speziell zu einem der obigen Punkte, mit konkretem Scope — dieser Bericht ist bewusst breit und vergleichend, keine Spezifikation. ## Unsicherheiten und offene Punkte - **Identität der Primärquelle nicht vom Nutzer verifiziert.** Der Bericht geht davon aus, dass „The AI-Native SDLC Playbook" (claude.com, 21.08.2026) die gemeinte Quelle ist, gestützt auf mehrfache, konsistente Web-Suchtreffer und die Übereinstimmung mit dem vagen Erinnerungswert „vier Buchstaben" (SDLC). Eine andere, zeitlich benachbarte Anthropic-Veröffentlichung zum selben Themenfeld wurde in der Suche nicht gefunden, ist aber nicht mit Sicherheit ausgeschlossen. - **Kein direkter Vendor-Vergleich auffindbar.** Keine der vier ausgewerteten Sekundärquellen vergleicht den Playbook explizit mit einem Konkurrenzansatz (OpenAI, Google, GitHub). Das ist selbst als Lücke zu werten, nicht als Beleg, dass es keine vergleichbaren Ansätze gibt — weitere, gezielte Suche dazu wurde im Rahmen dieses Auftrags nicht vertieft, um den Scope nicht zu sprengen. - **Sekundärquellen sind teils kommerziell interessengeleitet** (Waydev und Port.io bewerben im selben Artikel ihr eigenes Produkt als Lösung der benannten Lücke). Die inhaltliche Kritik wurde trotzdem referenziert, da sie in der Sache nachvollziehbar und plausibel ist — aber als Werbekontext ausdrücklich benannt. - **Kein Zugriff auf den vollständigen Academy-Kurs** (`academy.claude.com`) — nur die über Suchtreffer sichtbaren Kursbeschreibungen wurden ausgewertet, nicht der vollständige Kursinhalt. - **Ist-Zustand des Repos ist ein Snapshot vom 03.09.2026**, einschließlich laut `git status` bereits im Arbeitsbaum vorhandener, aber noch nicht committeter Änderungen. Ein späterer Abgleich sollte den dann aktuellen Stand erneut prüfen, nicht diesen Bericht als bereits veraltete Momentaufnahme fortschreiben. ## Fazit Anthropics „AI-Native SDLC Playbook" (21.08.2026) beschreibt für große, insbesondere regulierte Organisationen eine Sechs-Stufen-Schleife (Plan–Design–Build–Test–Deploy–Maintain) mit einer durchgehenden, git-versionierten Artefaktkette und risikoabhängigen menschlichen Checkpoints. Unabhängige Kommentare loben die konzeptionelle Klarheit, kritisieren aber übereinstimmend die fehlende Operationalisierung (Messung, Signalverarbeitung, Autonomie-Dosierung, Kostenkontrolle). Dieses Repo verfolgt in seiner Herdr-/`agents/`-Pipeline bereits mehrere strukturell verwandte Prinzipien — versionierte Zwischenartefakte, rollenbasierte Sandbox-Trennung, risikoabhängige Reviewpflicht, getrennte Build-/Aktivierungsfreigabe — allerdings schlanker geschnitten und ohne eigene Design-Zwischenstufe, Kostenmessung oder Observability-Schicht. Für den aktuellen Ein-Personen-/Drei-Host-Kontext erscheint das plausibel angemessen; die oben genannten Empfehlungen sind als Diskussionsgrundlage für ein mögliches, engeres Folgevorhaben gedacht, nicht als Bewertung, dass eine Angleichung an den Playbook-Umfang nötig oder sinnvoll wäre.