Warum ich eine Stunde plane, bevor die KI eine Zeile Code schreibt

Der Moment, in dem du zum Korrektor deiner eigenen Idee wirst

Du beschreibst der KI, was du bauen willst. Sie stellt zwei, drei Fragen. Dann liefert sie einen Plan. Sieht sauber aus. Du liest die Hälfte, überfliegst den Rest, sagst "passt". Code entsteht.

Und dann geht es los.

"Nein, so meinte ich das nicht." "Warum hast du das mit rein?" "Das braucht doch gar keinen Login." Du sitzt da und korrigierst. Runde für Runde. Aus deinem Feature ist ein Review-Job geworden, den du dir selbst eingebrockt hast.

Das kostet drei Dinge gleichzeitig: Zeit, Nerven und Tokens. Und das Bitterste daran ist: der Plan war von Anfang an falsch. Nicht weil die KI dumm war. Sondern weil sie nach zwei Fragen glaubte, sie hätte genug verstanden.

Bei größeren Projekten investiere ich mittlerweile bis zu eine Stunde in reine Planung, bevor eine einzige Zeile Code entsteht. Klingt nach Verschwendung. Ist das Gegenteil.

Warum der eingebaute Planmodus dich im Stich lässt

Die naheliegende Lösung heißt: nutz doch den Planmodus. Der ist eingebaut, der ist gedacht genau dafür. Nur macht er einen Fehler, der ihm einprogrammiert ist.

Er will schnell fertig werden.

Zwei bis drei oberflächliche Rückfragen, dann ein zweiseitiges Plandokument. Zwei Seiten, die kaum jemand ganz liest. Und das Entscheidende: dieser Plan besteht zum größten Teil aus Annahmen der KI, nicht aus Entscheidungen von dir.

Das ist der Bruch. Ein Plan ist nur so gut wie die Entscheidungen, die drinstecken. Wenn die KI rät, wie dein Login funktionieren soll, statt dich zu fragen, dann baut sie sauber und schnell das Falsche.

Die Modelle sind längst nicht mehr das Problem. Die aktuellen Top-Modelle arbeiten stundenlang sauber durch, wenn der Plan stimmt. Der Engpass hat sich verschoben. Er liegt nicht mehr in der Umsetzung. Er liegt davor: versteht das Modell wirklich, was du willst? Oder tut es nur so, weil es nach zwei Fragen aufgehört hat zu fragen?

Die Mechanik: der Entscheidungsbaum, den keiner ausspricht

Der Ansatz, der das repariert, ist unspektakulär und genau deshalb stark. Statt dass die KI schnell einen Plan schreibt, löchert sie dich mit Fragen, bis ein echtes gemeinsames Verständnis entsteht.

Der Trick sitzt im Wort Entscheidungsbaum.

Nimm den Login als Beispiel. Erste Entscheidung: E-Mail und Passwort oder Social Login? Klingt harmlos. Aber sobald du dich für E-Mail und Passwort entscheidest, öffnet sich ein ganzer Zweig darunter. Brauchst du einen Passwort-Reset? Muss die E-Mail bestätigt werden? Wie lange bleibt der Nutzer eingeloggt? Jede Entscheidung gebiert die nächste.

Der native Planmodus fragt: "E-Mail oder Social?" und geht weiter. Der bessere Ansatz arbeitet den Baum Zweig für Zweig ab, bis unten kein offener Ast mehr hängt.

Dazu kommt eine zweite Regel, die genauso wichtig ist: die Trennung von Fakten und Entscheidungen. Was sich aus deiner Umgebung ableiten lässt, also aus vorhandenen Dateien, aus dem Kontext, aus dem, was schon da ist, das recherchiert die KI selbst. Nur echte Entscheidungen landen bei dir. Deshalb wirst du nicht mit Fragen zugeschüttet, deren Antwort ohnehin im Projekt steht. Du bekommst nur die Fragen, bei denen es wirklich eine Wahl gibt.

So baust du dir das nach

Der Skill, um den es geht, ist weniger als 10 Zeilen lang. Das ist keine Untertreibung, das ist der Punkt. Er setzt an der einen Stelle an, die die meisten Feedbackschleifen produziert, und tut sonst nichts.

Du kannst dir das Prinzip in vier Sätzen bauen. Leg es als Textdatei an und binde sie global in dein agentisches Coding-System ein, damit sie projektübergreifend verfügbar ist. Hier ist das Gerüst zum direkten Übernehmen:

Stelle mir so lange Fragen, bis ein echtes gemeinsames Verständnis
zwischen uns besteht. Gib dich nicht mit oberflächlichen Antworten
zufrieden.

Arbeite den Entscheidungsbaum Zweig für Zweig ab. Jede Entscheidung
öffnet Unterentscheidungen. Frage diese ab, bevor du zum nächsten
Zweig gehst.

Recherchiere selbst alles, was du aus dem vorhandenen Kontext
ableiten kannst. Frage mich nur nach echten Entscheidungen, nicht
nach Fakten, die schon im Projekt stehen.

Beginne erst mit der Umsetzung, wenn ich das Verständnis bestätigt
habe.

Und der Ablauf drumherum, damit es greift:

1. Leg deine Kontext-Dateien vorab bereit. Projektinfos, vorhandene Struktur, alles, woraus die KI Fakten ableiten soll. Je mehr sie selbst weiß, desto weniger unnötige Fragen.
2. Ruf bewusst diesen Skill auf, statt in den Standard-Planmodus zu rutschen. Das ist eine aktive Entscheidung, kein Automatismus.
3. Beantworte die Fragen ehrlich. Wenn du eine Antwort nicht weißt, sag das, statt zu raten. Ein geratenes "Ja" ist schlimmer als ein "keine Ahnung".
4. Bestätige erst dann, wenn du das Gefühl hast, ihr redet über dasselbe. Nicht vorher.
5. Nach dem Durchlauf: prüf, ob sich daraus ein wiederverwendbarer Skill machen lässt für Aufgaben, die du öfter hast.

Ein durchgerechnetes Beispiel dazu. Ich habe ein kleines Tool gebaut, das Kommentare einsammelt und daraus Ideen ableitet. Kein Riesenprojekt, ein überschaubares Werkzeug. Der Durchlauf mit diesem Ansatz hat mir 12 Fragen gestellt. Kein Fragebogen aus dem Nichts, sondern gezielte Entscheidungsfragen, weil der Kontext vorher bereitlag. Gesamtdauer für Planung und fertiges, funktionierendes Tool: eine halbe Stunde. Und das Entscheidende: es lief beim ersten Versuch. Keine Feedbackschleife. Kein "so meinte ich das nicht".

Rechne das gegen den anderen Weg: zwei Fragen, zweiseitiger Plan, "passt", und dann fünf Korrekturrunden über zwei Stunden verteilt. Die Stunde vorne ist die günstigere Rechnung.

Wo der Ansatz kippt

Jetzt die ehrliche Kante, denn ohne die ist der Rest Verkaufe.

Die Zahlen oben sind meine Erfahrung, kein Benchmark. Es gibt keine saubere Messung, die die Token- und Zeitersparnis beweist. Die halbe Stunde und die 12 Fragen sind ein Einzelfall bei einer überschaubaren Aufgabe. Ob das bei einem großen, mehrdeutigen Projekt mit dutzenden parallelen Entscheidungssträngen genauso glatt läuft, ist offen. Ein tiefer, breit verzweigter Entscheidungsbaum kann dich auch erschlagen, statt dich zu führen.

Zweiter Punkt: der Skill ist für Leute gebaut, die programmieren oder zumindest wissen, was sie technisch entscheiden. Wenn du auf die Frage "Passwort-Reset per E-Mail oder Security-Frage?" nur ein ratloses "was ist besser?" hast, dann verschiebt sich das Problem nur. Der Skill zwingt dich zu Entscheidungen, die du treffen können musst.

Und der reibungslose Idealfall, den ich beschrieben habe, setzt voraus, dass deine Antworten klar und widerspruchsfrei sind. Gibst du unsichere oder gegensätzliche Antworten, ist unklar, wie gut der Ansatz das abfängt. Er kann nur so gut planen, wie du entscheiden kannst.

Meine Einordnung

Ich sehe die Länge des Skills nicht als Nachteil, sondern als das eigentliche Argument. Es gibt umfangreichere Frameworks für dieselbe Planungsphase, mit eigener Brainstorming-Logik und mehr Einarbeitung. Für die meisten ist das Overkill. Die Wirkung kommt nicht aus dem Umfang, sie kommt aus der einen Regel: erst Verständnis, dann Code.

In meinem eigenen Setup hat sich vor allem der vorbereitete Kontext bewährt. Ich merke den Unterschied direkt: mit gut gepflegten Kontext-Dateien stellt die KI die richtigen 12 Fragen statt 40 falscher. Ohne diesen Unterbau fällt ein Teil der Qualität weg. Das ist die stille Bedingung, die in der Begeisterung gern untergeht. Der Skill ist der Zünder, dein Kontext ist der Brennstoff.

Der eine Satz, den du mitnimmst: Ein Plan aus zwei Fragen ist kein Plan, sondern eine Vermutung mit Formatierung.

FAQ

Was ist der Unterschied zwischen dem nativen Planmodus und diesem Skill?

Der native Planmodus stellt zwei bis drei oberflächliche Fragen und schreibt dann selbst einen Plan, der größtenteils aus Annahmen besteht. Der Skill dagegen arbeitet einen Entscheidungsbaum Zweig für Zweig ab und fragt so lange nach, bis ein echtes gemeinsames Verständnis besteht. Der Plan entsteht dadurch aus deinen Entscheidungen, nicht aus Vermutungen der KI.

Wie lang ist der Skill und wo trage ich ihn ein?

Der Skill besteht aus weniger als 10 Zeilen Text, im Artikel als vierteiliges Gerüst aufgeführt. Du legst ihn als Textdatei an und bindest sie global in dein agentisches Coding-System ein, damit sie projektübergreifend verfügbar ist. Eine spezielle Software brauchst du dafür nicht.

Was ist ein Entscheidungsbaum in diesem Zusammenhang?

Ein Entscheidungsbaum ist hier die Reihenfolge an Fragen, bei der jede Antwort weitere Unterfragen öffnet. Entscheidest du dich zum Beispiel beim Login für E-Mail und Passwort statt Social Login, folgen automatisch Fragen zu Passwort-Reset, E-Mail-Bestätigung und Login-Dauer. Der Skill arbeitet diesen Baum bis zum letzten offenen Ast ab, bevor Code entsteht.

Lohnt sich eine Stunde Planung wirklich, bevor Code geschrieben wird?

Das lässt sich nicht pauschal beweisen, es gibt dazu keine saubere Messung, nur Erfahrungswerte aus der Praxis. In einem Beispiel im Artikel hat eine halbe Stunde Planung mit 12 gezielten Fragen zu einem funktionierenden Tool ohne Korrekturrunde geführt. Der Vergleichswert dazu wäre ein kurzer Plan mit anschließend mehreren Korrekturrunden über zwei Stunden, was in Summe teurer war.

Für wen eignet sich dieser Planungs-Skill nicht?

Der Skill setzt voraus, dass du technische Entscheidungen selbst treffen kannst, etwa ob ein Passwort-Reset per E-Mail oder per Security-Frage laufen soll. Wenn du auf solche Fragen keine Antwort hast, verschiebt sich das Problem nur, statt gelöst zu werden. Auch bei sehr großen, mehrdeutigen Projekten mit vielen parallelen Entscheidungssträngen ist unklar, ob der Ansatz genauso gut funktioniert.

Zum Nachbauen

• mattpocock/skills (GitHub-Repo), Matt Pococks öffentliches Skill-Verzeichnis unter MIT-Lizenz, enthält den grill-me Skill und weitere Engineering-Skills, auch als natives Plugin installierbar.
• grill-me Skill, Der Planungs-Skill selbst: die KI interviewt dich entlang des Entscheidungsbaums, bis gemeinsames Verständnis besteht, statt sofort einen Plan zu schreiben.
• Superpowers Plugin, Umfangreicheres Skill-Framework mit eigener Brainstorming- und Planungsphase, wenn dir der schlanke Ansatz zu wenig ist.