Vibe Coding: Programmieren im Dialog

Auf meiner Startseite steht, dass die Ideen von mir kommen und die Umsetzung mit KI passiert. Für diese Arbeitsweise gibt es inzwischen einen Namen: Vibe Coding. Der Begriff klingt nach Bauchgefühl statt Handwerk, nach hinschreiben was gerade passt und weiterschauen. Bei mir sieht die Praxis anders aus. Was am Ende steht, ist geplant, nicht zufällig, nur der Weg dahin führt über ein Gespräch mit einem Modell statt über jede Zeile von Hand. Genau darin liegt auch die Grenze des Begriffs: Er beschreibt gut, wie schnell heute etwas entsteht, aber er sagt nichts darüber, was es später kostet.

Was der Begriff meint

Geprägt hat ihn Andrej Karpathy Anfang 2025. Die Idee: Man beschreibt, was man will, lässt das Modell den Quellcode schreiben und schaut ihn sich nicht mehr genau an. Man vergisst, dass es überhaupt Quellcode gibt. Läuft es, ist es gut. Läuft es nicht, beschreibt man den Fehler und lässt das Modell noch einmal ran. Das ist der eigentliche Kern und der ist radikaler, als die meisten denken. Nicht „Programmieren mit KI“, sondern „ich lese das Ergebnis nicht mehr“.

Warum das verführerisch ist

Der eigentliche Effekt von Vibe Coding ist nicht, dass ich schneller programmiere. Es ist, dass ganze Kategorien von Software entstehen, die es vorher schlicht nicht gab, weil sich der Aufwand nie gelohnt hätte. Ein kleines Tool für ein Nischenproblem, eine Spielerei für einen Nachmittag, eine Idee, die erst mal drei Wochen Einarbeitung gekostet hätte, bevor man überhaupt wusste, ob sie funktioniert. Solche Dinge sind früher fast immer im Kopf geblieben, weil die Distanz zwischen Idee und lauffähigem Ergebnis zu groß war. Man hat abgewogen, ob sich die Mühe lohnt und die Antwort war meistens nein.

Mit KI kippt diese Rechnung. Die Hürde sinkt so weit, dass sie unter der Reizschwelle liegt, ab der man eine Idee normalerweise verwirft. Man probiert einfach aus, statt vorher zu prüfen, ob es sich lohnt. Das verändert nicht nur, was gebaut wird, sondern auch wie: Software wird zum Wegwerfprodukt für einen einzelnen Zweck, aus einer Laune heraus gebaut und oft schon nach Gebrauch wieder vergessen. Vieles davon ist Ballast, Halbfertiges, das niemand außer einem selbst je zu sehen bekommt. Aber ein Teil davon wäre ohne diese neue Beiläufigkeit nie entstanden und genau das ist der eigentliche Unterschied zum klassischen Programmieren.

Wo es kippen kann

Zum Problem wird es bei dem, was bleiben soll. Mein Sleek Audio Player ist inzwischen ein Plugin, das auf einer echten Seite läuft und Leute benutzen. Da rächt sich jede Zeile, die ich nie gelesen habe. Der Punkt ist immer der gleiche. Etwas geht kaputt und niemand versteht, warum, weil nie jemand verstanden hat, wie es funktioniert. Dann beschreibt man dem Modell den Fehler, es baut etwas um, ein anderes Ding geht kaputt. Wer da schon zehn Runden gedreht hat, weiß, wovon ich rede.

Dazu kommt: Ein Modell schreibt Quellcode, der plausibel aussieht. Das ist genau das Problem, das ich bei der AI Verifikation beschrieben habe. Plausibel ist nicht geprüft. Bei Text merkt man es. Bei Quellcode merkt es der Server. Und zwar meistens dann, wenn es gerade am wenigsten passt.

Das Netz mit doppeltem Boden

Eine Sache hat mich lange beschäftigt. Ich hatte eine Änderung, alle Tests grün, sieben Prüfläufe ohne Beanstandung. Auf der echten Seite hat es trotzdem nicht funktioniert. Wochenlang, ohne dass es jemand merkt. Grün heißt nicht richtig. Es heißt nur, dass das geprüft wurde, woran jemand gedacht hat.

Genau daraus ist ein Rahmen geworden. Ohne den würde ich so nicht mehr arbeiten und er besteht aus vier Dingen.

Erstens die Technik festlegen: welche Sprachversion, welche Abhängigkeiten, was ausdrücklich nicht dazukommt. Steht das nicht fest, entscheidet es das Modell bei jeder Anfrage neu und man hat nach drei Wochen vier Bauweisen im selben Projekt. Zweitens die Konventionen an eine Stelle schreiben, die das Modell mitliest. Bei mir ist das eine Regeldatei im Projekt und sie ist genau deshalb wertvoll, weil sie nicht nur für mich gilt, sondern auch für das Werkzeug.

Drittens die Prüfungen automatisieren, damit sie bei jedem Schritt laufen: Syntax, Abhängigkeiten, Übersetzungen und vor allem Tests, die das Verhalten festnageln. Tests verhindern keine Fehler, sie verhindern, dass derselbe Fehler zweimal passiert. Und viertens eine Umgebung, die der echten gleicht. Bei mir läuft die Seite lokal mit denselben Einstellungen und was dort funktioniert, hat eine Chance.

Dazu die Sicherheitsfrage, die am Anfang gestellt werden muss und nicht am Ende. Was darf das Werkzeug überhaupt anfassen? Wo deine Zugangsdaten liegen und was passiert, wenn ein Vorschlag ungeprüft durchläuft, gehört in dieselbe Runde.

Der doppelte Boden ist dann genau das: Die Automatik fängt die mechanischen Fehler, der Blick auf die laufende Seite fängt das, woran niemand gedacht hat. Einer allein reicht nicht. Das habe ich mit sieben grünen Prüfläufen teuer gelernt.

Ohne Sachverständnis nützt der ganze Rahmen allerdings nichts. Wer nicht weiß, was im eigenen Fach schiefgehen kann, baut Prüfungen, die nichts prüfen. Ein Test, den man nicht versteht, ist Dekoration.

Wer sich das alles spart, bekommt genau das Chaos, das man vom Vibe Coding erwartet. Nicht am ersten Tag, sondern im dritten Monat. Wenn niemand mehr weiß, warum der Quellcode so aussieht, wie er aussieht. Und wenn niemand mehr wagt, etwas daran zu ändern, weil jede Änderung an unerwarteter Stelle etwas kaputt macht. Dann steht man vor einem Haufen Code, den keiner mehr versteht und keiner mehr anfassen will.

Das Lernen mit KI gilt hier genauso. Der schwerere Weg ist oft der bessere, weil er das Verständnis mitliefert, das man später braucht.

Meine Rolle dabei

Die Frage ist nicht, ob das Modell den Quellcode schreibt. Es schreibt ihn. Die Frage ist, wer dafür einsteht. Und diese Frage lässt sich nicht an eine API delegieren.

Verantwortung wandert nämlich nicht mit. „Das Modell hat das so geschrieben“ ist keine Auskunft, die irgendwer akzeptiert. Und das ist richtig so. Wenn mein Plugin die Seite von jemandem zerlegt, steht da mein Name und nicht der einer Maschine.

Also bin ich nicht mehr der, der tippt. Ich bin der, der beauftragt und der, der prüft. Auftraggeber und Prüfinstanz in einer Person. Mündig heißt dabei: sagen können, warum etwas drinsteht. Nicht jede Zeile, aber jede Entscheidung. Wer das nicht kann, hat nicht delegiert, sondern abgegeben.

Daraus folgen drei Pflichten. Entscheiden, was überhaupt gebaut wird. Genug verstehen, um das Ergebnis beurteilen zu können. Und gegen die Wirklichkeit prüfen, nicht gegen das Versprechen.

Praktisch heißt das vier Dinge. Den Diff lese ich, jeden, nicht jede Zeile im Detail, aber ich will wissen, was sich geändert hat und warum. Eine Sache pro Schritt: Struktur umbauen und Verhalten ändern nie gleichzeitig, sonst weiß hinterher niemand, was den Fehler gebracht hat. Erklären lassen, was der Quellcode tut, bevor er übernommen wird, weil das Erklären die Lücken zeigt. Und streng trennen zwischen Wegwerf und Bleibt.

Das Unbequeme daran: Diese Rolle ist anstrengender als Tippen, nicht bequemer. Quellcode schreiben zu lassen, den man nicht versteht, ist leicht. Quellcode zu beurteilen, den man nicht geschrieben hat, ist Arbeit. Genau darum geht es auch beim Meaningful Work im KI Zeitalter: Was bleibt, ist nicht das Ausführen. Es ist das Urteil.

Ausblick

Der Begriff wird bleiben und er wird sich abnutzen. Was heute Vibe Coding heißt, ist in zwei Jahren einfach Programmieren, so wie niemand mehr sagt, er schreibe „mit Syntaxhervorhebung“. Was bleibt, ist die Frage, wer noch versteht, was die Modelle da eigentlich gebaut haben.

Die interessante Frage ist eine andere. Wenn Modelle die Umsetzung übernehmen, bleibt das Beschreiben. Genau zu wissen, was man will und es so zu sagen, dass es keine zwei Lesarten hat. Das ist keine neue Fähigkeit, sie war nur nie so sichtbar. Wer sich unklar ausdrückt, bekommt jetzt sofort die Rechnung dafür, in Form von Quellcode, der etwas anderes tut.

Mein Fazit

Vibe Coding ist großartig für Sachen, die niemand pflegen muss. Für alles andere ist es ein Kredit, den man später mit Zinsen zurückzahlt. Wer das weiß, kann es bewusst einsetzen. Wer es ignoriert, wird irgendwann von der Rechnung überrascht.

Was bleibt, ist die Rolle: beauftragen und prüfen. Ich nutze KI bei jeder Zeile. Und lese trotzdem mit. Das ist kein Widerspruch, das ist der Unterschied zwischen einem Werkzeug und einem Blindflug. Wer die Verantwortung abgibt, gibt am Ende auch die Kontrolle ab.

Wenn du noch tiefer einsteigen willst: Im KI Glossar findest du alle Grundlagen kompakt erklärt.