Erst denken, dann generieren

Seit ein paar Wochen geistert ein neuer Begriff durch die Tech-Welt: Vibe Coding. Andrej Karpathy hat getweetet, dass er beim Coden mit KI den Code gar nicht mehr liest, Diffs nicht anschaut, Fehlermeldungen einfach in den Chat kopiert und weitermacht. Das hat offensichtlich einen Nerv getroffen.

Ich habe das auch gemacht. “Bau mir eine REST-API für diesen Use Case.” “Schreib mir die Tests dazu.” “Mach das Styling responsive.” Prompt rein, Code raus. Funktioniert erstaunlich gut für kleine Sachen. Und erstaunlich schlecht für alles andere.

Wo es anfängt zu bröckeln

Das Muster ist immer dasselbe. Ich beschreibe grob, was ich will. Das Modell liefert etwas, das auf den ersten Blick passt. Ich korrigiere. Das Modell passt an. Ich ergänze. Das Modell baut um. Prompt für Prompt für Prompt arbeite ich mich dem Ziel entgegen. Und irgendwann, nach dreißig Nachrichten, hat das Modell den Kontext halb vergessen, die Qualität der Antworten sackt ab, und ich stehe vor der Wahl: Weiterwursteln oder von vorne anfangen.

Bei kleinen Prototypen ist das egal. Da ist der Weg das Ziel. Aber bei echten Projekten, in meiner täglichen Arbeit, habe ich Stunden in Chat-Sitzungen versenkt, die am Ende im Nichts gelandet sind. Nicht weil das Modell schlecht war. Sondern weil der Ansatz nicht skaliert: sich über dutzende Prompts iterativ an ein Ergebnis heranzutasten, das ich vorher nicht klar genug definiert hatte.

Der Blogpost, der den Schalter umgelegt hat

Letztens bin ich über einen Blogpost gestolpert, der mein Vorgehen komplett verändert hat. Der Autor beschreibt seinen Workflow für KI-gestützte Codegenerierung, und der hat eine Eigenschaft, die mich sofort angesprochen hat: Er beginnt nicht mit dem Prompt an das Coding-Tool. Er beginnt mit Denken.

Die Grundidee: Bevor eine Zeile Code generiert wird, passieren zwei Dinge. Eine saubere Spezifikation wird erarbeitet. Und daraus wird ein konkreter Plan abgeleitet. Erst dann geht es an die Umsetzung.

Klingt banal? Klingt nach dem, was wir in der Softwareentwicklung immer schon hätten tun sollen? Genau. Und genau das ist der Punkt.

Mein Ansatz in drei Schritten

Ich habe den Ansatz aus dem Blogpost als Ausgangspunkt genommen und für mich angepasst. Was dabei rausgekommen ist, nutze ich seit Wochen täglich. Und es funktioniert besser als alles, was ich vorher gemacht habe.

Schritt 1: Die Spezifikation erarbeiten. Ich gehe nicht mit einer fertigen Anforderung in den Chat. Ich nutze ein Conversational-Modell und sage ihm: “Stell mir Fragen. Eine nach der anderen. So lange, bis wir eine vollständige, entwicklungstaugliche Spezifikation haben.” Das Modell wird zum Interviewer. Es fragt nach Edge Cases, die ich übersehen hätte. Nach Abhängigkeiten, die ich vergessen hätte. Nach Entscheidungen, die ich aufgeschoben hätte.

Wo das am besten funktioniert: auf der Autobahn. Ich fahre regelmäßig zu Kunden, drei Stunden hin, drei zurück. Seit ein paar Wochen nutze ich diese Fahrten mit dem Voice-Modus von ChatGPT. Ich rede über eine Produktidee, das Modell stellt Rückfragen, ich denke laut nach, es hakt nach. Wenn ich ankomme, lasse ich mir das Gespräch zusammenfassen. Und habe eine erste Spezifikation, an der ich weiterarbeiten kann. Kein Bildschirm, kein Editor, nur Nachdenken mit einem Gesprächspartner, der nicht müde wird.

Am Ende steht ein Dokument. Keine Prosa, sondern eine klare Spezifikation mit Anforderungen, Akzeptanzkriterien und technischen Rahmenbedingungen.

Schritt 2: Den Plan ableiten. Die Spezifikation geht an ein Reasoning-Modell, aktuell meistens o3-mini. Nicht an das gleiche Modell, nicht im gleichen Chat. Ein frischer Kontext, ein klarer Auftrag: Nimm diese Spezifikation und erstelle einen Implementierungsplan. Zerlege ihn in kleine, einzeln umsetzbare Schritte. Schreib für jeden Schritt einen konkreten Prompt.

Was zurückkommt: Ein Dokument mit durchnummerierten Aufgaben, jede so formuliert, dass ein Coding-Agent sie ohne Rückfragen umsetzen kann. Plus eine Checkliste, an der ich den Fortschritt abhake.

Zeitaufwand bis hierhin: vielleicht 15 Minuten. Für etwas, das vorher nicht existiert hat.

Schritt 3: Ausführen. Jetzt erst geht es ans Coden. Aber nicht als offenes Gespräch mit dem Modell, sondern als schrittweise Abarbeitung des Plans. Prompt für Prompt. Test für Test. Jeder Schritt überprüfbar gegen die Spezifikation.

Aktuell mache ich das mit Cline, einem VSCode-Plugin, das als Coding-Agent direkt im Editor arbeitet. Aber das Tool ist nicht der Hebel. Der Hebel ist der Plan, der davor entstanden ist.

Was sich verändert hat

Der Unterschied ist so deutlich, dass ich mich frage, warum ich das nicht von Anfang an so gemacht habe.

Der Output ist dramatisch besser. Nicht ein bisschen. Grundlegend anders. Features, die vorher nach drei Iterationen immer noch Lücken hatten, kommen beim ersten Mal richtig raus. Weil die Spezifikation die Lücken vorher geschlossen hat.

Ich verbringe weniger Zeit im Chat. Klingt paradox, weil ich ja einen zusätzlichen Schritt vorgeschaltet habe. Aber die fünfzehn Minuten für Spezifikation und Plan sparen mir Stunden an Hin-und-her mit dem Coding-Agent.

Und ich verstehe meinen eigenen Code besser. Weil ich vor dem Generieren gezwungen bin, zu durchdenken, was ich eigentlich baue. Die Spezifikation ist nicht nur für das Modell. Sie ist für mich.

Die eigentliche Erkenntnis

Was mir dabei klar geworden ist: Die Spezifikation ist der Prompt. Nicht einer von dreißig Prompts in einem langen Chat. Sondern der eine Prompt, der zählt. Alles, was ich vorher in dutzende Nachrichten verteilt habe, die Anforderungen, die Randbedingungen, die Entscheidungen, das steckt jetzt in einem Dokument. Und dieses Dokument ist das, was das Modell bekommt.

Shit in, shit out. So simpel ist das. Ein LLM ist kein Kollege, der nachfragt, den Kontext ergänzt und zwischen den Zeilen liest. Es ist ein System, das exakt das liefert, was die Eingabe hergibt. Und wenn die Eingabe eine vage Beschreibung ist, aus der es raten muss, was ich meine, dann rät es. Mit jedem Prompt ein bisschen mehr. Bis der Kontext zerfällt und ich von vorne anfange.

Vibe Coding funktioniert, wenn mir egal ist, was genau rauskommt. Für Prototypen, für Spielereien, für Sachen die ich morgen wegwerfe. Für alles, was morgen noch stehen soll, brauche ich etwas anderes.

Was das für den Alltag heißt

Ich nutze diesen Workflow nicht nur für neue Projekte. Auch wenn ich in einer bestehenden Codebase ein Feature umsetze, beginne ich mit einer Spezifikation. Manchmal sind das drei Zeilen. Manchmal drei Seiten. Aber der Schritt ist immer da.

Im Hype um immer bessere Modelle und immer smartere Tools vergessen alle, dass der erste Schritt nicht “prompte das richtige Tool” ist. Der erste Schritt ist: Weiß ich eigentlich, was ich will?

Wie es weitergeht

Ich arbeite seit 2023 KI-gestützt, seit Sommer letzten Jahres generiere ich Software konsequent mit LLMs. Was ich hier beschreibe, ist nicht der Anfang. Es ist der nächste Schritt. Und trotzdem ist es eine Baustelle. Ich probiere gerade alles Mögliche aus. Voice-Gespräche auf der Autobahn. Spezifikationen in verschiedenen Formaten. Reasoning-Modelle gegen Conversational-Modelle für die Planung. Manchmal klappt es großartig, manchmal produziere ich eine aufwändige Spezifikation für etwas, das ich in zehn Minuten hätte hacken können.

Jede Woche sieht mein Workflow ein bisschen anders aus. Das ist keine Phase der Optimierung. Das ist eine Phase des Ausprobierens. Ich glaube, so geht es vielen, die ernsthaft mit KI-gestützter Entwicklung arbeiten. Die alten Workflows passen nicht mehr. Aber die neuen sind noch nicht gefunden. Nicht wirklich.

Was ich nach fast zwei Jahren KI-Codegenerierung sagen kann: Die Idee, dass die Qualität der Spezifikation die Qualität des Outputs bestimmt, ist die deutlichste Lektion aus dieser ganzen Zeit. Und sie gilt unabhängig davon, welches Tool oder Modell man benutzt.

Die Modelle werden besser. Jeden Monat. Aber der Unterschied zwischen einem guten und einem schlechten Ergebnis liegt nicht am Modell. Er liegt an dem, was ich ihm gebe.

Erst denken. Dann generieren.