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.
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.