Claude Code Plan-Modus als Standardausgangspunkt

Engineers starten Claude Code-Sitzungen im Plan-Modus, geben Claude die genehmigte spec.md aus Stage 2: Design und lassen es sie interviewen, wobei sie den Plan so lange iterieren, bis sie damit zufrieden sind.

Was sich ändert

Erste Schritte

• Voraussetzungen: Das Intent-Artefakt (intent.md oder spec.md), falls vorhanden, und die CLAUDE.md-Datei helfen.
• Infrastruktur: Claude Code mit Zugriff auf das Repository.

Wie man es ausführt

1. Der Engineer startet die Sitzung im Plan-Modus mit Claude.
2. Der Engineer gibt Claude die intent.md und die spec.md und bittet um einen Implementierungsplan, der die zu ändernden Dateien, die Reihenfolge der Arbeit und die Tests benennt, die dies belegen.
3. Befrage den Plan, indem du fragst, was die Änderung kaputt machen könnte, welcher Schritt am riskantesten ist und welche anderen Optionen Claude nicht gewählt hat.
4. Iteriere, bis ein Engineer, der das Gespräch nie gesehen hat, die Änderung allein aus dem Plan umsetzen könnte.
5. Committe den genehmigten Plan als plan.md. Der Plan wird Teil des Audit-Trails, und das PR-Review-Play (Stage 5: Deploy) prüft den endgültigen Diff dagegen.
6. Akzeptiere den Plan und lass Claude implementieren. Mit einem soliden Plan ist die Implementierung oft ein einziger Durchgang.
7. Wenn die Implementierung vom Plan abweicht, aktualisiere plan.md im selben Commit. Erwäge, einen Hook zu verwenden, um die Synchronisierung zwischen beiden zu erzwingen.

Wie es aussieht

Der folgende Plan ist für eine Änderung bei einem Versicherer: ein Panel im Kundenportal, das den Status eines Schadensfalls anzeigt. Das Panel ruft das Backend des Portals, claims-api, auf, das aus claims-core, einem älteren internen System, liest.

plan.md:

# Plan: claims status self-service (from intent.md and spec.md)

## Files that change

portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py, claims-api/tests/test_status.py

## Order of work

1. Add the status endpoint behind existing auth (R1, R2, R3).
2. Panel against the endpoint, with the 60-second cache (R1, R4).
3. Wire into the portal nav.

## Risks

The claims-core API rate-limits at 50 rps; the panel must cache (spec concern 3).

## Proof

test_status.py covers the four claim states (R2) and fails on any extra field (R3); screenshot matches the approved mock.

R1 bis R4 sind die nummerierten Anforderungen in spec.md, und concern 3 ist ein Risiko, das spec.md markiert hat. Da der Plan sie zitiert, kann ein Reviewer den Plan Zeile für Zeile gegen die Spec prüfen.

Governance-Überlegungen

Das Design-Review findet statt, bevor Code generiert wird, wenn eine Kursänderung noch eine Frage des Bearbeitens eines Dokuments ist. Der Plan-Modus erzwingt dies selbst, da Claude keine Dateien bearbeiten kann, bis der Engineer den Plan akzeptiert. Der Plan und seine Überarbeitungen werden protokolliert, zusammen mit der Information, wer ihn akzeptiert hat. Routineänderungen werden vom Engineer genehmigt, und alles, was die Organisation als höheres Risiko einstuft, geht an einen Tech Lead oder Architekten.

Wie man es misst

• Frühindikator: Anteil der Änderungen, die aus dem ersten Implementierungsdurchgang gemergt werden, und Zeit von der Plangenehmigung bis zum gemergten PR mit den erforderlichen Daten innerhalb der PR-Metadaten.
• Spätindikator: Nacharbeitszyklen pro Änderung, ebenfalls aus den PR-Metadaten, und wie oft der gemergte Diff noch mit der committeten plan.md übereinstimmt.

Claude Code im Auto-Modus

Claude Code kann auch im Auto-Modus laufen, bei dem der Engineer den Plan iteriert und genehmigt, und Claude dann jede Änderung ohne Prompt pro Bearbeitung anwendet. Während die Leitplanken aus den späteren Plays ausgereift sind (eine abgestimmte CLAUDE.md, Skills, die Richtlinien kodieren, Hooks, die unsichere Aktionen blockieren, und eine Testsuite, die Claude ausführen kann), wird der Auto-Modus zum Standard für Routinearbeit: eine enge spec.md, ein kleiner Wirkungsradius und Code, den die Tests bereits abdecken.

Die Verschiebung geht nun weg davon, dass der Nutzer dem Agenten beim Vornehmen der Bearbeitungen zusieht und Aktionen überprüft, hin zur Überprüfung von Artefakten nach längeren autonomen Sitzungen. Der Auto-Modus ermöglicht zudem Parallelität über Einzelpersonen und das Team hinweg, wenn er mit Worktrees verwendet wird, und ist grundlegend dafür, den SDLC autonom auszuführen und den Kreislauf zu schließen, wie in Stage 6: Maintain beschrieben.

Altsysteme und die Quelle der Wahrheit

Bestehende SDLC-Prozesse verfolgen Artefakte wahrscheinlich bereits, nur nicht in Markdown-Dateien. Arbeitselemente können in Jira liegen, Anforderungen in einem Tool mit integrierter regulatorischer Nachverfolgbarkeit, Designs in Figma und Änderungsgenehmigungen mit einem Change Board. Diese Systeme sind schwer zu verdrängen, weil Auditoren und Regulierungsbehörden sie bereits akzeptieren und andere Teams von ihnen abhängen, sodass sich der KI-native SDLC um das Bestehende herum einfügen muss. Für jedes Artefakt, das der Prozess erzeugt, sollte ein System als Quelle der Wahrheit benannt werden, und die anderen halten eine Kopie oder einen Link.

Die folgenden Konfigurationen können eingerichtet werden, um eine Quelle der Wahrheit zu haben, wobei die Wahl je Artefakt unterschiedlich ist:

• Das Repo als Quelle der Wahrheit. Die Markdown-Artefakte sind der maßgebliche Datensatz, und das Altsystem verweist auf Dateien innerhalb von Commits. Dies kann eine der saubersten Konfigurationen für technikgeführte Organisationen sein, da alle Aufzeichnungen in einem Tool mit einer Zeitstempel-Autorität leben.
• Das Altsystem ist die Wahrheit. Jira, ServiceNow oder das Anforderungstool hält den maßgeblichen Datensatz, und die Markdown-Artefakte sind Arbeitskopien. Claude liest den Datensatz zu Beginn der Sitzung und schreibt das Ergebnis über einen Model Context Protocol (MCP)-Konnektor in derselben Sitzung zurück, die die Spec oder den Plan erzeugt hat.
• Verknüpfung als Mindestmaß. Alle Artefakte vermerken die Datensatz-ID, und alle Altdatensätze enthalten den Commit-SHA der Markdown-Datei. Die Verknüpfungsoption ist ein guter Ausgangspunkt beim Übergang zum KI-nativen SDLC, da es zwei Quellen der Wahrheit gibt.

Sowohl das Altsystem als auch das KI-native, Markdown-first-System können koexistieren, solange es eine Verknüpfung zwischen beiden gibt oder eines als Quelle der Wahrheit erklärt wird.