Sechs Phasen, zwölf Plays – und ein Praxischeck, der zeigt, welche Fähigkeiten Unternehmen für eine erfolgreiche Zusammenarbeit zwischen Menschen und KI-Agenten wirklich benötigen.

Ein KI-Agent hat eine neue Funktion für ein Kundenportal entwickelt.

Die Implementierung ist abgeschlossen. Die automatisierten Tests sind erfolgreich durchgelaufen. Der Pull Request liegt bereit. Technisch scheint alles in Ordnung.

Doch kurz vor dem Deployment stellt jemand eine entscheidende Frage:

Was passiert eigentlich mit bereits ausgestellten Rechnungen, wenn ein Kunde seine Rechnungsadresse ändert?

Der Agent hat genau das umgesetzt, was in der technischen Spezifikation stand. Das Problem: Eine wichtige fachliche Regel war dort gar nicht enthalten.

Das Beispiel ist fiktiv. Aber es zeigt eine Herausforderung, die mit zunehmender KI-Automatisierung an Bedeutung gewinnt.

Wir können die Softwareentwicklung beschleunigen. Doch können wir auch sicherstellen, dass am Ende das Richtige entwickelt wird?

Und sind unsere bestehenden Prozesse überhaupt darauf vorbereitet, wenn KI-Agenten zunehmend eigenständig Aufgaben übernehmen?

Genau an dieser Stelle setzt Anthropic mit seinem am 21. August 2026 veröffentlichten AI-native SDLC Playbook an.

Das Playbook beschreibt einen Software Development Life Cycle (SDLC), in dem KI-Agenten nicht nur Code erzeugen, sondern entlang des gesamten Entwicklungsprozesses mitarbeiten.

Ich finde diesen Ansatz bemerkenswert. Nicht, weil er sämtliche etablierten Vorgehensweisen infrage stellt, sondern weil er eine sehr konkrete Frage aufwirft:

Welche Fähigkeiten muss eine Organisation besitzen, damit aus KI-gestütztem Coding tatsächlich ein funktionierender AI-native SDLC werden kann?

Schauen wir uns das anhand des Playbooks und einer fiktiven Entwicklungsorganisation genauer an.

1. Was Anthropic mit dem AI-native SDLC verändern möchte

In vielen Unternehmen folgt die Softwareentwicklung einem bekannten Ablauf.

Aus einer Produktidee entstehen Anforderungen. Diese werden analysiert, konkretisiert und in technische Lösungen übersetzt. Anschließend folgen Implementierung, Qualitätssicherung, Freigabe und produktiver Betrieb.

Dazwischen liegen Abstimmungen, Tickets, Dokumente und Entscheidungen.

KI-Agenten verändern inzwischen vor allem die Geschwindigkeit, mit der einzelne Aufgaben erledigt werden können.

Doch was geschieht, wenn ein Agent innerhalb weniger Stunden implementiert, während die angrenzenden Prozesse weiterhin auf manuelle Übergaben ausgerichtet sind?

Anthropic schlägt deshalb vor, den gesamten Entwicklungsprozess stärker über versionierte Artefakte, automatisierte Übergaben und definierte Kontrollmechanismen miteinander zu verbinden.

Die Idee dahinter: Jede Phase erzeugt ein nachvollziehbares Ergebnis, das Menschen überprüfen und nachfolgende Agenten weiterverarbeiten können.

Eine fachliche Idee wird beispielsweise als intent.md dokumentiert. Daraus entsteht eine Spezifikation (spec.md), anschließend ein technischer Umsetzungsplan (plan.md). Codeänderungen, Testergebnisse, Pull Requests und Betriebsinformationen vervollständigen diese Artefaktkette.

Entscheidend ist, dass die Verantwortung nicht einfach an KI-Agenten übertragen wird. Menschen behalten die Verantwortung für Entscheidungen, bei denen fachliche Bewertung, Risikoabwägung oder Freigaben erforderlich sind.

Sechs Phasen und zwölf Plays

Anthropic strukturiert seinen Ansatz entlang von sechs Lifecycle-Phasen. Innerhalb dieser Phasen beschreibt das Playbook zwölf konkrete Vorgehensweisen, sogenannte Plays.

Phase	Die zwölf Plays nach Anthropic
PLAN	1. Ideen als intent.md erfassen
DESIGN	2. Anforderungen und Design entwickeln
BUILD	3. Plan Mode nutzen; 4. CLAUDE.md einsetzen; 5. Wissen durch Skills bereitstellen; 6. Parallele Sessions und Subagenten einsetzen
TEST	7. Feedbackschleifen ermöglichen; 8. Kontinuierliche Agenten-Evals in CI
DEPLOY	9. KI-gestützte PR-Reviews; 10. Hooks als Freigabegates; 11. CI/CD-Integration und Deployment
MAINTAIN	12. Betriebsmetriken zurück in den Lifecycle führen

Diese Phasen bilden einen zusammenhängenden Entwicklungszyklus. Die zwölf Plays sind allerdings keine starre Einführungsreihenfolge. Anthropic beschreibt ihre Abhängigkeiten ausdrücklich und ermöglicht damit einen schrittweisen Einstieg.

Ein Unternehmen kann beispielsweise mit CLAUDE.md, dem Plan Mode oder Feedbackschleifen beginnen, ohne zuvor den gesamten Planungsprozess umgestellt zu haben.

Meine Bewertung: Das Playbook beschreibt keine vollständige Neuerfindung der Softwareentwicklung. Sein Wert liegt vor allem darin, bestehende Entwicklungsfähigkeiten mit agentengestützter Ausführung, nachvollziehbaren Artefakten und geeigneten Kontrollen zu verbinden.

Quelle: Anthropic – The AI-native SDLC Playbook.

2. Ein Praxisbeispiel: Unsere Organisation beginnt nicht bei null

Um den Ansatz greifbar zu machen, betrachten wir ein fiktives Unternehmen.

Unser Beispiel ist ein mittelgroßer B2B-Softwareanbieter mit mehreren agilen Entwicklungsteams. Das Unternehmen besitzt ein etabliertes Kundenportal, eine ERP-Anbindung und eine gewachsene Entwicklungsorganisation.

Die technischen und organisatorischen Grundlagen sind durchaus solide:

• Product Owner und Product Backlogs
• Jira und Confluence für Anforderungen und Dokumentation
• Git-Repositories und definierte Entwicklungsstandards
• CI/CD-Pipelines
• Automatisierte Unit- und Integrationstests
• Architektur- und Security-Vorgaben
• Monitoring und Incident Management

Erste Entwickler verwenden bereits KI-gestützte Coding-Tools. Eine typische Organisation also, die viele Voraussetzungen für moderne Softwareentwicklung erfüllt.

Nun möchte das Unternehmen eine neue Funktion bereitstellen: Geschäftskunden sollen ihre Rechnungsadresse selbstständig im Kundenportal ändern können.

Was auf den ersten Blick überschaubar klingt, betrifft mehrere Systeme, fachliche Regeln und Verantwortlichkeiten.

An diesem Beispiel untersuchen wir, was unsere Organisation in jeder Phase des AI-native SDLC bereits kann – und welche zusätzlichen Fähigkeiten für den Einsatz von KI-Agenten erforderlich wären.

Die Beispielorganisation ist vollständig fiktiv. Alle beschriebenen Fähigkeiten und Lücken dienen der Illustration und sind keine Ergebnisse einer realen Unternehmensbewertung.

3. PLAN – Eine gute Idee ist noch keine gute Anforderung

Im ersten Play beschreibt Anthropic einen interessanten Ansatz. Die fachliche Idee wird gemeinsam mit Claude konkretisiert und in einem versionierten intent.md festgehalten.

Der Agent unterstützt dabei, das ursprüngliche Anliegen zu strukturieren. Welche Benutzer sind betroffen? Welches Problem soll gelöst werden? Welche Einschränkungen existieren? Woran erkennen wir, dass die gewünschte Verbesserung erreicht wurde?

Für unsere Rechnungsadressfunktion könnte der Intent beispielsweise enthalten:

• Problem: Kunden müssen Änderungen ihrer Rechnungsadresse derzeit über den Support veranlassen.
• Gewünschtes Ergebnis: Berechtigte Kunden können ihre Rechnungsadresse selbstständig ändern.
• Betroffene Systeme: Kundenportal, Benutzerverwaltung, ERP-System.
• Randbedingungen: Rollenberechtigungen, Datenschutz, Nachvollziehbarkeit und bestehende Abrechnungsregeln.
• Offene Fragen: Welche Auswirkungen haben Änderungen auf bestehende Rechnungen? Gibt es zusätzliche Freigabeanforderungen?

Der Product Owner überprüft diesen Intent, ergänzt fehlende Informationen und entscheidet über die fachliche Akzeptanz.

Was die Organisation bereits mitbringt

Unsere Beispielorganisation hat Product Owner, Backlogs und etablierte Abstimmungsprozesse. Damit verfügt sie über wichtige Grundlagen.

Was möglicherweise fehlt, sind einheitliche Standards für die Beschreibung fachlicher Ziele, Erfolgskriterien und Randbedingungen.

Hinzu kommt eine weitere Herausforderung: Ein intent.md darf nicht zu einer zusätzlichen, widersprüchlichen Informationsquelle werden.

Wenn Jira weiterhin das führende System für Anforderungen ist, muss klar geregelt sein, wie beide Artefakte miteinander verbunden werden. Anthropic berücksichtigt diesen Fall ausdrücklich und empfiehlt, für jedes Artefakt eine verbindliche Source of Truth festzulegen.

Meine Bewertung: Ein intent.md ist noch keine bessere Anforderung, nur weil ein Agent es geschrieben hat. Der eigentliche Fortschritt entsteht, wenn fachliche Unklarheiten früh erkannt, verbindlich geklärt und für nachfolgende Prozessschritte nachvollziehbar dokumentiert werden.

4. DESIGN – Wenn Organisationswissen für Agenten nutzbar werden muss

Nach dem fachlich akzeptierten Intent beginnt die Ausarbeitung der Lösung. Anthropic beschreibt, wie Agenten aus den Anforderungen eine Spezifikation entwickeln und dabei vorhandene Standards berücksichtigen können.

Diese Standards werden beispielsweise über Skills bereitgestellt. Ein Skill enthält wiederverwendbare Anweisungen, die einem Agenten helfen, bestimmte Aufgaben nach vereinbarten Regeln auszuführen.

Für unsere Beispielorganisation könnte ein Skill festlegen, wie neue API-Endpunkte gestaltet werden müssen. Ein weiterer beschreibt Security-Anforderungen oder den Umgang mit personenbezogenen Daten.

Der Agent verwendet diese Informationen bei der Erstellung der Spezifikation.

Was dafür notwendig ist

Viele Unternehmen besitzen umfangreiche Architektur- und Sicherheitsdokumentationen. Doch deren Existenz bedeutet nicht automatisch, dass sie für KI-Agenten geeignet sind.

Sind die Informationen aktuell? Sind Regeln eindeutig formuliert? Gibt es widersprüchliche Standards? Wer ist für Änderungen verantwortlich?

Und welches System ist für die jeweilige Information verbindlich?

Eine veraltete Architekturentscheidung in Confluence kann genauso problematisch sein wie eine unvollständige Skill-Anweisung.

Für unsere Rechnungsadressfunktion müssten beispielsweise Berechtigungsregeln, API-Verträge, Anforderungen an Audit-Logs und die Schnittstelle zum ERP-System eindeutig beschrieben sein.

Dabei ist eine technische Unterscheidung wichtig: Skills und CLAUDE.md vermitteln Anweisungen. Sie garantieren nicht, dass ein Agent diese Regeln in jeder Situation korrekt befolgt.

Verbindliche Sicherheits- und Berechtigungsvorgaben benötigen zusätzlich technisch durchgesetzte Kontrollen. Das Playbook unterscheidet ausdrücklich zwischen beratenden Vorgaben und kontrollierenden Mechanismen wie Hooks oder verwalteten Berechtigungseinstellungen.

Meine Bewertung: Organisationswissen wird im AI-native SDLC zunehmend zu einer operativen Fähigkeit. Dabei geht es nicht darum, möglichst viele Dokumente für Agenten zugänglich zu machen. Entscheidend sind Aktualität, Eindeutigkeit, Verbindlichkeit und die Qualität der bereitgestellten Informationen.

5. BUILD – Entwickler steuern zunehmend auch die Arbeit von Agenten

Die Build-Phase bildet den technischen Schwerpunkt des Playbooks.

Anthropic beschreibt unter anderem den Einsatz des Claude Code Plan Mode, die Verwendung von CLAUDE.md, wiederverwendbare Skills und die parallele Zusammenarbeit mit spezialisierten Subagenten.

Im Plan Mode erstellt Claude zunächst einen Implementierungsplan. Dieser kann beschreiben, welche Komponenten verändert werden müssen, welche technischen Alternativen bestehen und wie die Umsetzung überprüft werden soll.

Ein Entwickler überprüft den Plan, bevor die Implementierung beginnt.

Die Datei CLAUDE.md liefert dem Agenten dabei wichtige Informationen zur Codebasis: Architektur, verwendete Technologien, Build-Befehle, Coding-Standards und bekannte Fehlerquellen. Skills ergänzen wiederverwendbares Wissen für bestimmte Aufgaben.

Was bedeutet das für unseren Anwendungsfall?

Unsere Rechnungsadressfunktion betrifft möglicherweise drei Bereiche. Im Kundenportal muss eine neue Benutzeroberfläche entstehen. Ein Backend-Service muss die Berechtigungen prüfen und Änderungen verarbeiten. Die ERP-Schnittstelle muss mit den neuen Daten umgehen können.

KI-Agenten könnten diese Aufgaben teilweise parallel bearbeiten. Ein spezialisierter Agent untersucht die bestehende Schnittstelle. Ein anderer bereitet Änderungen am Frontend vor. Ein weiterer unterstützt bei Tests oder technischen Reviews.

Der Entwickler koordiniert diese Arbeiten und überprüft ihre Ergebnisse.

Das Potenzial ist offensichtlich. Allerdings entstehen neue Fragen: Wie verhindern wir widersprüchliche Änderungen? Welche Rechte besitzen die Agenten? Arbeiten sie in isolierten Umgebungen? Wie werden ihre Ergebnisse integriert?

Und wie viel parallele Arbeit kann ein Entwickler noch zuverlässig prüfen?

Meine Bewertung: Mehr Agenten bedeuten nicht automatisch mehr nutzbaren Durchsatz. Wenn Agenten schneller Code erzeugen, als Menschen oder automatisierte Kontrollen ihn prüfen können, entstehen neue Warteschlangen.

Die Entwicklerrolle verändert sich damit zunehmend in Richtung technischer Planung, Orchestrierung, Integration und Qualitätssicherung. Das macht fundierte Engineering-Kompetenz nicht überflüssig. Sie wird an anderer Stelle gebraucht.

6. TEST – Wer prüft eigentlich den Prüfer?

Eine der interessantesten Veränderungen beschreibt Anthropic in der Testphase. KI-Agenten sollen ihre Ergebnisse möglichst unmittelbar überprüfen können.

Dafür benötigen sie funktionierende Build- und Testbefehle, automatisierte Rückmeldungen und die Möglichkeit, Fehler zu analysieren und zu beheben.

Zusätzlich sieht das Playbook kontinuierliche Agenten-Evals vor.

Softwaretests und Agenten-Evals sind nicht dasselbe

Softwaretests prüfen das Verhalten der entwickelten Anwendung.

Unsere Rechnungsadressfunktion muss beispielsweise sicherstellen, dass Daten korrekt gespeichert werden, die Berechtigungsprüfung funktioniert und die ERP-Schnittstelle bei Fehlern zuverlässig reagiert.

Agenten-Evals untersuchen dagegen, ob ein KI-Agent bei definierten Aufgaben das erwartete Verhalten zeigt.

Beispielsweise könnte eine Eval prüfen, ob der Agent bei der Erstellung eines API-Endpunkts weiterhin die vereinbarten Vorgaben für Authentifizierung, Validierung und Protokollierung berücksichtigt.

Das ist besonders wichtig, wenn sich Agenteninstruktionen, Skills oder Konfigurationen ändern. Anthropic beschreibt hierfür automatisierte Eval-Suites, die in CI-Pipelines ausgeführt werden können.

Die Gefahr der Selbstbestätigung

Ein Agent erzeugt Code und schreibt dazu passende Tests. Doch wer überprüft, ob diese Tests überhaupt die richtigen fachlichen Anforderungen abdecken?

Wenn der Agent eine wichtige Geschäftsregel nicht kennt, kann es passieren, dass sowohl die Implementierung als auch die Tests denselben Fehler enthalten.

Die Rechnungsadressfunktion würde dann möglicherweise sämtliche technischen Tests bestehen – und trotzdem fachlich falsch funktionieren.

Deshalb benötigen wir unabhängige Prüfmechanismen, geeignete Testdaten und klare Qualitätskriterien. Auch Einschränkungen, die einem Agenten das Löschen oder Manipulieren bestimmter Tests untersagen, können sinnvoll sein.

Meine Bewertung: Je autonomer Agenten arbeiten, desto wichtiger wird die Unabhängigkeit der Qualitätssicherung. Die erfolgreiche Ausführung eines Agenten beweist noch nicht, dass das fachlich richtige Ergebnis entstanden ist.

7. DEPLOY – Autonomie braucht durchsetzbare Grenzen

Auch die Bereitstellung von Software möchte Anthropic stärker automatisieren. KI-Agenten können Pull Requests überprüfen, Review-Kommentare bearbeiten und CI/CD-Prozesse unterstützen.

Dabei kommen unter anderem sogenannte Hooks zum Einsatz. Hooks können bestimmte Aktionen erlauben, blockieren oder zusätzliche Prüf- und Freigabeschritte auslösen.

Beispielsweise könnte ein Agent Änderungen in einer Entwicklungsumgebung innerhalb festgelegter Grenzen selbstständig durchführen. Ein produktiver Release benötigt dagegen eine gesonderte Autorisierung, wenn der organisationsspezifische Freigabeprozess dies vorsieht.

Warum das für Unternehmen entscheidend ist

Unsere Beispielorganisation verfügt bereits über Release-Prozesse, automatisierte Security-Prüfungen und Freigabemechanismen.

Für agentengestützte Prozesse muss sie diese Kontrollen jedoch genauer definieren.

Welche Systeme darf ein Agent verändern? Welche Informationen darf er lesen? Welche Aktionen sind grundsätzlich ausgeschlossen? Wann genügt eine automatisierte Prüfung – und wann muss eine verantwortliche Person entscheiden?

Neben Hooks können verwaltete Berechtigungen, Sandbox-Isolation, Branch Protection und verbindliche CI-Prüfungen erforderlich sein.

Gerade kritische Regeln dürfen nicht allein auf einer Anweisung beruhen, die ein Agent interpretieren soll.

Auch Nachvollziehbarkeit ist wichtig: Welche Änderung wurde vorgenommen? Durch welchen Agenten? Auf Grundlage welcher Anforderung? Welche Prüfungen wurden durchlaufen? Wer hat die Freigabe erteilt?

Eine Commit-Historie kann hierbei helfen. Sie ersetzt aber nicht automatisch sämtliche Anforderungen an rechtliche oder regulatorische Nachweisführung.

Meine Bewertung: Die entscheidende Frage lautet nicht, wie viel Autonomie wir technisch ermöglichen können. Sie lautet, welche Autonomie wir unter den jeweiligen Risiken verantworten können.

Ein AI-native SDLC benötigt deshalb nicht weniger Governance, sondern eine Governance, die mit automatisierten Abläufen Schritt halten kann.

8. MAINTAIN – Wenn der Betrieb neue Entwicklungsaktivitäten auslöst

Die letzte Phase führt den Entwicklungsprozess zurück an seinen Anfang.

Anthropic beschreibt, wie Betriebsmetriken, Monitoring-Ereignisse oder Incidents neue Analysen und Entwicklungsaktivitäten auslösen können.

Ein Agent könnte beispielsweise auffällige Fehlermuster untersuchen, Diagnosedaten auswerten und einen Lösungsvorschlag vorbereiten.

Abhängig vom Ergebnis entsteht daraus eine technische Korrektur oder ein neuer Intent.

Zurück zu unserer Rechnungsadressfunktion

Die neue Funktion ist produktiv. Nach einigen Tagen zeigt das Monitoring, dass bestimmte Änderungen nicht korrekt an das ERP-System übertragen werden.

Ein Agent analysiert die Logs, untersucht mögliche Ursachen und bereitet einen Änderungsvorschlag vor.

Doch auch hier benötigen wir klare Grenzen. Nicht jedes auffällige Signal ist automatisch ein Bug. Nicht jede Abweichung rechtfertigt eine sofortige Softwareänderung. Und nicht jede technische Verbesserung besitzt dieselbe geschäftliche Priorität.

Eine Organisation muss deshalb festlegen, welche Signale automatisiert verarbeitet werden dürfen und wann ein Mensch über Priorität, Risiko und weitere Maßnahmen entscheidet.

Meine Bewertung: Ein geschlossener Lifecycle bedeutet nicht, dass jeder erkannte Fehler automatisch neue Entwicklung auslösen sollte. Sein Wert liegt darin, relevantes Feedback zuverlässig in Verbesserungen und bewusst getroffene Produktentscheidungen zurückzuführen.

9. Eine oft unterschätzte Frage: Wer orchestriert den gesamten Lifecycle?

Bisher haben wir betrachtet, wie Agenten innerhalb einzelner Phasen arbeiten können. Damit entsteht aber noch kein durchgängiger Prozess.

Entscheidend sind die Übergänge zwischen den Phasen.

Ein genehmigter Intent kann die Erstellung einer Spezifikation anstoßen. Eine akzeptierte Spezifikation kann einen Implementierungsplan auslösen. Ein zusammengeführter Pull Request startet eine Pipeline.

Anthropic beschreibt diese automatisierten Übergaben als wesentlichen Bestandteil seines Zielbildes.

Doch was passiert, wenn ein Übergang fehlschlägt?

Ein Agent erhält keine Antwort von einer API. Eine Pipeline wird abgebrochen. Eine Freigabe wird verweigert. Ein Ereignis wird versehentlich mehrfach verarbeitet.

Damit solche Situationen nicht zu unkontrollierten Aktionen führen, braucht es zusätzliche Fähigkeiten.

Dazu gehören eindeutig definierte Prozesszustände, nachvollziehbare Auslöser, Fehlerbehandlung, kontrollierte Wiederholungen und geeignete Mechanismen gegen doppelte Ausführungen – beispielsweise Idempotenz.

Ebenso wichtig sind Protokollierung und die Möglichkeit, einen Prozess nach einem Fehler sicher wiederaufzunehmen.

Für solche Aufgaben können bestehende CI/CD-Plattformen, ereignisbasierte Integrationen oder Workflow-Orchestrierungssysteme eingesetzt werden.

Auch n8n kann je nach Anwendungsfall eine geeignete Ergänzung sein. Es ist jedoch weder Voraussetzung noch verbindlicher Bestandteil des Anthropic-Playbooks.

Meine Bewertung: Ein AI-native SDLC ist erst dann wirklich belastbar, wenn nicht nur der erfolgreiche Ablauf funktioniert. Auch Fehler, Ausnahmen, abgelehnte Entscheidungen und Wiederanläufe müssen kontrollierbar bleiben.

10. Der Praxischeck: Wie AI-native ist unsere Beispielorganisation?

Kommen wir zurück zu unserer fiktiven B2B-Softwareorganisation. Sie besitzt bereits zahlreiche Grundlagen moderner Softwareentwicklung.

Product Management funktioniert. Architekturstandards sind vorhanden. Entwickler arbeiten mit Git, automatisierten Tests und CI/CD. Monitoring und Incident Management sind etabliert.

Trotzdem wäre es voreilig, die Organisation deshalb als AI-native einzustufen.

Denn eine vorhandene Fähigkeit ist nicht automatisch eine agententaugliche Fähigkeit.

Ein Architekturstandard kann beispielsweise gut dokumentiert sein, aber trotzdem nicht in einer Form vorliegen, die ein Agent zuverlässig verwenden kann.

Eine CI/CD-Pipeline kann technisch ausgereift sein, ohne geeignete Berechtigungsgrenzen für autonome Agenten zu besitzen.

Und eine gute Testautomatisierung beantwortet noch nicht die Frage, ob die eingesetzten Agenten selbst zuverlässig handeln.

Deshalb sollten wir den bestehenden Entwicklungsprozess entlang der sechs Lifecycle-Phasen betrachten.

Für jede Phase untersuchen wir:

• Was kann die Organisation bereits?
• Welche zusätzlichen Fähigkeiten benötigt sie?
• Welche Lücken bestehen?
• Welcher nächste Schritt wäre sinnvoll?

Was uns diese Standortbestimmung zeigt

Unsere Beispielorganisation müsste nicht sämtliche bestehenden Prozesse ersetzen. Sie könnte vielmehr auf vorhandenen Stärken aufbauen.

In der Planungsphase wäre beispielsweise ein standardisierter Intent ein sinnvoller Einstieg. Im Design könnten ausgewählte Architektur- und Sicherheitsregeln als Skills aufbereitet werden. In der Build-Phase ließen sich zunächst Plan Mode und CLAUDE.md etablieren.

In der Testphase wäre eine kleine Eval-Suite sinnvoll. Deploy und Maintain könnten anschließend gezielt um agententaugliche Kontrollen und automatisierte Rückkopplungen erweitert werden.

Wichtig ist dabei, dass nicht sämtliche Fähigkeiten gleichzeitig eingeführt werden müssen. Die zwölf Plays besitzen unterschiedliche Voraussetzungen. Anthropic stellt hierfür einen eigenen Abhängigkeitsgraphen bereit.

Meine Bewertung: Ein Readiness-Check sollte nicht beantworten, wie viel Prozent AI-native ein Unternehmen bereits ist. Er sollte sichtbar machen, welche Voraussetzungen für den nächsten sinnvollen Entwicklungsschritt vorhanden sind und wo tatsächliche Risiken oder Fähigkeitslücken bestehen. Das ist für mich der wesentlich praktischere Ansatz.

11. Was sagt die Forschung über die tatsächliche Wirkung von KI?

Bis hierhin haben wir vor allem Anthropics Playbook betrachtet. Das ist wichtig, aber nicht ausreichend.

Denn ein Hersteller-Playbook beschreibt zunächst empfohlene Vorgehensweisen. Daraus lässt sich noch nicht ableiten, dass jede Organisation mit diesen Maßnahmen automatisch bessere Ergebnisse erzielt.

Eine interessante Ergänzung liefert die DORA-Forschung von Google Cloud.

Der State of AI-assisted Software Development Report 2025 beschreibt KI insbesondere als Verstärker vorhandener organisatorischer Fähigkeiten.

Das bedeutet: Eine Organisation mit guten Entwicklungsplattformen, klaren Informationsflüssen, verlässlichen Tests und funktionierender Zusammenarbeit besitzt günstige Voraussetzungen, um vom KI-Einsatz zu profitieren.

Bestehende Schwächen verschwinden dagegen nicht allein durch leistungsfähigere Modelle. Im Gegenteil: Fragmentierte Toolchains, unklare Verantwortlichkeiten oder mangelhafte Qualitätssicherung können sich bei zunehmender Automatisierung stärker auswirken.

Besonders relevant ist ein Befund aus der DORA-Forschung: Höhere KI-Adoption war 2025 sowohl mit höherem Software Delivery Throughput als auch mit höherer Delivery-Instabilität verbunden.

Das sind statistische Zusammenhänge und keine allgemeingültigen Ursache-Wirkungs-Beweise.

Eine ergänzende DORA-Analyse vom März 2026 beschreibt zudem, dass Entwickler einen Teil der bei der Codegenerierung gewonnenen Zeit für zusätzliche Überprüfung und Validierung verwenden.

Darin sehe ich einen wichtigen Hinweis: Schneller erzeugter Code ist nicht dasselbe wie schneller bereitgestellter Geschäftswert.

Wer den Nutzen eines AI-native SDLC bewerten möchte, sollte deshalb mehrere Dimensionen gemeinsam betrachten:

• End-to-End-Flow-Time statt alleiniger Coding-Zeit
• Qualität, Stabilität und produktive Fehler
• Nacharbeit und Review-Aufwand
• Kosten und Ressourcenverbrauch der Agenten
• Tatsächliche Produktnutzung und Business Outcomes

Erst aus dieser Gesamtbetrachtung lässt sich beurteilen, ob eine Veränderung den Entwicklungsprozess wirklich verbessert.

12. Was mich am Anthropic-Playbook überzeugt – und wo Fragen offenbleiben

Das Playbook besitzt für mich drei wesentliche Stärken.

Erstens: Es betrachtet nicht nur die Codegenerierung, sondern mehrere Phasen des gesamten Entwicklungsprozesses.

Zweitens: Es verbindet Automatisierung mit nachvollziehbaren Artefakten, Prüfungen und menschlichen Entscheidungen.

Drittens: Es ermöglicht einen schrittweisen Einstieg, statt einen vollständigen organisatorischen Neustart vorauszusetzen.

Gleichzeitig sehe ich drei Bereiche, die wir kritisch betrachten sollten.

Wie viel Standardisierung ist sinnvoll?

Versionierte Spezifikationen und verbindliche Regeln können Qualität und Nachvollziehbarkeit verbessern. Aber nicht jedes Produktproblem lässt sich vollständig im Voraus beschreiben.

Gerade innovative Produktentwicklung benötigt Exploration, Experimente und kontinuierliche Rückmeldungen.

Ein AI-native SDLC darf deshalb nicht dazu führen, dass aus einem aufwendigen Dokumentationsprozess lediglich ein schnellerer automatisierter Dokumentationsprozess wird.

Wie verändert sich die Zusammenarbeit?

Anthropic beschreibt detailliert, wie Agenten innerhalb verschiedener Entwicklungsphasen eingesetzt werden können.

Die weitergehenden Auswirkungen auf Organisationsdesign, Portfolioentscheidungen und die Zusammenarbeit mehrerer Teams bleiben jedoch ein zusätzliches Untersuchungsfeld. Die Verschiebung organisatorischer Engpässe ist dabei ein zusätzlicher Aspekt.

Was bedeutet das für Product Owner, Architekten, Engineering Leads oder agile Führungskräfte? Welche Synchronisationsmechanismen benötigen wir weiterhin? Und welche könnten tatsächlich vereinfacht werden?

Aus meiner Erfahrung mit skalierten Entwicklungsorganisationen halte ich diese Fragen für mindestens ebenso relevant wie die technische Umsetzung.

Wie stellen wir den tatsächlichen Geschäftswert sicher?

Ein Agent kann eine technisch korrekte Funktion implementieren. Er kann dabei sämtliche Tests bestehen. Trotzdem kann das Ergebnis am tatsächlichen Kundenbedarf vorbeigehen.

Deshalb benötigt auch ein AI-native SDLC eine klare Verbindung zwischen Produktzielen, Entwicklungsarbeit, Nutzerfeedback und wirtschaftlichem Nutzen.

Meine Bewertung: Das Anthropic-Playbook ist ein interessanter Baustein für die Weiterentwicklung von Softwareorganisationen. Ein vollständiges organisatorisches Operating Model ersetzt es jedoch nicht.

13. Wie würde ich mit der Einführung beginnen?

Ich würde nicht empfehlen, alle zwölf Plays gleichzeitig einzuführen. Stattdessen erscheint mir ein begrenzter Pilot sinnvoller.

Schritt 1: Einen geeigneten Anwendungsfall auswählen

Ein überschaubares Feature mit klaren Anforderungen, vorhandenen Tests und einem beherrschbaren Risiko.

Unsere Rechnungsadressfunktion wäre dafür ein mögliches Beispiel, sofern die fachlichen Regeln ausreichend geklärt sind.

Schritt 2: Vorhandene Fähigkeiten überprüfen

Welche Informationen sind bereits vorhanden? Welche technischen Standards gelten? Wie funktionieren Reviews und Freigaben? Welche Systeme sind führend?

Schritt 3: Wenige geeignete Plays kombinieren

Beispielsweise strukturierte Intents, Plan Mode, CLAUDE.md und automatisierte Feedbackschleifen.

Die Auswahl richtet sich nach den jeweiligen Voraussetzungen – nicht nach der Reihenfolge der Lifecycle-Phasen.

Schritt 4: Wirkung messen und gezielt erweitern

Nicht nur die Dauer der Codeerstellung vergleichen, sondern den vollständigen Prozess bis zu einer überprüften, nutzbaren Änderung.

Dabei sollten Qualität, Sicherheit, Nacharbeit, Kontrollaufwand und Agentenkosten berücksichtigt werden.

Erst wenn die Ergebnisse belastbar sind, würde ich weitere Prozesse oder Autonomiestufen einbeziehen.

Als zusätzliche Orientierung kann das DORA AI Capabilities Model dienen, das sieben organisatorische Fähigkeiten zur wirksamen KI-Nutzung beschreibt.

14. Der Selbstcheck: Sechs Fragen an deine Organisation

Wenn du Anthropics Playbook morgen in deiner Organisation einsetzen wolltest, wie würdest du diese Fragen beantworten?

SDLC-Phase	Die entscheidende Frage
PLAN	Können Menschen und Agenten fachliche Ziele, Erfolgskriterien und Randbedingungen eindeutig verstehen?
DESIGN	Sind Architektur-, Sicherheits- und Produktstandards aktuell, zugänglich und verbindlich?
BUILD	Können Agenten innerhalb definierter Berechtigungen arbeiten und ihre Ergebnisse nachvollziehbar integrieren?
TEST	Können wir sowohl die entwickelte Software als auch das Verhalten der Agenten zuverlässig überprüfen?
DEPLOY	Sind Freigaben, Sicherheitskontrollen und Autonomiegrenzen technisch durchsetzbar?
MAINTAIN	Können Betriebsinformationen kontrolliert in neue Entwicklungsaktivitäten zurückfließen?

Nicht jede Frage muss sofort vollständig positiv beantwortet werden. Entscheidend ist, zu erkennen, wo vorhandene Fähigkeiten ausreichen und wo gezielt weiterentwickelt werden muss.

Genau darin sehe ich den praktischen Nutzen eines AI-native SDLC Readiness Checks.

15. Mein Fazit: AI-native ist keine Eigenschaft eines Tools

Anthropics AI-native SDLC Playbook beschreibt eine mögliche Zukunft der Softwareentwicklung, in der KI-Agenten über den gesamten Lifecycle hinweg zunehmend eigenständig Aufgaben übernehmen.

Das ist technisch interessant. Noch spannender finde ich aber die organisatorischen Konsequenzen.

Viele Unternehmen besitzen heute bereits einen großen Teil der notwendigen Grundlagen. Sie haben erfahrene Entwickler, etablierte Prozesse, Architekturstandards, Qualitätssicherung und Governance.

Die Herausforderung besteht nicht darin, diese Fähigkeiten vollständig zu ersetzen. Sie besteht darin, sie für eine neue Form der Zusammenarbeit zwischen Menschen, KI-Agenten und bestehenden Systemen weiterzuentwickeln.

Dabei sollten wir einen wichtigen Unterschied nicht übersehen:

Automatisierung ist eine technische Fähigkeit. Autonomie ist eine Frage von Verantwortung, Vertrauen und Kontrolle.

Ein erfolgreicher AI-native SDLC benötigt beides.

Deshalb würde ich nicht mit der Frage beginnen, welches KI-Tool ein Unternehmen als Nächstes einführen sollte.

Mich interessiert vielmehr: Welche Fähigkeiten fehlen der Organisation heute noch, damit sie KI-Agenten morgen zuverlässig und verantwortungsvoll einsetzen kann?

Und genau hier würde mich die Erfahrung anderer interessieren.

Wenn ihr auf euren eigenen Entwicklungsprozess schaut: In welcher der sechs SDLC-Phasen seid ihr bereits gut vorbereitet – und wo seht ihr aktuell die größte Hürde?

Quellen und weiterführende Literatur

1. Louis Claxton / Anthropic (21. August 2026): The AI-native SDLC Playbook. Primärquelle für die sechs Phasen, zwölf Plays und die technischen Vorgehensweisen. Originalartikel lesen.
2. Anthropic / Claude Academy: The AI-native SDLC Playbook – What Changes and Where to Start. Vertiefende Informationen zu Plays, Voraussetzungen und Abhängigkeiten. Claude Academy.
3. Google Cloud / DORA (2025): State of AI-assisted Software Development. Forschung zu KI-Adoption, organisatorischer Leistungsfähigkeit und Software Delivery. DORA Report 2025.
4. Jessica Baolin und Nathen Harvey / DORA (10. März 2026): Balancing AI Tensions: Moving from AI Adoption to Effective SDLC Use. Analyse der Zielkonflikte zwischen KI-gestützter Entwicklung, Geschwindigkeit und Verifikationsaufwand. DORA Insights.
5. DORA (2025): AI Capabilities Model. Sieben organisatorische Fähigkeiten zur Unterstützung wirksamer KI-Nutzung. AI Capabilities Model.
6. NIST (2024): Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Ergänzender Referenzrahmen zu Risiken und Governance generativer KI. NIST AI RMF.

Transparenzhinweis: Dieser Beitrag wurde mit Unterstützung generativer KI recherchiert und redaktionell ausgearbeitet. Die fachlichen Bewertungen, die abschließende Prüfung und die Verantwortung für die veröffentlichten Inhalte liegen beim Autor André Ullmann.