Planen ist das neue Coden

Ich habe dieselbe App zweimal gebaut.

Beim ersten Mal war es ein Tag Coden und mehrere Tage Debugging. Am Ende habe ich den Code wieder gelöscht.

Beim zweiten Mal habe ich mehrere Tage in die Planung und Research gesteckt. Einen Tag gecoded und eine fertige App gehabt, so wie ich sie wollte.

Der Unterschied war nicht der Code selbst, sondern der Plan, mit dem ich gestartet habe.

Der erste Versuch

Ende letzten Jahres, in der Weihnachtszeit, wollte ich eine lokale Meeting-Transkriptions-App für den Mac bauen. Mit Sprechererkennung und der Möglichkeit, aus dem Transkript Dokumente zu erstellen und zu chatten. Alles lokal.

Whisper kannte ich schon. Ich hatte es bereits einige Male in Python-Apps und Skripten verwendet. Deshalb fiel meine erste Wahl auch auf Whisper.

Mit einer einfachen Prompt wie “Ich möchte eine lokale Meeting-Transkript-App bauen mit Whisper” habe ich gestartet.

Innerhalb eines Tages hatte ich eine funktionierende App. Dachte ich zumindest. Aber nach einigen Tests fiel mir auf, dass die Sprechererkennung nicht optimal war. Sie war richtig schlecht.

Das hat mich gewundert. Ich hatte andere Apps mit dem gleichen Funktionsumfang bereits getestet. Diese konnten das. Was machten die anders als ich?

Ich habe Stunden damit zugebracht, die Parameter zu optimieren. Nichts half. Dann, während eines Research, habe ich herausgefunden, dass die meisten eine Paid-Variante davon verwenden und es deshalb so gut ist.

Das hat mein Projekt über den Haufen geworfen. Ich musste eine andere Lösung finden.

Zuallererst habe ich das Projekt gelöscht. Ich wusste, dass ich von einem weißen Blatt Papier starten muss.

Der zweite Versuch

Im zweiten Versuch habe ich es grundlegend anders gemacht. Obwohl ich schon wusste, dass Planung in der Entwicklung mit Sprachmodellen (LLMs) extrem wichtig ist, hatte ich es beim ersten Versuch ignoriert und Stunden meiner Zeit geopfert.

Zuerst habe ich mit einem intensiven Research begonnen, um herauszufinden welche Möglichkeiten es noch gibt. Dabei bin ich auf FluidAudio gestoßen, das für Apple Silicon optimiert ist. Das war der Schlüssel, um die App so umzusetzen, wie ich sie mir vorstelle.

Dann bin ich in eine tiefe Planungsphase mit Claude Code gegangen. Ich habe mit dem DeepWiki-MCP, Claude Code die Möglichkeit gegeben auf die Dokumentation von FluidAudio zuzugreifen.

Dann habe ich gemeinsam mit Claude einen detaillierten Plan geschrieben. Was soll die App können? Aufnahmefähigkeit, Upload von bestehenden Meeting-Audio- oder Video-Files, dann die Transkription inklusive Sprachererkennung. Das war die MVP-Version.

Während der Planungsphase habe ich entschieden, dass ich die Möglichkeit brauche, aus dem Transkript direkt ein Dokument erstellen zu lassen und mit dem Transkript zu chatten.

Ich habe mich entschieden, das simpel zu lösen. Es gibt Ollama. Der User kann Modelle installieren, die für ihn interessant sind. In meinem Fall habe ich Qwen3 genommen, aber gpt-oss funktioniert auch wunderbar.

Ich habe alles in den Plan geschrieben, was ich haben möchte. Dann habe ich das Ganze in Phasen aufgeteilt, um nach der ersten Phase zu sehen, ob das Ergebnis brauchbar ist oder nicht.

Nachdem ich die erste Phase umgesetzt habe, war sofort klar, dass es sich ausgezahlt hat, die Zeit in das Planen zu investieren.

Die App sah genauso aus, wie ich es wollte. Sie hatte genau die Funktionen, die ich brauchte. Das hat mir extrem viel Zeit gespart.

Ich habe ein, zwei Tage für das Planen investiert. One-Shot war es nicht. Man braucht immer wieder Interaktionen, um das hinzubekommen. Aber ich habe die App sehr schnell so hinbekommen, wie ich sie mir vorgestellt habe.

Vibe Coding

Die Erkenntnis daraus führt zu dem Begriff, den Andrej Karpathy geprägt hat. Vibe Coding. Du gibst dich dem Vibe hin und akzeptierst, was die AI ausspuckt.

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” — Andrej Karpathy, Februar 2025

Es funktioniert. Aber noch besser funktioniert es, wenn man einen konkreten Plan schreibt.

Im ersten Versuch habe ich nur Vibe Coding gemacht, mit wenig Information, weil ich dachte: “Ich habe Whisper schon verwendet, ich weiß, wie das funktioniert.” Das hat nicht funktioniert.

Mit einem konkreten Plan funktioniert Vibe Coding um einiges besser. So bekommst du die Ergebnisse, die du haben willst.

Die Zahlen

Das hat auch die Studie von Engprax/J.L. Partners (Mai 2024) mit 600 Software Engineers gezeigt:

• 97% höhere Erfolgschance bei Projekten mit klaren Requirements vor Entwicklungsbeginn
• 50% mehr Erfolg durch Spezifikation vor dem Coden
• 57% mehr Erfolg durch akkurate Requirements
• 39% aller Fehlschläge gehen auf schlechte Requirements zurück

Das war vor AI schon so. Mit AI wird es zum Multiplikator.

Der Job hat sich verändert

Früher mussten die Leute viele Jahre investieren, um gut entwickeln zu können. Um zu wissen, wie Dinge funktionieren.

Jetzt, durch das Aufkommen von Sprachmodellen und agentischem Coding, verändert sich das. Entwickler werden zu Produktmanagern, Requirements Engineers und Business Analysten. Aber nicht nur Entwickler. Jeder, der weiß, was er bauen will, kann jetzt Produkte mit AI bauen.

Man beschreibt, was man haben will, und die AI baut es.

Je präziser deine Beschreibung, desto besser das Ergebnis.

Planen ist das neue Coden.