Claude Code unterstützt seit Version 2.1 einen eingebauten Plan Mode, den man über Shift+Tab aktiviert. Der Agent darf dann nur noch lesen -- Dateien inspizieren, Befehle ausführen, Recherche machen -- aber nichts verändern. Er muss einen schriftlichen Plan in eine vordefinierte Datei schreiben und ihn explizit per ExitPlanMode zur Freigabe vorlegen. Erst nach User-Zustimmung darf er ausführen. Dieses kleine Konstrukt verändert den Charakter riskanter Tasks komplett, und genau bei Infrastruktur-Umbauten sollte es zum Standard-Einstieg werden.
Wann Plan Mode Pflicht ist
Ein Plan Mode ist sinnvoll bei allem, was ein Rollback teuer macht:
- Migrationen zwischen Hostern, Datenbanken, Frameworks
- Schema-Änderungen an produktiven Datenbanken
- Entfernen von Infrastruktur (Accounts löschen, Container stoppen, DNS umbiegen)
- Multi-System-Umbauten, bei denen mehrere Dateien, Container und externe Dienste zusammenspielen
- Architektur-Entscheidungen, bei denen die Frage "wie machen wir das" wichtiger ist als "wie codieren wir das"
Trivial-Tasks wie "ändere diesen Textbaustein" brauchen keinen Plan Mode. Der Overhead lohnt sich erst, wenn man im Kopf nicht mehr sicher weiss, was der Agent tun wird, oder wenn ein Fehler mehr als fünf Minuten Aufräumen kostet.
Was der Plan abdecken muss
Der Plan ist kein Memo, sondern ein Arbeitsvertrag zwischen Nutzer und Agent. Ein brauchbarer Plan enthält:
- Context -- das Warum, der Ist-Zustand, das Ziel in zwei bis drei Sätzen
- Ziel-Architektur -- was soll am Ende stehen, wo verbindet sich was
- Konkrete Änderungen im Repo -- welche Dateien werden erstellt, geändert, gelöscht
- Serverseitige Schritte -- in welcher Reihenfolge, mit konkreten Kommandos
- Wiederverwendung statt Neu-Bau -- was im Repo oder auf dem Server existiert schon und wird genutzt
- Verifikation -- wie wird am Ende getestet, ob es läuft
- Offene Punkte für den Nutzer -- DNS-Umstellungen, Passwörter, Zustimmungen, die man nicht scripten kann
Wer den Plan in dieser Form bekommt, sieht den Blast Radius vorher. Wer nur "ja, mach mal" sagt, sieht ihn nachher.
Typische Fehler beim Einsatz
Plan zu früh verlassen. Wenn der Agent nach zehn Minuten Exploration schon ExitPlanMode ruft, aber im Plan Annahmen stehen ("vermutlich läuft auf dem Server Nginx"), dann ist das kein Plan, sondern ein Verdacht. Lieber per SSH nachschauen, Plan schärfen, dann freigeben.
Plan ohne Abbruchkanten. Ein Plan, der nur den Happy Path beschreibt, ist gefährlich. Gute Pläne benennen, was der Agent NICHT anfassen wird ("bestehende NPM-Container bleiben unverändert") und markieren die Punkte, an denen der Nutzer eingreifen muss.
Agent ohne Kontext planen lassen. Wer Plan Mode einschaltet, ohne dem Agenten vorher klar zu sagen, welche Dateien und welche Infrastruktur im Spiel sind, bekommt einen Plan, der auf halluzinierten Annahmen basiert. Erst Kontext, dann Plan.
Einmal genehmigen, dann nicht mehr mitlesen. Plan Mode ersetzt nicht das Beobachten der Ausführung. Nach der Genehmigung macht der Agent genau das, was im Plan steht -- wenn der Plan einen logischen Fehler hat, macht er den Fehler auch. Beim ersten Fehlschlag im Roll-out einzugreifen ist immer noch günstiger als hinterher zu reparieren.
Faustregel
Je grösser der Umbau, desto kleiner die Schrittweite, bis der erste ExitPlanMode fällt. Wer eine Migration plant, sollte bereit sein, zwei bis drei Iterationen im Plan Mode zu verbringen, bevor irgendein Container neu gestartet wird. Der Agent hat alle Zeit der Welt -- die Produktion nicht.
Quellen
- Claude Code 2.1.101: Ultraplan in der Cloud, Team-Onboarding-Generator und Enterprise-CA-Vertrauen -- dieser Artikel zum Release inkl.
/ultraplan-Variante - Wie Claude Code funktioniert -- Mechanik-Hintergrund
- Eigene Erfahrung aus der Migration
radar.chestersoft.de(Netlify → eigener Server), 2026-04-11