Anthropic hat ein Dokument mit dem Titel „The AI-native software development lifecycle" veröffentlicht und darin den intern rund um Claude neu aufgebauten Entwicklungsprozess des Unternehmens öffentlich in sechs Phasen aufgeschlüsselt. Der Ausgangspunkt des Dokuments wird unverblümt benannt: Codegenerierung ist nicht mehr der Flaschenhals; klassische Prozesse waren auf das Tempo von Menschen ausgelegt, die Code von Hand schreiben, weshalb sich der Engpass schlicht verschoben hat.
Die sechs Phasen sind der Reihe nach Planung, Design, Build, Test, Deployment und Wartung, und die Vorgehensweise in jeder Phase wurde neu geschrieben. Aus Anforderungsmeetings plus handschriftlichen Dokumenten wird in der Planungsphase ein Gespräch mit Claude, das eine intent.md erzeugt — laut Dokument verkürzt sich der Zyklus dadurch von Wochen auf Stunden. Das Design erzeugt in einer einzigen Session eine spec.md und lässt eine Policy-Prüfung durchlaufen. Der Build beginnt mit einer plan.md, bevor es an die eigentliche Umsetzung geht. Tests warten nicht mehr an Phasengrenzen — kontinuierliche Bewertung wird direkt in den Implementierungsprozess eingebettet. Das Deployment wird durch mehrschichtige automatisierte Reviews plus Hook-Kontrollen ersetzt. Die Wartung wiederum wechselt von passivem Reagieren auf Alarme zu automatischer Erkennung, die eine neue intent.md erzeugt und so zum Ausgangspunkt zurückführt.
Was diese sechs Phasen verbindet, sind Dateien, keine Meetings. intent.md übergibt an spec.md, spec.md übergibt an plan.md, danach folgen Pull Request und Review-Ergebnis, und am Ende schließt ein Vorfallsbericht den Kreis zurück zur intent.md. Das Dokument fasst diese Kette in einem Satz zusammen: Jede Phase liefert ein Artefakt ab, das die nächste Phase liest.
Vier Governance-Bausteine
Skills tragen institutionalisiertes Wissen. Dinge wie API-Sicherheitsstandards oder Markenrichtlinien werden in .claude/skills/ festgehalten; ändert sich die Policy, wird sie zentral einmal angepasst, und Ingenieure erhalten die neue Version automatisch in ihrer nächsten Session. Das Beispiel im Dokument ist ein Skill namens secure-api-review, der Authentifizierung, Eingabevalidierung und Audit-Logging überwacht.
Hooks übernehmen deterministische Kontrolle, ohne dass ein manueller Umweg möglich ist. In der Build-Phase blockieren sie Änderungen an eingefrorenen Abhängigkeitspaketen und erzwingen einen Formatierungslauf; in der Deployment-Phase benötigt ein Produktions-Release die Freigabe eines Release Managers — fehlt sie, wird der Vorgang mit Exit-Code 2 direkt gestoppt.
CLAUDE.md ist das Gedächtnis des Teams und auf eine Seite begrenzt: Build-Befehle, Konventionen, Architektur, häufige Fehler. Die Pflegeregel des Dokuments ist pragmatisch — passiert derselbe Fehler ein zweites Mal, wird er eingetragen.
evals dienen als Regressionstests. Ein Bewertungssatz aus 20 bis 50 realen Aufgaben läuft bei jeder Konfigurationsänderung, dazu ein täglicher Lauf über Nacht; jeder Produktionsvorfall wird zu einem dauerhaften Eval gemacht, und die Bestehensquote fließt direkt als Merge-Bedingung ein.
Wie ein Feature zur Schadensstatusabfrage den gesamten Prozess durchläuft
Der im Dokument durchgespielte Fall ist eine Self-Service-Funktion zur Abfrage des Schadensstatus. Das Operations-Team schreibt zunächst eine intent.md, die Problem, Nutzer und Randbedingungen beschreibt; erst nach Prüfung und Freigabe durch den Product Lead beginnt die Designphase. Claude wendet UX- und Sicherheits-Skills an, um eine spec.md zu erzeugen; ein Ingenieur wechselt in den Plan-Modus, um eine plan.md zu erhalten, danach setzt Claude Code die Implementierung um, und der Pull Request wird gemerged, sobald er den Review-Hook besteht.
Randbedingungen werden explizit in den Plan geschrieben: Die claims-core-Schnittstelle ist auf 50 Requests pro Sekunde begrenzt, weshalb plan.md die Notwendigkeit von Caching vermerkt; während der Session dürfen keine personenbezogenen Daten hinzugefügt werden; die Authentifizierung nutzt das bestehende Verfahren. Ein anderes Team, zuständig für den Payment-Service, hat eine CLAUDE.md, in der steht: Java 21, Spring Boot 3, kein Lombok, Beträge müssen BigDecimal statt double verwenden, und die Abhängigkeitsversionen werden vom Plattformteam verwaltet und dürfen nicht angefasst werden.
Die Automatisierung in der Wartungsphase ist in drei Schwellenstufen gestaffelt. Am Beispiel der CI-Testfehlerquote: Die Baseline ergibt sich aus einem gleitenden 30-Tage-Fenster, bei 1 Sigma wird nur protokolliert, bei 2 Sigma erhält Claude Nur-Lese-Zugriff für eine Diagnose, erst bei 3 Sigma darf es einen Pull Request öffnen oder ein vorab genehmigtes Runbook auslösen. Das Anomalieerkennungs-Skript selbst arbeitet deterministisch — es nutzt die Western-Electric-Regeln zur Beurteilung, nicht ein Modell.
Die Kennzahlenliste verrät, wer die eigentliche Zielgruppe ist
Zu den Frühindikatoren zählen die Zeit vom ersten Gespräch bis zur Einreichung der intent.md, die Zeit von der Einreichung bis zum ersten Review, die Zahl gleichzeitig laufender Agent-Sessions sowie die CI-Erfolgsquote. Zu den Spätindikatoren zählen die Freigabequote von intent.md-Dokumenten, die Erfolgsquote der Erstimplementierung, der Trend bei den in PR-Reviews gefundenen Problemen, die Wiederholungsrate von Produktionsvorfällen sowie die Zahl der pro Ingenieur und Woche gemergten Pull Requests.
Dazu kommen zwei passende Compliance-Pfade: Der eine nutzt Jira oder ServiceNow als maßgebliches Systemprotokoll, wobei Markdown lediglich als Arbeitskopie dient und über einen MCP-Connector zurück ins Altsystem synchronisiert wird; der andere behandelt das Repository als alleinige Quelle der Wahrheit, wobei Altsysteme nur auf Commit-SHAs verweisen. Die Audit-Spur setzt sich aus vier Kanälen zusammen: Git-Historie, PR-Diskussionsverläufe, über OpenTelemetry exportierte Protokolle des Agent-Verhaltens sowie Freigabe-/Blockier-Logs der Hooks.
All das ist nicht auf einzelne Entwickler zugeschnitten. Grob überschlagen: Eine Engineering-Organisation mit zwei- bis dreihundert Mitarbeitenden, die einen Bewertungssatz in der im Dokument beschriebenen Größenordnung ausrollt und ihn bei jeder Konfigurationsänderung plus einmal täglich laufen lässt, hat allein bei den Inferenzkosten eine dauerhafte Jahresrechnung — hinzu kommt, dass Skills und Hooks eigenes Fachpersonal zur Pflege brauchen. Die Governance-Bausteine selbst kosten Geld und Personal, während sich der Nutzen oft erst nach mehreren Quartalen zeigt. Genau daran scheitert ein solcher Prozessumbau bei mittelgroßen Unternehmen meist. Organisationen, die bereit sind, für eine Audit-Spur zu zahlen, sind die eigentliche Zielgruppe dieses Handbuchs.
Quellen: offizielle Engineering-Dokumentation von Anthropic, CocoLoop, Produktdokumentation zu Claude Code; abgeglichen anhand der Benennung der Artefakte der sechs Phasen, der Konfiguration der drei Schwellenstufen und der Größe des Bewertungssatzes.