Nach Kapitel 1 und 2 sollten Sie im Griff haben, was Claude Code ist und wie es arbeitet. In diesem Kapitel bauen wir einen Rhythmus, den Sie jeden Tag in derselben Form durchlaufen können – die vier Takte erkunden → planen → umsetzen → committen.
Warum es eine Form braucht, ist klar: Die Ursache an Tagen, an denen es nicht läuft, ist meistens ein übersprungener Takt. Schreiben lassen, ohne lesen zu lassen; delegieren, ohne ein Prüfmittel mitzugeben; laufen lassen, ohne zu zäsurieren – die Symptome unterscheiden sich, der Ort der Rückkehr ist derselbe.
Die Form eines Tages – vier Takte
Die beteiligten Dateien lesen lassen und den Ist-Zustand in Worte fassen lassen. Noch nichts schreiben lassen.
Das Vorgehen vorab ausgeben lassen, und Sie korrigieren es. Der einzige billige Korrekturpunkt.
Schreiben lassen und gleich an Ort und Stelle die Prüfung laufen lassen. Die Schleife aus Kapitel 1 ganz durchdrehen lassen.
Sobald es durchläuft, einen Punkt setzen, zu dem Sie zurückkönnen. Das nächste Erkunden beginnt hier.
Als Maß für eine Runde gilt: Wenn Sie sich an den Zwischenstand nicht mehr erinnern, war sie zu groß. Vier Runden zu einer Stunde sind fast immer stabiler als eine Runde über einen halben Tag.
Das heißt nicht, dass Sie jedes Mal alles tun müssen. Für einen Tippfehler braucht es keinen Plan. Zu entscheiden ist, welchen Takt Sie weglassen können; die Grundeinstellung lautet „alle“.
Bevor Sie anfangen, geben Sie ein Prüfmittel mit
Bevor die vier Takte losgehen, gibt es etwas, das Sie einmalig erledigen: Claude vorab ein Mittel in die Hand geben, mit dem es sich selbst überprüfen kann.
Wie wir in Kapitel 1 gesehen haben, steckt darin eine Schleife aus sammeln → handeln → prüfen. Stark ist sie, weil es STEP 3 gibt: Es kann selbst so lange nachbessern, bis die Tests durchlaufen. Umgekehrt heißt das: Ohne Prüfmittel hält die Schleife nach einer Runde an – geschrieben, wird schon stimmen, Ende. Genau wie ein Chat-Werkzeug.
„Bring die Tests durch“ genügt. Die Ausgabe des Fehlschlags wird zur nächsten Eingabe, und die Schleife dreht sich, auch wenn Sie nicht zusehen.
Sie führen aus, teilen das Ergebnis mit und lassen erneut schreiben. Sie werden zum Engpass. Delegiert haben Sie nur in Ihrer Vorstellung.
Was Sie mitgeben, muss nichts Großes sein. Eine Zeile im Sinne von „mit diesem Befehl sehen Sie, ob es stimmt“ reicht. Und das steht zuverlässiger in einer Datei als in einem Satz – die CLAUDE.md direkt im Projekt wird nämlich auch über eine Verdichtung hinweg erneut von der Festplatte gelesen.
Was in der CLAUDE.md wirkt (Beispiele)
- Befehle nach einer Änderung: Tests / Typprüfung / Linter
- Nicht „fertig“ melden, solange sie noch fehlschlagen
- Orte, die tabu sind: erzeugte Dateien, Produktionskonfiguration und dergleichen
Steht das da, prüft es sich nach jeder Änderung selbst, ohne dass Sie jedes Mal „mach die Tests“ sagen. Es ist nicht so, dass Sie weniger Anweisungen geben – es braucht schlicht an weniger Stellen eine. Genau so zahlt sich eine Form aus (wie man das schreibt, steht in Kapitel 6). Dass die Aufgaben, die Kapitel 1 auf die Seite „passt schlecht“ gestellt hat, hier durchfallen, liegt ebenfalls daran: Es gibt kein Prüfmittel zum Mitgeben.
Erkunden – lesen lassen, bevor geschrieben wird
Erster Takt. Es gibt genau eine Aufgabe: die beteiligten Dateien lesen lassen und erklären lassen, wie die Lage gerade ist. Noch wird nichts geschrieben. Überspringen Sie das, füllt Claude die ungelesenen Teile durch Raten auf. Zurück kommt plausibler Code, der leicht neben dem steht, wie der Rest geschrieben ist, und die Abweichung bemerken Sie erst beim Review oder in der Produktion.
Schlecht erkundet: „Repariere die Authentifizierung“
→ sofort wird editiert. Sie sehen nie, wovon es ausgegangen ist
Gut erkundet: „Finde und lies die Dateien, die zur Authentifizierung gehören.
Erkläre, wie die Anmeldung derzeit abläuft,
zusammen mit einer Liste der beteiligten Dateien.
Ändere noch nichts.“
→ die Annahmen landen auf dem Bildschirm. Stimmen sie nicht, korrigieren Sie hier
Die Erklärung, die zurückkommt, ist zum Lesen da. Das ist die billigste Stelle, um einzugreifen. „Diese Datei wird nicht mehr benutzt“ kostet einen Satz – einen Bruchteil dessen, was es kostet, eine falsche Umsetzung erst im Review zu finden.
Erkunden hat außerdem einen Preis. Jede gelesene Datei landet im Kontext, je weiter Sie also erkunden, desto weniger Luft bleibt später – die Zeile aus Kapitel 1 über Trägheit und das Vergessen des Anfangs nimmt hier ihren Ausgang. Drei Wege, das im Zaum zu halten.
- Den Umfang beschneiden – „erst einmal nur die Authentifizierung“. Ein Gesamtbild braucht es, alle Dateien nicht
- Riesige Dateien in Teilen lesen lassen – am Stück füllen sie den Kontext auf einen Schlag. Ein Zeilenbereich oder eine einzelne Funktion genügt
- Untersuchungen mit viel Ausgabe auslagern – Logauswertungen und Massensuchen an einen Subagenten. Der hat seinen eigenen Kontext, und zurück kommt nur eine Zusammenfassung, der Hauptstrang bläht sich also nicht auf (Kapitel 6)
Planen – wann der Planmodus sich lohnt und wann er bremst
Zweiter Takt. Was in welcher Reihenfolge geändert wird, lassen Sie ausgeben, bevor geschrieben wird. Claude Code hat für genau diesen Takt einen Planmodus: Es hält dort an, wo es untersucht und einen Plan vorlegt, und geht erst zum Schreiben über, wenn Sie zustimmen. Wie umgeschaltet wird, ändert sich von Version zu Version – sehen Sie in der Hilfe Ihrer Version nach.
Im Kern verschiebt das die Rechte-Schranke von „bei jeder Änderung“ an den Eingang der Arbeit. Standardmäßig kommt bei jedem Werkzeugaufruf eine Rückfrage; der Planmodus bündelt sie zu einer und zieht sie nach vorn. Und was Sie bestätigen, ist dann nicht „diese eine Zeile“, sondern „die Marschrichtung dieser Arbeit“.
Es erstreckt sich über mehrere Dateien / es gibt zwei oder mehr Wege / es muss sich in den bestehenden Entwurf einfügen / ein Fehler wäre mühsam zurückzunehmen / Sie selbst haben den besten Zug noch nicht festgelegt
Es gibt nur eine Sache zu tun / das Vorgehen steht bereits fest / ein Fehler ist sofort rückgängig zu machen / den Plan zu lesen dauert länger als die Umsetzung
Die rechte Seite überspringen Sie ruhig. Ein Plan ist nicht kostenlos, er verbraucht Zeit zum Erstellen, Zeit zum Lesen und Kontext. Haben Sie ihn bekommen, schauen Sie nur auf drei Dinge. ① Stimmen die Annahmen? (Ist der erste Takt danebengegangen, geht der ganze Plan daneben.) ② Ist eine Prüfung enthalten? (Fehlt „die Tests durchbringen“, ergänzen Sie es.) ③ Ist es fein genug zerlegt? (Bei einem Plan, der alles in einem Zug erledigt, können Sie im Fehlerfall die Ursache nicht bestimmen.)
Bei langen Arbeiten legen Sie den Plan in einer Datei ab. Ein Plan, der nur im Gespräch existiert, wird zerdrückt, sobald die Sitzung lang wird und eine Zusammenfassung entsteht. Lassen Sie ihn an eine Stelle wie PLAN.md schreiben, dann können Sie ihn auch nach dem Zusammenfalten des Kontexts erneut lesen, und er ist zugleich der Wiedereinstiegspunkt, wenn Sie zwischendurch weg waren.
Umsetzen – in kleinen Schritten, im Laufen korrigiert
Dritter Takt. Hier wird endlich geschrieben. Es gibt zwei Grundsätze.
Erstens: nach jedem Zug die Prüfung laufen lassen. Wer fünf Änderungen sammelt und dann testet, handelt sich Arbeit ein, wenn es rot wird: herausfinden, welche davon die Ursache war. Wer eine schreibt und eine durchbringt, weiß, dass der letzte Zug die Ursache ist. Eine Gepflogenheit weniger für Claude als für Sie.
Zweitens: die Ausgabe des Fehlschlags unverändert weiterreichen. Sie müssen sie nicht zusammenfassen und in eigenen Worten wiedergeben. STEP 3 heißt „die Ausgabe lesen und zu STEP 1 zurückkehren“, also ist die rohe Ausgabe die informationsreichste Eingabe. Vorverdautes lässt eher Anhaltspunkte verschwinden.
Eine Runde beim Umsetzen (in kleinen Schritten wiederholen)
[ÄNDERN] genau einen Punkt des Plans umschreiben
↓
[AUSFÜHREN] Tests / Typprüfung laufen lassen
↓
grün → weiter zum nächsten Punkt (oder committen)
rot → die Ausgabe lesen, zurück zu [ÄNDERN]
Dreimal hintereinander rot an derselben Stelle: nicht weiter nachbessern lassen
→ die Hände weglegen und zur Eingrenzung übergehen (Kapitel 4)
Die letzte Zeile ist eine Faustregel. Wenn sich derselbe Fehlschlag zu wiederholen beginnt, ist das meist nicht das Zeichen „gleich haben wir es“, sondern „die Annahme ist falsch“.
Wenn die Prüfung lange dauert – lange Builds oder das Warten auf einen CI-Durchlauf –, können Sie auch delegieren, statt davorzukleben. Claude Code hat einen Mechanismus, eine Anweisung in festen Abständen zu wiederholen; lassen Sie den Abstand weg, bestimmt Claude selbst, wann es das nächste Mal nachsieht, und hält die Schleife an, sobald es die Arbeit für erledigt hält. Mechanismus und Einschränkungen stehen unter Was der Befehl /loop ist. Achtung: Schließen Sie die Sitzung, hört es auf.
Committen – die Zäsuren setzen Sie selbst
Vierter Takt. Laufen die Tests durch, committen Sie genau dann. Nicht „wenn ich an einem guten Punkt angekommen bin“ – der Moment, in dem es durchläuft, ist der gute Punkt.
- Es entsteht ein Rückkehrpunkt – geht der nächste Zug schief, kommen Sie verlässlich an eine Stelle zurück, die grün war
- Der Diff bleibt in lesbarer Größe – die Änderungen eines halben Tages liest niemand. Ein unlesbarer Diff wird faktisch nicht geprüft
- Sie dürfen das Gespräch abschneiden – ist das Ergebnis gesichert, verliert das Wegwerfen einer Sitzung seinen Schrecken
Die Commit-Nachricht dürfen Sie ebenfalls schreiben lassen, aber stimmen Sie ihr nicht zu, ohne den Diff gesehen zu haben. Wenn Sie sich vornehmen, nicht auf „was wurde geändert“ zu achten, sondern auf „hat sich etwas eingeschlichen, das gar nicht geändert werden sollte“, rutscht der Blick nicht so leicht ab.
Und Committen und Pushen sind zwei verschiedene Entscheidungen. Wie weit Sie schwer rückgängig zu machende Operationen wie ein Deployment abgeben, behandelt Kapitel 5.
Eine Sitzung zusammenfalten und zurückspulen
Nach ein paar Runden der vier Takte stoßen Sie unweigerlich darauf, dass sich der Kontext füllt. Zeigen sich die beiden Symptome aus Kapitel 1 – träge Antworten, der Anfang wird vergessen –, ist Faltzeit. Es gibt zwei Mittel, verdichten oder neu beginnen, und die Scheidelinie ist eine einzige.
Ist das Nächste eine Fortsetzung, dann verdichten – der Verlauf lässt sich als Zusammenfassung mitnehmen, und der Unterschied zum automatischen Ablauf ist, dass Sie vorgeben können, was erhalten bleibt. Ist das Nächste eine andere Sache, dann neu beginnen – wer nicht einmal die Zusammenfassung braucht, muss auch nicht dafür bezahlen, sie zu erstellen. Und weil nichts Fremdes mitgeschleppt wird, wird es zugleich genauer.
Auch für den Zeitpunkt gibt es eine Form. Nicht nach Uhr oder Prozentzahl, sondern an der Zäsur der Arbeit drücken – wenn eine Runde zu Ende ist, direkt bevor die nächste lange Arbeit beginnt. Drücken Sie mittendrin, werden auch die Details zerdrückt, die Sie später noch brauchen. Die Begründung behandelt Sollte man /compact regelmäßig drücken?.
Bevor Sie falten, schreiben Sie das, was nicht verschwinden darf, in eine Datei. Die CLAUDE.md direkt im Projekt und der automatische Speicher werden erneut von der Festplatte gelesen und überleben deshalb beliebig viele Faltungen; Entscheidungen, die nur im Gespräch existieren, verdünnen sich dagegen in der Zusammenfassung.
Es gibt noch einen Mechanismus, der die Art des Delegierens selbst verändert. Claude Code legt zu jedem Prompt automatisch einen Rückkehrpunkt an, und wenn etwas aus dem Ruder läuft, spulen Sie bis dorthin zurück. Sie wählen dabei zwischen nur Code, nur Gespräch oder beidem, und am häufigsten braucht man „den Code zurücksetzen, das Gespräch behalten“ – die Änderungen gelten als nicht geschehen, und Sie können es neu formulieren, während noch bekannt ist, was daran nicht taugte.
Was hier wirkt, ist weniger die Bequemlichkeit der Bedienung als die Art, Risiko einzugehen. Wer davon ausgeht, nicht zurückzukönnen, bestätigt Zug um Zug und entwertet damit den Sinn eines Agenten. Wer weiß, dass er zurückkann, kann größere Pakete abgeben, und ausprobieren und im Zweifel wegwerfen wird zu einer echten Option.
Zurück geht allerdings nur, was „Claude über sein Bearbeitungswerkzeug umgeschrieben hat“. Dateien, die über Shell-Befehle angelegt oder gelöscht wurden, Ihre eigenen Änderungen und der Zustand der Datenbank kommen nicht zurück. Es ist kein Ersatz für Git und setzt voraus, dass Sie an den Zäsuren zusätzlich committen. Die Linie lässt sich so ziehen: Arbeiten, die mit Dateiänderungen auskommen, in großen Paketen abgeben. Arbeiten, die über die Shell den Zustand verändern, vor dem Abgeben committen. Einzelheiten unter Prüfpunkte und Zurückspulen.
Prüfen lassen – wer schreibt und wer liest, sollte getrennt sein
Code, dessen Tests durchlaufen, ist nicht zwangsläufig guter Code. Tests garantieren „es ist nicht kaputt“, sie beantworten aber nicht „war diese Schreibweise die richtige“.
Es gibt einen Grundsatz: Trennen Sie den Kontext des Schreibens vom Kontext des Lesens. Wenn Sie in demselben Gespräch, in dem die Umsetzung gerade fertig geworden ist, „prüfe das“ sagen, wird eher die eigene Entscheidung bestätigt. Ein Zustand, in dem alle Gründe für die getroffene Wahl sichtbar sind, taugt schlecht zum Suchen von Schwachstellen. Konkret sind es drei Dinge.
- In einer anderen Sitzung lesen lassen – committen, damit ein Diff entsteht, und einem frischen Gespräch nur den Diff geben. Mit einem Blick lesen lassen, der den Hergang nicht kennt
- Den Blickwinkel vorgeben – nicht „mach es besser“, sondern eine Achse mitgeben: „Randbedingungen“, „Stimmigkeit mit der bestehenden Schreibweise“. Vage Aufträge erzeugen vage Hinweise
- Hinweise nicht ungeprüft übernehmen – ob sie stimmen, prüfen Sie am Original nach. Erst lesen, dann korrigieren lassen
Der dritte Punkt hängt mit anderen Stellen dieses Kapitels zusammen. Ein Review ist der Musterfall einer Aufgabe ohne Prüfmittel, und weil sich richtig und falsch nicht automatisch entscheiden, sagt Claude auch Danebenliegendes in selbstsicherem Ton. Wer das ungefiltert in eine Korrekturanweisung übergehen lässt, zerstört Code, der richtig war – behandeln Sie Hinweise als Kandidaten und entscheiden Sie einen nach dem anderen. Wenn Sie Lust bekommen, dieselben Blickwinkel jedes Mal durchzugehen, ist das das Signal, daraus einen Mechanismus zu machen (Kapitel 6).
Mehrere Sitzungen – wie weit sich das lohnt
Während die eine Seite einen langen Test dreht, an etwas anderem weiterarbeiten – ein naheliegender Gedanke. Claude Code kann mehrere unabhängige Sitzungen im Hintergrund starten und auf einem Bildschirm verwalten. Der Kern ist Isolierung: Eine Sitzung im Hintergrund wechselt in ein eigenes Arbeitsverzeichnis, bevor sie Dateien bearbeitet. Gelesen wird gemeinsam, geschrieben getrennt, damit ist es baulich ausgeschlossen, dass sich zwei beim Überschreiben derselben Datei ins Gehege kommen. Einzelheiten unter Agent View und Dispatch.
Die Aufgaben sind voneinander unabhängig / Sie müssen den Zwischenstand nicht sehen / es genügt, nach Erhalt des Ergebnisses zu entscheiden / eine Seite ist eine Arbeit mit langer Wartezeit
Sie hängen an derselben Entwurfsentscheidung / die Richtung muss unterwegs neu festgelegt werden / es sind nicht rücknehmbare Operationen dabei / es sind ohnehin mehr, als Sie an Ergebnissen prüfen können
Der letzte Punkt rechts ist die wirksamste Beschränkung. Parallelisieren erhöht die Gesamtmenge an Review. Wer drei Aufträge losschickt, bekommt drei Portionen „stimmt das wirklich“ zurück, und der Prüfaufwand parallelisiert sich nicht mit. Die Obergrenze dessen, was Sie losschicken dürfen, ist die Zahl, deren Ergebnisse Sie prüfen können. Auch die Kosten steigen – im Hintergrund heißt nicht billiger (Kapitel 7).
Bevor Sie mit dem Parallelisieren anfangen, sehen Sie Ihre Rechteeinstellungen durch. Eine im Hintergrund laufende Sitzung übernimmt ihre Rechte aus der Konfiguration, statt sie an Ort und Stelle zu wählen. Gerade wer es sonst locker hält, erzeugt so „Sitzungen mit lockeren Rechten, denen niemand zusieht“ – in genau der Anzahl. Kapitel 5 kommt zuerst.
Unscheinbar, aber häufig Quelle von Unfällen ist das Aufräumen. Der Arbeitsplatz, den eine Hintergrundsitzung angelegt hat, verschwindet mit ihr, wenn Sie die Sitzung löschen. „Fertig“ und „übernommen“ sind zweierlei – committen Sie, bevor Sie löschen.
Zusammenfassung
- Der Tagesrhythmus sind die vier Takte erkunden → planen → umsetzen → committen. Läuft es nicht, liegt es meist an einem übersprungenen Takt
- Vor dem Start ein Prüfmittel mitgeben. Ohne eines hält die Schleife sammeln → handeln → prüfen nach einer Runde an
- Beim Erkunden erst lesen lassen, dann schreiben lassen. Aber jede gelesene Zeile kostet Luft, also den Umfang beschneiden
- Der Plan bündelt die Rechte-Schranke am Eingang der Arbeit. Für Arbeiten mit einem einzigen Zug ist er zu schwer
- Beim Umsetzen nach jedem Zug prüfen und nach dem dritten Fehlschlag zur Eingrenzung übergehen. Committen Sie in dem Moment, in dem es durchläuft
- Ob verdichten oder neu beginnen, entscheidet „ist das Nächste eine Fortsetzung oder eine andere Sache“. Direkt vor dem Falten in eine Datei schreiben
- Zurückspulen setzt nur Dateiänderungen zurück. Über die Shell bewirkte Änderungen kommen nicht zurück, also zusätzlich committen
- Das Review vom Kontext des Schreibens trennen und Hinweise als Kandidaten behandeln. Die Obergrenze für Parallelität ist die Zahl, die Sie prüfen können
Auch mit einer Form bleibt man manchmal stecken. Legen wir uns im nächsten Kapitel eine Reihenfolge für die Eingrenzung zurecht. Weiter zu Kapitel 4 „Aus der Sackgasse heraus“.