Was Vibe Coding wirklich ist – und was nicht

Der Begriff ist in kurzer Zeit überall aufgetaucht, und wie das bei solchen Begriffen üblich ist, meint inzwischen jeder etwas anderes damit. Für die einen ist Vibe Coding der Beweis, dass Softwareentwicklung trivial geworden ist. Für die anderen ist es ein Schimpfwort für Prototypen, die niemand warten kann. Beide Lager haben ein bisschen recht und übersehen dasselbe.

Ich arbeite so, und deshalb schreibe ich hier auf, was ich darunter verstehe.

Die einfache Definition

Vibe Coding heisst: Sie beschreiben, was entstehen soll, und die Implementierung entsteht daraus. Sie lesen nicht mehr primär Code, Sie beurteilen Resultate. Der Ort, an dem gearbeitet wird, verschiebt sich von der Syntax zur Absicht.

Das klingt nach einer Kleinigkeit und ist keine. Es dreht die Arbeitsteilung um. Früher war die Spezifikation das lästige Vorspiel und die Implementierung die eigentliche Arbeit. Heute ist die Spezifikation die eigentliche Arbeit, und die Implementierung ist das, was danach passiert.

Was es nicht ist

Es ist nicht «keine Ahnung von Software haben». Das ist das grösste Missverständnis. Wer nicht beurteilen kann, ob eine Datenstruktur trägt, ob eine Schnittstelle sinnvoll geschnitten ist oder ob eine Fehlerbehandlung tatsächlich den Fehler behandelt, bekommt trotzdem etwas Lauffähiges. Er merkt einfach später, dass es das Falsche ist. Vibe Coding senkt die Kosten des Bauens, nicht die Anforderungen ans Urteilsvermögen.

Es ist nicht «einmal beschreiben, fertig». Es ist ein Dialog. Beschreiben, anschauen, korrigieren, präzisieren. Wer beim ersten Resultat aufhört, hat den Prozess nicht durchlaufen, sondern abgebrochen.

Es ist kein Ersatz für Architektur. Im Gegenteil: Weil so viel so schnell entsteht, entscheidet die Struktur früher über das Schicksal des Projekts als vorher. Eine schlechte Datenmodellierung produziert heute in zwei Tagen den Schaden, für den man früher zwei Monate gebraucht hätte.

Es ist kein Prototyping-Werkzeug. Es kann für Prototypen benutzt werden, aber wer es nur dafür einsetzt, verschenkt den grösseren Teil. Der Unterschied zwischen Prototyp und Produkt liegt nicht in der Art, wie der Code entstanden ist, sondern darin, ob jemand für Betrieb, Sicherheit und Wartung geradesteht.

Was es wirklich ist

Aus meiner Praxis: Vibe Coding ist vor allem eine Verschiebung des Engpasses.

Vorher lag der Engpass in der Umsetzungskapazität. Man wusste ziemlich genau, was man wollte, und die Frage war, wann jemand Zeit hat, es zu bauen. Priorisierung war deshalb immer eine Diskussion über Aufwand.

Heute liegt der Engpass in der Klarheit. Die Frage ist nicht mehr, wann etwas gebaut werden kann, sondern ob ausreichend präzise beschrieben ist, was gebaut werden soll. Und das ist eine unangenehmere Frage, weil sie an den Auftraggeber zurückgeht statt an das Entwicklungsteam.

In Projekten merkt man das sofort. Sobald eine fachliche Frage offen ist – was passiert bei diesem Sonderfall, welche Regel gilt hier wirklich –, steht die Arbeit. Nicht weil die Technik fehlt, sondern weil die Entscheidung fehlt.

Wie das im Alltag aussieht

Ein typischer Zyklus bei uns hat vier Schritte, und drei davon haben nichts mit Code zu tun.

Verstehen. Was soll das Ding tun, für wen, unter welchen Bedingungen. Was sind die Sonderfälle, die im Gespräch immer erst beim dritten Nachfragen auftauchen.

Beschreiben. Nicht in Prosa, sondern präzise genug, dass es eindeutig ist. Datenstrukturen, Regeln, erwartetes Verhalten an den Rändern.

Erzeugen. Der schnelle Teil. Hier entsteht die Implementierung.

Prüfen. Läuft es – und stimmt es fachlich? Zwei völlig verschiedene Fragen. Die erste beantwortet ein Test. Die zweite beantwortet jemand, der die Fachlichkeit versteht.

Wer diesen Zyklus als Ganzes fährt, bekommt in Tagen Software, die vorher Monate gebraucht hätte. Wer nur den dritten Schritt macht, bekommt schnell etwas, das aussieht wie Software.

Warum ich den Begriff trotzdem mag

Er ist unpräzise, aber er trifft etwas Richtiges: dass sich der Modus des Arbeitens geändert hat. Man denkt nicht mehr in Implementierungsschritten, sondern in Absichten und Resultaten. Das fühlt sich tatsächlich anders an – flüssiger, weniger mechanisch.

Was der Begriff nicht transportiert, ist die Verantwortung, die dabei bleibt. Deshalb sage ich Kunden lieber, wie wir arbeiten, als wie es heisst: Erst verstehen wir das Geschäft, dann setzen wir um, dann bringen wir es in Betrieb und bleiben dafür zuständig.

Im nächsten Beitrag geht es um die Ebene darüber: Warum die meisten AI-Initiativen in KMU nicht an der Technik scheitern, sondern daran, dass niemand ein Gesamtkonzept hat.