Wie vibe-code ich?

Was Vibe Coding wirklich von Ihnen verlangt

Vibe Coding klingt nach der Abwesenheit von Methode, und genau deshalb geht es für so viele Menschen schief. Ein Modell den Code schreiben zu lassen, beseitigt das Syntax-Problem, aber nicht die zwei Aufgaben, die schon immer der schwierige Teil waren: präzise zu sagen, was passieren soll, und zu prüfen, ob es passiert ist. Ihr Aufwand verschwindet nicht, er verschiebt sich — vom Code-Tippen zum Spezifizieren und Prüfen. Woher der Begriff stammt, sehen Sie unter Vibe Coding.

Deshalb erzielen zwei Gründer mit demselben Tool völlig unterschiedliche Ergebnisse. Wer mit "bau mir einen Marktplatz" beginnt, bekommt eine Demo, die bei der zweiten Funktion zusammenbricht. Wer mit einem Absatz beginnt, der den Nutzer, die Daten und die eine Sache benennt, die Version eins leisten muss, bekommt etwas, auf dem sich aufbauen lässt. Die Wahl des Tools zählt weniger, als die meisten Vergleiche nahelegen — die besten Vibe-Coding-Tools erklärt, wie sich die Familien unterscheiden —, denn die folgende Schleife bleibt gleich, egal welches Sie wählen.

Die Schleife, Schritt für Schritt

1. Schreiben Sie die Spezifikation vor dem Prompt — ein Absatz: wer das nutzt, was es tun muss, welche Daten es speichert, und was es in Version eins ausdrücklich nicht tun soll. Zehn Minuten hier verhindern den Neubau, der entsteht, wenn das Modell bei allem raten muss, was Sie unausgesprochen gelassen haben.
2. Bauen Sie jeweils eine Scheibe nach der anderen — fordern Sie das kleinste Ding an, das durchgängig läuft, bestätigen Sie, dass es tatsächlich läuft, und erweitern Sie es dann. Ein einziger riesiger Prompt erzeugt eine große Angriffsfläche, die Sie realistisch nicht prüfen können.
3. Committen Sie jedes Mal, wenn etwas funktioniert — Versionskontrolle ist der Rückgängig-Button für generative Arbeit. Wenn die nächste Änderung drei Dinge auf einmal kaputt macht, ist ein bekanntermaßen funktionierender Commit der einzige verlässliche Weg zurück, und er kostet nur einen Befehl.
4. Lesen Sie die riskanten Zeilen selbst — Logins, Zahlungen, alles, was Kundendaten betrifft, und alles, was löscht. Ein Modell schreibt plausiblen Code und sagt Ihnen nicht, welche Prüfung es ausgelassen hat, also werden diese Pfade Zeile für Zeile gelesen, auch wenn der Rest es nicht wird.
5. Testen Sie es wie ein Fremder — klicken Sie sich wie ein Erstnutzer durch: falsche Eingaben, leere Zustände, der Zurück-Button, ein zweites Konto. Generierte Apps sind meist auf dem Pfad korrekt, den der Prompt beschrieben hat, und überall sonst dünn.
6. Führen Sie ein Änderungsprotokoll — bitten Sie das Modell, nach jeder Scheibe zusammenzufassen, was es geändert hat und warum, und bewahren Sie diesen Text zusammen mit dem Projekt auf. Das ist die billigste Verteidigung gegen eine Codebasis, die Sie niemandem mehr erklären können, sich selbst eingeschlossen.

Wo es bricht

Die Fehlermuster sind über alle Tools hinweg konsistent, und keines davon liegt wirklich daran, dass das Modell schlecht im Programmieren ist:

• Stille Annahmen — das Modell baut, worum Sie gebeten haben, nicht das, was Sie gemeint haben. Alles, was Sie unausgesprochen gelassen haben, wird mit etwas Plausiblem aufgefüllt, und Sie entdecken die Lücke erst, wenn ein echter Nutzer darauf stößt.
• Funktionierende Dinge, die still aufhören zu funktionieren — generierte Änderungen reichen weiter, als sie scheinen. Wenn Sie das Ganze nicht nach jeder Änderung ausführen können, bemerken Sie erst viel später, was die letzte Änderung kaputt gemacht hat.
• Sicherheit, die Sie nie gewählt haben — Standard-Zugriffsregeln, zu großzügige Datenbankrichtlinien und Schlüssel, die dort committet werden, wo sie nicht hingehören, sind in generierten Apps häufig, und nichts warnt Sie davor. Prüfen Sie das vor dem Launch, nicht danach.
• Die letzten zwanzig Prozent — die ersten achtzig kommen an einem Nachmittag; beim Rest braucht das Modell, dass Sie das System wirklich verstehen. Planen Sie entweder Zeit für diese Strecke ein, oder schneiden Sie Version eins so zu, dass sie keine hat.

Was passiert, nachdem es funktioniert

Wenn Sie die Schleife durchlaufen haben, haben Sie funktionierende Software, von der niemand weiß, dass sie existiert — das ist inzwischen die typische Gründersituation: Das Bauen wurde dramatisch billiger, die Distribution nicht. Bevor Sie mehr bauen, legen Sie fest, wofür Version eins eigentlich da ist — genau darum geht es bei einem Minimum Viable Product —, und sobald es funktioniert, lautet die nächste Frage wie man eine vibe-gecodete App vermarktet.

Aus erster Hand vom Bau von AgentCeres — dem KI-Wachstumsmanager unter agentceres.com: Die meisten unserer Code- und Marketingseiten werden von KI entworfen und von einem Menschen geprüft, und die teuerste Fehlerklasse war nie schlechter Code. Es war Arbeit, die still verschwand. Zwei parallel generierte Änderungen, jede für sich korrekt und bestand jede Prüfung gegen den Ausgangspunkt, gegen den sie geschrieben wurde, und kaputt in dem Moment, in dem sie zusammengeführt wurden — weil niemand die Prüfungen am zusammengeführten Ergebnis erneut ausgeführt hat. Wenn Sie eine Gewohnheit von dieser Seite mitnehmen, dann diese: kleine Scheiben, und prüfen Sie das, was Sie tatsächlich ausgeliefert haben, statt das Stück, das Sie gerade generiert haben.