Wann Vibe Coding reicht und wann nicht

Irgendwann zeigt jemand aus der Fachabteilung eine Anwendung, die es am Vortag noch nicht gab. Eine Übersicht über offene Reklamationen, ein Formular für Urlaubsanträge, ein kleines Portal für Lieferanten. Gebaut an einem Nachmittag, von jemandem, der nie programmiert hat. Und sie funktioniert. Die Ergebnisse sind gut, und wer sie einmal gesehen hat, lässt sie sich nicht mehr ausreden, ganz gleich, wie viele Bedenken danach im Raum stehen.

Vibe Coding heißt, eine Anwendung in Alltagssprache zu beschreiben und eine KI den Programmcode schreiben zu lassen, ohne ihn selbst zu lesen. Andrej Karpathy hat den Begriff im Februar 2025 geprägt, und noch im selben Jahr hat Collins ihn zum Wort des Jahres gewählt. Plattformen wie Lovable oder Bolt haben daraus ein Produkt gemacht. Man beschreibt, was man braucht. Wenige Minuten später läuft die Anwendung im Browser. Die Frage, die danach kommt, ist eine andere: ob das laufen darf, und wie lange.

Warum es so schnell geht

Naheliegend ist die Annahme, eine solche Plattform sei ein offener Raum, in dem die KI alles baut, was man ihr beschreibt. Das Gegenteil trifft zu. Lovable und Bolt haben fast alles Technische vorab entschieden: womit gebaut wird, wo die Daten liegen, wie sich jemand anmeldet und wo die Anwendung am Ende läuft, sodass der Autor von all dem nichts wissen muss. Genau das ist die Absicht. Darin liegt das Tempo: Jede Entscheidung, die schon getroffen ist, muss niemand mehr treffen. Eine Plattform, die fast alles festlegt, bringt jemanden ohne Vorkenntnisse in einer Stunde zu einem Ergebnis, und die Enge ist die Bedingung dafür. Sie dient einer bestimmten Person zu einem bestimmten Zeitpunkt, dem Autor der Idee im ersten Moment.

Wofür das gebaut ist

Ein Fehler ist auf so einer Plattform billig. Gefällt das Ergebnis nicht, beschreibt man es neu, und die KI erzeugt eine neue Fassung. Wer eine Idee prüfen will, hat nach einer Stunde etwas zum Anklicken und spart sich drei Abstimmungsrunden mit Folien, in denen jeder etwas anderes vor Augen hatte. Wer ein Werkzeug für sich und zwei Kollegen braucht, hat es am Abend. Und eine Anwendung, die nur eine Aktion, eine Messe oder einen Monat überleben soll, braucht keine Zukunft. In diesen Fällen ist das Tempo der ganze Wert. Vorsicht wäre hier falsch platziert.

Was sich ändert, wenn andere sich darauf stützen

Die Rechnung kippt in dem Moment, in dem sich andere auf die Anwendung stützen, also wenn zwanzig Leute damit arbeiten, wenn Kundendaten darin liegen oder wenn sie an die Daten des Betriebs angeschlossen ist. Dann ist ein Fehler nicht mehr billig. Neu erzeugen hilft nicht. Der Fehler ist dann schon passiert, und zwar bei jemand anderem.

Wie das aussieht, hat die Sicherheitsfirma UpGuard Anfang Oktober 2026 gezeigt. Sie hat rund dreihunderttausend Internetadressen untersucht und 16.326 Datenbanken beim Dienst Supabase gefunden, deren Inhalt jeder im Netz lesen konnte. Supabase ist der Speicher, in dem Lovable und viele ähnliche Werkzeuge die Daten ihrer Anwendungen ablegen. In mehr als der Hälfte der offenen Datenbanken fanden sich Hinweise auf Personendaten, in einem kleineren Teil Passwörter. Neu war das Muster nicht: Schon im Frühjahr 2025 hatte ein Entwickler dasselbe bei vielen mit Lovable gebauten Anwendungen gefunden.

Der Mechanismus ist schlicht: Legt ein KI-Assistent einen neuen Datenbestand an, ist der zunächst nicht geschützt, und die Regel, wer welche Daten sehen darf, muss jemand eigens setzen. Wer den Programmcode nie liest, merkt nicht, dass sie fehlt. Die Anwendung funktioniert ja. Dass jeder mitlesen kann, sieht man ihr nicht an. UpGuard rechnet damit, dass das so bleibt, weil der typische Autor mit seinem Assistenten spricht und nicht mit seinem Code.

Für die Leitung eines Unternehmens zählt daran weniger die Zahl als die Frage, wo die Verantwortung liegt. Lovable prüft beim Veröffentlichen und meldet, was es findet, aber ob jemand den Hinweis befolgt, entscheidet der Autor. Lovable ist als Anbieter nach anerkannten Sicherheitsnormen zertifiziert, aber dieses Zertifikat gilt dem Anbieter und seinem Betrieb und sagt nichts über die Anwendung, die jemand auf der Plattform gebaut und veröffentlicht hat. Für die einzelne Anwendung steht der Kunde gerade, und bei einer Anwendung vom Nachmittag ist dieser Kunde der Autor. Oft weiß er nicht, dass er es ist.

Der Übergang, den niemand beschließt

Die meisten Anwendungen vom Nachmittag bleiben, was sie waren: ein Entwurf, ein kleines Werkzeug, etwas, das nach der Messe niemand mehr öffnet. Einige werden mehr. Gerade die sind das Problem. Der Weg dorthin besteht aus kleinen Schritten, und jeder davon ist vernünftig. Ein Kollege fragt, ob er das auch benutzen darf. Dann fragt eine zweite Abteilung. Jemand trägt echte Kundendaten ein, weil die Beispieldaten nicht mehr reichen.

Ein halbes Jahr später stützen sich zwanzig Leute auf eine Anwendung, die als Versuch begonnen hat, und für keinen dieser Schritte hat jemand etwas entschieden. Deshalb hat auch niemand geklärt, wer sie pflegt, wenn sich im Ablauf etwas ändert, wer prüft, wer welche Daten sieht, und was passiert, wenn der Autor in eine andere Abteilung wechselt oder kündigt. Die Verantwortung liegt bei ihm. Übernommen hat er sie nie. Er wollte etwas ausprobieren.

Unten links ist ein Fehler billig, weil man neu erzeugen kann. Oben rechts ist er schon passiert, bei jemand anderem. Den Weg dazwischen beschließt selten jemand.

Dasselbe Prinzip bei Entwicklern

Für Programmierassistenten wie Claude Code oder Cursor, mit denen Entwickler arbeiten, gilt im Kern dasselbe, auch wenn sie weniger festlegen als Lovable oder Bolt und dem, der sie bedient, deutlich mehr Spielraum lassen. Einen Rahmen setzen sie nicht. Ob die Regel gesetzt wird, wer welche Daten sehen darf, hängt an dem Menschen, der den Assistenten benutzt, und daran, ob er liest, was der Assistent für ihn schreibt. Die offenen Datenbanken, die UpGuard gefunden hat, entstehen dort, wo ein Assistent sie anlegt und niemand hinsieht. Welcher Assistent das war, spielt kaum eine Rolle.

Hier liegt auch ein Denkfehler nahe, den das Stück über zwei Einstiege beschreibt. Wer viele kleine Anwendungen hat gelingen sehen, schließt leicht darauf, dass die großen genauso gelingen werden. Die kleinen gelingen aber auch deshalb, weil ein Fehler in ihnen billig ist. Bei den großen ist er das nicht mehr.

Zwei Fragen

Ob Vibe Coding angemessen ist, hängt an keinem Werkzeug. Es hängt an zwei Fragen: Wie lange soll die Anwendung leben? Und wer stützt sich auf sie? Eine Anwendung für wenige Leute und kurze Zeit ist bei Lovable oder Bolt gut aufgehoben, und das Tempo ist dort ein echter Gewinn, weil ein Fehler in ihr wenig anrichtet und schnell behoben ist. Eine Anwendung, auf die sich viele stützen, die Daten des Betriebs berührt und über Jahre laufen soll, braucht dagegen jemanden, der für sie geradesteht. Dazwischen liegt der Übergang. Er geschieht leise.

Was Sie daraus machen, wissen Sie besser als ich. Die beiden Fragen lassen sich an jede Anwendung stellen, auch an die, die heute Nachmittag entsteht.