ChatGPT · Codex Schritt für Schritt · Kapitel 11 · 4 Min.

Plan-Modus: erst denken, dann bauen

Erst den Plan zeigen lassen, dann laufen lassen. Je größer die Aufgabe, desto mehr spart dieser Umweg.

Auf dem Bau würde niemand auf die Idee kommen, ohne Plan anzufangen. Man schaut sich an, was da ist, überlegt sich die Reihenfolge, klärt die Schnittstellen — und erst dann kommt der Bagger.

Beim Arbeiten mit KI machen fast alle das Gegenteil. Auftrag rein, los geht's, und zwanzig Minuten später steht etwas, das man so nicht wollte.

Was der Plan-Modus ist

Wie du ihn einschaltest

Mit einem Befehl mitten im Gespräch:

/plan

Du kannst den Auftrag auch gleich anhängen, statt ihn danach zu tippen:

/plan Bau die Kontaktseite um, ohne die Formularlogik anzufassen

Bilder und eingefügte Inhalte funktionieren dabei genauso wie sonst.

Warum das so viel bringt

1. Du siehst den Irrtum, bevor er teuer wird

Der häufigste Fall ist nicht, dass Codex etwas falsch macht. Es ist, dass es etwas anderes richtig macht, als du gemeint hast. Im Plan steht das in drei Zeilen, und du siehst es sofort. Im fertigen Ergebnis siehst du es nach einer halben Stunde.

2. Der Plan zwingt zur Erkundung

Wer einen Plan schreiben soll, muss erst nachsehen, was überhaupt da ist. Genau das führt dazu, dass Vorhandenes wiederverwendet wird, statt daneben etwas Zweites aufzubauen.

3. Es fragt nach, solange Fragen noch etwas ändern

Das ist der Punkt, an dem Codex sich am deutlichsten von anderen Werkzeugen unterscheidet. Im Plan-Modus stellt es Rückfragen — welche Zielgruppe, welche Technik, wie weit soll das gehen. Es entscheidet noch nichts, also darf es noch fragen. Nutz das und antworte ordentlich.

Wie ein guter Plan aussieht

Ein brauchbarer Plan beantwortet vier Fragen:

• Was genau wird geändert — welche Dateien, welche Stellen?
• In welcher Reihenfolge?
• Was wird wiederverwendet von dem, was schon da ist?
• Wie prüfen wir am Ende, ob es funktioniert hat?

Fehlt der letzte Punkt, frag danach. „Woran erkennen wir, dass es geklappt hat?“ ist eine Frage, die auf jeder Baustelle selbstverständlich ist und beim Programmieren gern vergessen wird.

Den Plan korrigieren

Der Plan ist ein Entwurf, kein Vertrag. Sag, was daran nicht stimmt:

Schritt 3 fällt weg, das machen wir später. Bei Schritt 2 nimm die Funktion, die schon in der anderen Datei steht, statt eine neue zu schreiben. Und schreib dazu, wie wir am Ende prüfen, ob es läuft.

Er wird neu geschrieben. So oft, bis er passt. Das kostet fast nichts, weil noch nichts gebaut wurde.

Ein Ziel, das den Plan überlebt

Bei allem, was über eine Sitzung hinausgeht, lohnt sich der zweite Befehl aus Kapitel 5:

/goal Kontaktseite umbauen, Formularlogik bleibt unberührt

Das Ziel hängt am Gespräch, während gearbeitet wird. Der Plan sagt, wie — das Ziel erinnert daran, wozu. Bei langen Läufen ist das der Unterschied zwischen „es macht noch, was ich wollte“ und „es ist unterwegs abgebogen“.

Die Gewohnheit

Es gibt eine einfache Faustregel, an der ich mich festhalte:

Wenn ich nicht in einem Satz sagen kann, welche Datei sich wie ändern soll, gehe ich in den Plan-Modus.

Das ist erstaunlich oft der Fall. Und es hat mir mehr Ärger erspart als jede andere Angewohnheit in diesem ganzen Kurs.

Merke

Bei allem, was länger als eine halbe Stunde dauert: Plan in eine Datei speichern lassen. Das ist das Bautagebuch. Ohne läuft man dieselbe Erkundung beim nächsten Mal wieder von vorn.

In einem Satz

Je größer die Aufgabe, desto lohnender der Plan. Bei einer Überschrift ist er Zeitverschwendung, bei einem Umbau der Unterschied zwischen zehn Minuten und einem Nachmittag.