KI-nativer SDLC mit Claude Code: planen, bauen, prüfen

Dieser Kurs wurde unter Zuhilfenahme von künstlicher Intelligenz erstellt.

Etwa acht Wochen, nachdem eine Engineering-Organisation agentisches Programmieren für alle freigegeben hat, passiert etwas ganz Bestimmtes. Das Volumen gemergter Pull Requests verdoppelt sich ungefähr. Alle feiern. Und dann kommt die zweite Zahl: Die mediane Review-Zeit steigt, die Change-Failure-Rate klettert, und ein Quartal später fragt jemand in einem Audit, wer die Änderung freigegeben hat, die ein Agent um zwei Uhr nachts geschrieben hat — und niemand kann es beantworten.

Das ist kein KI-Problem. Es ist ein Prozessproblem. Wir sind sehr gut darin geworden, KI Code schreiben zu lassen, und haben jede Phase rund um den Code im menschlichen Tempo weiterlaufen lassen.

Dieser Kurs baut den Lebenszyklus selbst um. Er folgt dem AI-Native SDLC Playbook von Anthropic — sechs Phasen, angeordnet als Kreislauf statt als Linie: Jede Phase endet mit dem Commit eines Artefakts, und die nächste beginnt damit, es zu lesen. Sie bauen die ganze Kette: eine Absichtsdatei, eine Spezifikation, einen Plan, den Diff mit seinen Tests, den Pull Request mit seinen Review-Befunden und den Vorfallsbericht, der die nächste Absicht schreibt.

Jeder Mechanismus wird gebaut, nicht nur beschrieben. Sie schreiben einen PreToolUse-Hook, der eine Bearbeitung blockiert und den Freigabeweg nennt. Sie befragen Claude zu einem Plan, bevor eine Zeile Code existiert. Sie richten eine Eval-Suite ein, die die Konfiguration Ihres Agenten per Regressionstest prüft, wenn sich ein Skill ändert. Sie schreiben eine Review-Richtlinie mit Schweregrad-Schwelle und Nit-Obergrenze. Sie setzen ein Produktions-Gate, bis zu dem der Agent handeln darf und das er nicht passieren kann. Und Sie richten statistische Kontrollgrenzen ein, sodass eine Grenzverletzung bei drei Sigma sich selbst diagnostiziert und eine Absichtsdatei anlegt, bevor jemand alarmiert wird.

Governance ist ein vollwertiges Anliegen, kein Nachgedanke. Jedes Play in diesem Kurs benennt, was durchgesetzt wird, was der Nachweis ist, wo er protokolliert wird und wer freigibt. Sie lernen den teuersten Designfehler, den Teams machen — die falsche Stärke einer Kontrolle zu wählen — und den Unterschied zwischen einer Regel, die hält, und einem Satz in einer Datei, den niemand durchsetzt.

Wir arbeiten durchgehend mit einem Unternehmen. Meridian Pay ist eine B2B-Zahlungsplattform mit 640 Mitarbeitenden: von der britischen Finanzaufsicht FCA zugelassen, mit seiner EU-Gesellschaft im Anwendungsbereich von DORA, PCI DSS auf dem Karteninhaberpfad, SOC 2 und ISO 27001. Das Unternehmen hat Claude Code an 90 Engineers ausgerollt, sein PR-Volumen verdoppelt, die Change-Failure-Rate von 8 % auf 19 % steigen sehen und ein internes Audit nicht bestanden, weil es nicht nachweisen konnte, wer agentenerstellte Änderungen im PCI-Scope freigegeben hatte. Der CTO hat ein Quartal, um das zu beheben, ohne das Tempo wieder abzugeben. Jede Entscheidung in diesem Kurs wird unter dieser Vorgabe getroffen.

Sie gehen mit Artefakten nach Hause, nicht mit Notizen. Vorlagen für Absicht, Spezifikation, Plan und Review. Ein Hook für geschützte Pfade und ein Produktions-Gate-Hook. Ein Einstieg in eine Eval-Suite. Eine Konfiguration für Kontrollgrenzen. Ein Paket aus Früh- und Spätindikatoren mit einem Schritt zur Erfassung der Baseline. Ein Arbeitsblatt, das jedes Gate NIST SSDF, ISO/IEC 42001 und SOC 2 zuordnet. Und einen 90-Tage-Rollout-Plan, den Sie am Montag vor Ihrer Leitung vertreten können.

Fünfunddreißig Lektionen, acht Kapitel, fünf Aufgaben und eine abschließende Übungsprüfung. Für Engineering Leads, Plattform-Teams und alle, die für das Tempo und die Nachweise verantwortlich sind.