Claude Code Plan Mode: wann er sich lohnt und wann nicht

Ich muss ehrlich zugeben, dass ich den Plan Mode viel zu selten nutze. Gerade bei Bugs neige ich dazu, schnell ein Ergebnis zu wollen, und dann überspringe ich ihn.

Bei größeren Features nutze ich ihn dagegen gerne. Dann habe ich einen besseren Eindruck davon, was passieren wird und wie Claude es umsetzen will.

Das ist die ganze Regel, die ich habe: keine. Ich entscheide es aus dem Bauch heraus, und die Grenze liegt ungefähr bei der Größe der Änderung.

Angefangen habe ich am anderen Ende. Gerade zu Beginn habe ich den Plan Mode auch für Kleinigkeiten benutzt, bei denen ein Plan eigentlich gar nicht notwendig war.

Von dort bin ich ins andere Extrem gependelt. Heute lasse ich ihn dort weg, wo er vermutlich nützen würde: bei der Fehlersuche, wo ich es eben schnell wissen will.

Das Thema ist damit weniger eine Frage der Technik als eine der Kalibrierung. Wie man den Plan Mode einschaltet, steht in der Dokumentation. Wann man ihn einschalten sollte, lernt man nur, indem man es beide Male falsch macht. Dasselbe Muster hatte ich bei den Skills: erst einen gebaut, für den es keinen wiederkehrenden Fall gab, und daraus die Regel abgeleitet.

Das letzte gute Beispiel war die Anbindung von Passkeys an unsere Anwendung, damit Nutzer sich damit anmelden können. Eine Änderung, die an mehreren Stellen eingreift und bei der ich nicht erst hinterher merken wollte, wie sie gedacht ist.

Die einzelnen Schritte des Plans bekomme ich heute nicht mehr zusammen, was geblieben ist, ist der Ablauf drumherum.

Umdenken musste ich an sich nicht. Der Plan hat mich nicht vor einem Denkfehler gerettet, und ich will das auch nicht größer machen, als es war. Wir haben stattdessen zusammen einen guten Plan erarbeitet, auch darüber, wo die Verknüpfung zu finden sein soll. Es ging vor allem um die Feinheiten.

Was ich daran sehr gut fand: Ich konnte vorab sehen, wie Claude Code es umsetzen will, und hatte dann noch die Chance, Anpassungen vorzunehmen. Ich meine mich zu erinnern, dass ich an einer Stelle eine Rückmeldung gegeben habe, weil ich es dort anders wollte.

Das klingt nach wenig, ist aber der ganze Punkt. Ohne Plan Mode hätte ich dieselbe Korrektur auch angebracht, nur an fertigem Code statt an einem Absatz.

Für diese Planungsphase habe ich mir sicherlich 30 bis 60 Minuten Zeit genommen, bevor eine Zeile Code entstanden ist. Das ist der Preis, und bei einer Änderung dieser Größe war er es wert.

Genau das ist der Wert, den ich beobachte: nicht die Rettung, sondern die gemeinsame Klärung der Details, bevor Code existiert.

Der Grund, warum ich ihn bei größeren Änderungen und neuen Features einschalte, ist Einfluss. Ich muss dann nicht im Nachgang alles korrigieren, sondern kann schon vorher proaktiv in meine Richtung beeinflussen, wie ich es mir vorstelle.

Das passt zu dem, was für mich generell über die Arbeit mit Claude Code gilt: Die Qualität steht und fällt mit dem Briefing. Der Plan Mode ist im Grunde nur die Stelle, an der das Briefing sichtbar wird, bevor es Konsequenzen hat. Wie ich sonst briefe, steht auf der Übersichtsseite.

Bei Kleinigkeiten kostet er schlicht Zeit. Eine überschaubare Änderung durch eine Planungsphase zu schieben, erzeugt einen Schritt, dessen Ergebnis man vorher schon kennt. Das war mein Anfängerfehler.

Der zweite Fall ist unangenehmer, weil er meiner ist: Bei Bugs lasse ich ihn weg, obwohl das nicht immer die richtige Entscheidung sein dürfte. Ich nenne das hier als Neigung, nicht als Empfehlung. Wer aus meiner Erfahrung etwas mitnehmen will, nimmt eher das Gegenteil mit.

Dass mich das Überspringen tatsächlich Zeit kosten kann, habe ich am Anfang gelernt, und zwar bei Features. Ich habe damals Dinge direkt implementieren lassen und musste sie hinterher sehr stark anpassen, weil die Umsetzung nicht optimal war. Welche das konkret waren, weiß ich nicht mehr; geblieben ist die Konsequenz.

Genau deshalb schalte ich den Plan Mode bei Features heute ein. Die Regel, die ich habe, ist also nicht aus der Dokumentation, sondern aus dieser Nacharbeit entstanden. Bei Bugs habe ich sie noch nicht gezogen.

Der Plan Mode ist bei mir kein Standard und wird auch keiner. Er ist das Werkzeug für den Fall, in dem mir die Richtung wichtiger ist als die Geschwindigkeit, und diese Fälle erkenne ich bis heute aus dem Bauch, nicht an einer Regel.

Auffällig finde ich dabei einen Widerspruch in meinem eigenen Vorgehen: Bei n8n gebe ich der KI Schreibzugriff auf die produktive Instanz, ohne programmatische Grenzen, und verlasse mich auf Backups. Im Code will ich den Plan vorher sehen. Der Unterschied ist wohl, dass ein Workflow wiederherstellbar ist und eine gewachsene Codebasis nicht.

Dass ich damit auf der Seite bleibe, die zu wenig plant, ist mir bewusst. Ein Artikel, der behauptet, er hätte das perfekt kalibriert, wäre allerdings gelogen.