nixos-config/docs/research/anthropic-ai-native-sdlc-playbook.md

# 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: <https://claude.com/blog/the-ai-native-sdlc-playbook>
Begleitender Kurs: <https://academy.claude.com/courses/ai-native-sdlc-playbook>

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** (<https://waydev.co/anthropics-ai-native-sdlc-playbook-has-a-missing-layer-measurement/>):
   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** (<https://getaibook.com/news/anthropics-ai-native-sdlc-replaces-gates-with-git-loops/>):
   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** (<https://www.port.io/blog/anthropic-ai-native-sdlc-playbook>):
   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** (<https://agenticaiarch.com/ai-native-sdlc-playbook/>):
   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/<slug>.md` (≈ `intent.md`), `researcher` erzeugt
  `docs/research/<slug>.md`, `reviewer` erzeugt bei Systemaudits
  `docs/review/<slug>.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.