Vibe Coding ist nicht per se schlecht, es verschiebt nur, wo die Fehler auftauchen.

Seit Anfang 2025 gibt es ein Wort für etwas, das viele schon vorher getan haben: Man beschreibt einer KI, was ein Programm tun soll, nimmt, was sie liefert und probiert es aus, ohne den Code zu lesen. Andrej Karpathy, früher bei OpenAI und Tesla, hat das im Februar 2025 Vibe Coding genannt und der Begriff ist geblieben, weil er ehrlich ist. Uns wird die Frage inzwischen regelmässig gestellt, meistens in zwei Formen: ob das Werkzeug, das ein Mitarbeitender am Wochenende gebaut hat, gefährlich ist und ob man die eigene App jetzt einfach selber machen kann. Dieser Beitrag erklärt, was der Begriff bedeutet, wofür Vibe Coding wirklich taugt, wo das Risiko sitzt und warum die Einschätzung dieses Risikos nicht bei der Person liegen sollte, die den Code hat schreiben lassen.

Vibe Coding heisst, dass man beschreibt, was man will und den Code nicht mehr liest.

Programmieren mit KI gibt es in zwei Formen und der Unterschied ist der Punkt, an dem es interessant wird. In der ersten Form arbeitet ein Entwickler mit einem KI Werkzeug, liest, was es vorschlägt, verwirft die Hälfte und versteht am Ende jede Zeile, die im System landet. Das ist seit 2023 Alltag und hat mit Vibe Coding wenig zu tun, es ist Softwareentwicklung mit einem schnelleren Werkzeug. In der zweiten Form beschreibt jemand in Alltagssprache, was er will, die KI schreibt das ganze Programm und der Mensch beurteilt nur noch das Ergebnis: Sieht es richtig aus, macht es, was ich wollte. Den Code selbst liest niemand mehr und oft könnte ihn auch niemand lesen.

Vibe Coding ist nicht schlechteres Programmieren, sondern Programmieren ohne Lesen. Alles, was Lesen bisher geleistet hat, muss danach jemand anders leisten, oder es fällt weg. Was Lesen leistet, merkt man erst, wenn es fehlt: Ein Entwickler, der Code liest, sieht, dass ein Passwort im Klartext gespeichert wird, dass eine Abfrage bei zehntausend Datensätzen stehen bleibt, dass eine Bibliothek verwendet wird, die seit zwei Jahren niemand pflegt. Die Person, die nur das Ergebnis anschaut, sieht ein Programm, das funktioniert. Beides ist wahr.

Für Prototypen, interne Hilfen und Dinge, die man wegwerfen darf, ist das ein echter Gewinn.

Wir sagen das ohne Einschränkung, weil wir es selber so machen. Ein Prototyp, der zeigt, wie eine Anwendung aussehen und sich anfühlen könnte, hat früher zwei bis drei Wochen Arbeit gekostet und man hat sie meistens gespart und stattdessen diskutiert. Heute steht er an einem Nachmittag und die Diskussion wird eine andere, weil alle auf denselben Bildschirm schauen. Der Prototyp wird danach weggeworfen und das ist sein Zweck.

Dasselbe gilt für die kleinen Werkzeuge, die in jedem Unternehmen fehlen: die Tabelle, die aus dem Export der Buchhaltung monatlich die drei Zahlen zieht, die die Geschäftsleitung sehen will, das Skript, das hundert Dateien umbenennt, die Seite, die einen Termin in vier Kalendern gleichzeitig einträgt. Für so etwas hat nie jemand CHF 5'000 ausgegeben, also blieb es liegen oder wurde von Hand gemacht. Wenn ein Mitarbeitender das in zwei Stunden mit KI baut, ist der Gewinn real und lässt sich in Stunden pro Monat ausrechnen. Wir haben beschrieben, ab wann sich eigene Software rechnet und ab wann man besser kauft und Vibe Coding verschiebt diese Grenze nach unten: Dinge, die früher zu klein zum Bauen waren, sind es nicht mehr.

Das Risiko sitzt nicht im Schreiben, sondern darin, dass niemand das Ergebnis lesen kann.

Software hat schon immer Fehler gehabt, auch die von Hand geschriebene und KI schreibt nach unserer Erfahrung nicht mehr Fehler als ein durchschnittlicher Entwickler unter Zeitdruck. Der Unterschied liegt nicht in der Zahl der Fehler, sondern darin, wer sie findet und wann. Bei gelesenem Code werden Fehler beim Schreiben, bei der Durchsicht durch eine zweite Person und beim Testen gefunden, also bevor jemand mit dem Programm arbeitet. Bei Vibe Coding fallen die ersten beiden Stationen weg und das Testen beschränkt sich auf das, was die Person, die es bestellt hat, ausprobiert. Die Fehler verschwinden nicht, sie tauchen später auf: im Betrieb, bei echten Daten, bei einem Benutzer, der etwas anderes eingibt als erwartet.

Drei Arten von Fehlern kommen dabei fast immer vor und keine davon sieht man am Ergebnis. Die erste betrifft die Daten: Das Werkzeug speichert Kundendaten in einer Datei, die jeder im Netzwerk lesen kann, oder schickt sie an einen Dienst im Ausland, weil das im Beispielcode so stand. Die zweite betrifft den Zugang: Die Anmeldung funktioniert, aber sie lässt sich mit einer veränderten Adresse umgehen und das prüft niemand, der nur ausprobiert, ob das Einloggen klappt. Die dritte betrifft die Abhängigkeiten: Das Programm zieht sich beim Start dreissig fremde Bausteine aus dem Internet und wer sie pflegt, ob sie noch gepflegt werden und was sie sonst noch tun, weiss niemand im Unternehmen. Wir haben beschrieben, warum in fast jedem Unternehmen KI läuft, über die niemand entschieden hat und selbst gebaute Software ist die nächste Stufe davon: Sie ist nicht nur nicht bewilligt, sie ist auch von niemandem verstanden.

Dazu kommt der Fehler, der kein technischer ist: Das Werkzeug funktioniert, die Person, die es gebaut hat, verlässt das Unternehmen und ein Jahr später arbeitet die Buchhaltung mit einem Programm, das niemand ändern, niemand reparieren und niemand abschalten kann, weil niemand weiss, was sonst noch daran hängt. Bei einem Skript, das Dateien umbenennt, ist das egal. Bei einem Werkzeug, das Rechnungen erstellt, ist es ein Problem, das ein Vielfaches des ursprünglichen Nachmittags kostet.

Die Grenze verläuft nicht beim Werkzeug, sondern bei den Daten und bei den Leuten, die darauf angewiesen sind.

Ob Vibe Coding in Ordnung ist, lässt sich nicht pro Werkzeug beantworten, sondern nur pro Einsatz. Wir stellen dafür drei Fragen und die Antworten sagen, ob der Code gelesen werden muss.

Die erste Frage gilt den Daten, die durch das Programm fliessen. Öffentliche Daten, ein Prototyp mit erfundenen Zahlen, ein Skript für die eigene Festplatte: Hier kann man bauen lassen, so viel man will. Sobald Personendaten oder Geschäftsgeheimnisse dabei sind, gilt dasselbe wie bei jedem KI Werkzeug: Die Geschäftsleitung muss entschieden haben, was mit diesen Daten passieren darf und das Datenschutzgesetz verlangt seit dem 1. September 2023, dass jemand sagen kann, wo Personendaten liegen und wer sie bearbeitet. Ein Programm, das niemand gelesen hat, kann diese Frage nicht beantworten. Das ist unsere Lesart und keine Rechtsberatung.

Die zweite Frage gilt den Leuten, die darauf angewiesen sind. Ein Werkzeug, das eine Person für sich nutzt und morgen weglassen könnte, ist ein Hilfsmittel. Ein Werkzeug, mit dem drei Leute täglich arbeiten und ohne das die Rechnungen nicht rausgehen, ist ein System, auch wenn es an einem Nachmittag entstanden ist. Systeme brauchen jemanden, der sie versteht, ein Backup und einen Plan für den Tag, an dem sie ausfallen.

Die dritte Frage gilt der Rechnung, wenn es schief geht. Bei einem internen Werkzeug ist das ein verlorener Tag. Bei einer App für Kunden, die Zahlungen entgegennimmt, sind es der Umsatz, das Vertrauen und unter Umständen eine Meldung an den Datenschutzbeauftragten. Wer eine App Idee hat und sie jetzt selber bauen will, sollte diese Frage vor dem ersten Prompt beantworten, weil der Nachmittag sonst nur der Anfang der Kosten ist. Eine App, die Kunden nutzen, kostet mit oder ohne KI nach unserer Erfahrung CHF 10'000 bis 30'000, bis sie sicher läuft, weil das Schreiben des Codes nie der teure Teil war.

Die Risikoeinschätzung gehört zu jemandem, der den Code nicht geschrieben hat.

Wer etwas gebaut hat und stolz darauf ist, kann das Risiko nicht neutral einschätzen und das ist keine Schwäche, sondern der Grund, warum es in der Softwareentwicklung seit Jahrzehnten die Durchsicht durch eine zweite Person gibt. Bei Vibe Coding fällt sie weg und genau sie muss wieder eingesetzt werden, an der Stelle, wo es zählt: nicht bei jedem Skript, aber bei jedem Werkzeug, das die drei Fragen oben in die falsche Richtung beantwortet.

Diese Durchsicht ist kleiner, als viele befürchten. Ein erfahrener Entwickler braucht für ein Werkzeug, das an einem Nachmittag entstanden ist, zwei bis vier Stunden, um zu sagen, welche Daten wohin fliessen, ob der Zugang hält, welche Abhängigkeiten drinstecken und ob man es so betreiben kann oder neu bauen sollte. Das Ergebnis ist selten ein Verbot. Meistens ist es eine kurze Liste: drei Dinge ändern, eines dokumentieren und die Regel, dass dieses Werkzeug keine Kundendaten sieht. Manchmal ist das Ergebnis, dass das Werkzeug genau richtig ist, so wie es ist und dann hat die Geschäftsleitung das schwarz auf weiss statt als Bauchgefühl.

Im Unternehmen ist das die Aufgabe eines CTO: zu entscheiden, was gebaut, gekauft und gelassen wird und dafür die Verantwortung zu tragen. Die meisten KMU haben diese Rolle nicht und Vibe Coding ist einer der Gründe, warum sie jetzt fehlt: Software entsteht neu an Orten, an denen früher keine entstanden ist und niemand schaut alles zusammen an. Wer diese Rolle nicht besetzt, kann sie für den einzelnen Fall holen. Wichtig ist nur, dass die Person, die einschätzt, nichts daran verdient, ob das Werkzeug bleibt, neu gebaut oder abgeschaltet wird.