Wir haben Anthropics Claude Code Playbook gemessen

Anthropic hat ein Playbook für den KI-nativen SDLC mit Claude Code veröffentlicht: sechs Stufen, jede endet in einer committeten Datei, angeboten als kostenloser Kurs. Die zentrale These: Code ist nicht mehr der Engpass, und die Kette der committeten Artefakte steuert das, was es ist. Das Dokument selbst enthält keinerlei Messung, keine Zeiten, keine Kosten, keinen Benchmark. Wir haben den ersten Zeittest an einem echten Repository gemacht: sechzehn gemessene Claude-Code-Sessions, jedes Gate mit Preis, und ein Urteil, das die Kette in der Mitte teilt. Nebenbei hat ein Zwei-Minuten-Fix durch die volle Kette die Zeremonie beziffert, und unser eigenes Deploy wurde zweimal gestoppt, einmal von vier Zeilen Shell.

Das Testsetup: sechzehn gemessene Claude-Code-Sessions, etwa $12 Rechenkosten, ein echtes Repository. Das Playbook hat sechs Stufen: Plan, Design, Build, Test, Deploy, Maintain. Jede Stufe endet in einer committeten Datei, und die nächste Stufe liest sie: Intent, Spec, Plan, den Pull Request, den Incident-Eintrag. Die Commits sind der Audit-Trail. Anthropic vermittelt das als kostenlosen Kurs mit 14 Lektionen, etwa eine Stunde, geschrieben für Unternehmen mit Review-Gates; wir haben getestet, was den Kontakt mit einem einzelnen Entwickler übersteht.

Das Repository ist die RealWorld-Demo-App (Express, TypeScript, Prisma, Postgres), ein echtes Projekt mit echten Tests und einer Suite, die nach frischem Clone kaputt ist (vier bestandene Suites, 14 grüne Tests, zwei Sekunden Laufzeit). Dieser Bug wird später zur Kontrollgruppe. Die Bewertungsregel: Ein Gate zahlt sich aus, wenn sein Ergebnis verändert, was ausgeliefert wird, und das für weniger, als es kostet.

Die Eintrittskarte ist eine Memory-Datei im Repo-Root: Befehle, Konventionen, Architektur, die Fehler, die das Modell immer wieder macht, unter einer Seite gehalten. Unsere war in 63 Sekunden für $0.44 geschrieben und committet. Eine ehrliche Einschränkung zur Methode: Headless-Läufe pressen die Interviews des Playbooks in einzelne Prompts.

Das erste Gate hält die Idee fest, bevor irgendjemand etwas entwirft. Die Feature-Anfrage: Leser wollen Autoren stummschalten, die ihren Feed fluten. Das Playbook nennt das Ergebnis eine Proto-Spec, gemeinsam mit dem Modell geschrieben, aber von dir verantwortet, und lässt drei Ursprünge zu: eine Idee, ein eröffnetes Ticket oder einen Incident-Alarm. Das Template hat fünf Abschnitte, deren Überschriften das Denken übernehmen: Problem, gewünschtes Ergebnis, betroffene Nutzer und Systeme, Randbedingungen, offene Fragen. Der Arbeitsablauf besteht aus fünf Schritten: beschreiben, brainstormen, aus dem Template generieren, korrigieren, committen.

intent.md	Zeit	Kosten
Mute-authors feature	29 s	$0.18
Broken test suite	39 s	—

Der Wert steckt ganz unten, in den offenen Fragen: Was passiert mit Favoriten eines stummgeschalteten Autors? Bleiben seine Seiten erreichbar? Das sind Entscheidungen, die ein Coding-Agent sonst stillschweigend treffen würde, jetzt aufgeschrieben und datiert. Die Datei ist committet, also überleben Autorschaft und Zeitstempel den Chat, und der Product Owner korrigiert den Entwurf, bevor er ihn annimmt. Anthropics eigenes Ziel für diese Stufe ist Elicitation in Stunden statt Wochen; allein sind es unter einer Minute.

Gate zwei macht aus dem Intent eine Spec, mit einem Prompt aus dem Kurs: den Intent lesen, eine Requirements-und-Design-Spec erstellen, die verfügbaren Skills anwenden, also die Skills, die eigentlich deine Marken-, Sicherheits- und UX-Richtlinien tragen sollen. Zwei Minuten später hatten wir rund 2.300 Wörter kompetente Spec: Endpoints, Datenmodell, Feed-Verhalten, Randfälle. Sie hielt sogar fest, was sie nicht erfüllen konnte, genau wie der Prompt es verlangt.

Der Clou steckt in ihren markierten Bedenken, vom Modell selbst geschrieben: "C0. No org skills available. This spec has not been checked against any policy." Die ganze Prämisse der Stufe setzte Dateien voraus, die in den meisten Setups nicht existieren; die Erklärvideos überspringen diese Voraussetzung, der Agent hat sie schriftlich festgehalten. Der zweite Hinweis war zahmer: Die Standardwerte für offene Fragen brauchen vor dem Build die Freigabe des Produkts.

Die Lektion ist streng bei der Paarung (Spec und Intent werden zusammen committet, ein Mensch gibt den Übergang zum Build frei), und es gibt eine Lese-Rechnung: etwa 12 Minuten Product-Owner-Zeit pro Spec. Das Playbook erfasst sogar Rework: Spec-Commits, die nach Build-Beginn datiert sind, zählen gegen dich. In einem Team, das seine Richtlinien kodiert hat, werden sie an diesem Gate ausgeführt. Allein zahlst du für ein Versprechen, das das Setup noch nicht halten kann.

Gate drei ist Plan Mode, und die Latte liegt brutal und nützlich hoch: Ein Ingenieur, der das Gespräch nie gesehen hat, müsste allein anhand des Plans implementieren können. Plan Mode erzwingt die Lesehälfte selbst: Das Modell darf keine Dateien bearbeiten, bevor der Plan akzeptiert ist. Unserer kam nach vier Minuten auf etwa 4.000 Wörter, benannte die geänderten Dateien, die Reihenfolge der Arbeit, die Risiken und den Nachweis, und hielt drei benannte Abweichungen von der Spec fest, die später im Review wiederkommen.

Der Build läuft als Loop: den fehlschlagenden Test schreiben, ihn zum Bestehen bringen, ein Ziel, alles grün, sonst ist die Aufgabe nicht erledigt. Der Loop ist geschützt (ein Agent, der Code repariert, darf die Prüfung dieses Codes nicht abschwächen) und mit einem Verifier gekoppelt, einer zweiten Prüfung in frischem Kontext, unbeeinflusst von der Session, die den Code geschrieben hat.

Build-Ergebnis	Wert
Agent-Zeit	~9 min, 91 Turns
Kosten	~$2
Änderung	15 Dateien, Mutes-Tabelle, zwei Endpoints, beide Feeds gefiltert
Tests	5 Suites, 50 Tests, alle grün bei unabhängigem Rerun
Merge im ersten Anlauf	ja

Das Sternchen: Grün beweist nur, was der Loop enthält, nicht mehr. End-to-End wurde nie ausgeführt, es braucht einen laufenden Server und eine befüllte Datenbank, und ein Loop, der auf veraltete Fakes zielt, leuchtet genauso grün. Im Team kommen parallele Sessions in Worktrees dazu (zwei oder drei sind die genannte Obergrenze); das haben wir nicht getestet.

Das Deploy-Gate hat zwei Ebenen, und beide haben uns Nein gesagt. Ebene eins liest den Diff nach einer schriftlichen Richtlinie im Repo-Root: drei Durchgänge (Bugs, Sicherheit, Compliance gegen Spec und Plan), "Important" ist reserviert für kaputtes Verhalten, geleckte Daten oder einen Richtlinienverstoß, maximal fünf Nits, der Rest wird als Zahl zusammengefasst; die Richtlinie begrenzt ihr eigenes Rauschen. Zwei Minuten Review, $0.80, und es führte die echten Prüfungen aus: Tests, Build, Lint gegen die im Plan festgehaltene Baseline, Formatierung über neun Dateien. Urteil: null Important-Funde, sechs Nits, einer über dem Limit zusammengefasst. Es schloss mit einem Satz, den wir nicht angefordert hatten: Dieser Agent gibt nicht frei, die Freigabe bleibt bei einem menschlichen Code Owner hinter Branch Protection.

Ebene zwei ist das Gate selbst. Wir baten um das Deploy; das Modell lehnte von selbst ab, weil das Feature nicht auf dem Release-Branch lag. Das ist Urteilsvermögen, keine Durchsetzung. Also haben wir gemergt und noch einmal gefragt: Vier Zeilen Shell antworteten in 14 Sekunden: blockiert, Release-Autorisierung erforderlich. Exit-Code 2 stoppt den Tool-Aufruf, und der Grund landet wieder beim Modell. Die Pipeline-Seite bekam dieselbe Behandlung: Ein kaputter Build wurde headless in 11 Sekunden für $0.13 analysiert; er las das Log, benannte die genaue Ursache und schlug den Diff vor, ohne eine Datei anzufassen. Deterministisch schlägt höflich; ein Hook ist nur so gut wie sein Muster, und unseres traf ein Skript.

Derselbe Bug, derselbe kaputte Start, zwei Wege: das Kontrollexperiment. Weg eins: einfach fixen. Weg zwei: die volle Kette, von Intent bis Build.

	direkter Fix	volle Kette	Faktor
Wandzeit	2:13	11:31	×5.2
Kosten	$0.70	$3.46	×4.9
Turns	40	169	—
Ergebnis	Suite grün	Suite grün	identisch

Die Maschinenrechnung ist die kleine Hälfte. Die Kette schrieb für einen Einzeiler-Fix etwa 5.500 Wörter Artefakte, grob 27 Minuten menschliches Lesen für einen Diff, den man auf einen Blick überfliegt. Die Kette wandelt Schreibzeit in Lesezeit um; das ist die Gate-Steuer.

Das Playbook fügt eine wiederkehrende Gebühr hinzu: kontinuierliche Evals. Zwanzig bis fünfzig echte Aufgaben, bei jeder Konfigurationsänderung erneut ausgeführt, jeder Fall eine echte frühere Aufgabe, der Prompt wie damals, gestartet vom Commit vor der Änderung, mit prüfbarer Akzeptanz. Fünf Fälle aus der Historie zu schreiben dauerte fünf Minuten; sie richtig auszuführen ist nicht so einfach: Unser erstes Harness richtete zwei Fälle auf den falschen Commit, und beide Agenten bemerkten es, statt ein Bestehen vorzutäuschen. Bei etwa einer Minute pro Fall kostet eine vollständige Suite bis zu eine Stunde Agent-Zeit pro Lauf, und jeder Produktions-Incident soll als dauerhafte Regressions-Eval in die Suite wandern. In einem regulierten Team ist dieses Lesen das Ergebnis; allein ist es Overhead.

Drei von sechs Gates zahlen sich selbst aus:

Stufe	Urteil	Beleg
Plan	behalten	40 s kaufen die Fragen, die keiner gestellt hat
Build	behalten	Plan Mode + Test-Loop lieferten 50 grüne Tests
Deploy	behalten	$0.80-Review mit echten Prüfungen, 14 s deterministischer Block
Design	allein überspringen	berechnet dir Richtlinien, die du nicht kodiert hast
Test (kontinuierliche Evals)	kann warten	bis zu eine Stunde pro Lauf, leicht falsch ausgerichtet
Maintain	unbewiesen	braucht Wochen an Produktionstelemetrie

Maintain ist auf dem Papier elegant: Deterministische Skripte überwachen Kontrollbänder, und ein Verstoß schreibt eine neue Intent-Datei. Aber der Beweis braucht Produktionstelemetrie, die wir nicht haben. Anthropics eigenes Dokument enthält, wie ein Analyst es formulierte, nirgends eine Messung; das hier sind die ersten Zahlen, mit den offensichtlichen Grenzen: ein Repo, ein Entwickler, ein Tag.

Die Daten von außen sagen, der Druck ist real. Faros hat über 10.000 Entwickler in mehr als 1.200 Teams erfasst: Teams mit hoher Adoption mergen 98% mehr Pull Requests, die Review-Zeit steigt um 91%, und der durchschnittliche Pull Request wird mehr als doppelt so groß. Der neueste DORA-Report reimt sich darauf: Durchsatz steigt mit KI, Stabilität sinkt. Review wird zum Engpass, und das Playbook zielt genau darauf. Community-Varianten kürzen die Kette bereits auf zwei menschliche Entscheidungen: Eine liefert Templates und ein Gate-Ledger, die andere hält Menschen nur bei Design und Test. Übernimm die drei Gates, die sich auszahlen, und wachse in den Rest hinein, wenn dein Team es tut. Anthropics eigener Schlusssatz ist die passende Grabinschrift: Der Loop läuft weiter, menschliches Urteil bleibt darüber.