Vibe Coding: was im Team davon übrig bleibt

Wo der Prototyp aufhört und der Betrieb anfängt

Der Begriff stammt von Andrej Karpathy und beschrieb ursprünglich einen bewussten Umgang mit Wegwerfcode: Man beschreibt, was passieren soll, nimmt das Ergebnis, ohne es Zeile für Zeile zu lesen, und wirft es wieder weg. Im Unternehmen fällt der letzte Teil regelmäßig aus. Was funktioniert, bleibt, und plötzlich hängt eine Abteilung an einer Anwendung, die niemand gelesen hat.

Die brauchbare Grenze ist nicht die Größe des Codes, sondern die Frage, wer Schaden nimmt, wenn er falsch läuft. Solange nur die Person betroffen ist, die ihn geschrieben hat, ist alles erlaubt. Sobald echte Daten, echtes Geld oder andere Menschen im Spiel sind, gelten dieselben Regeln wie für jede andere Software im Haus.

Die Lücken, die immer wieder auftauchen

Ein Muster wiederholt sich: Die Prüfung, ob jemand etwas überhaupt darf, fehlt auf der Serverseite und existiert nur in der Oberfläche. Wer die Adresse der Schnittstelle direkt aufruft, bekommt alle Daten. Das ist kein Fehler des Werkzeugs, sondern die Folge der Aufgabenstellung: Gefragt wurde nach einer Funktion, nicht nach einer Berechtigungsprüfung.

Dazu kommen Zugangsdaten, die im Quelltext oder im ausgelieferten Skript stehen, weil sie im Prototyp einfach dort lagen. Häufig hängt die Datenbank direkt am Browser, ohne Rechte auf Zeilenebene, sodass sich mit einem beliebigen Konto die Daten aller anderen lesen lassen. Es fehlt eine Begrenzung der Aufrufe, sodass ein einzelnes Skript den Dienst lahmlegt, und Eingaben wandern ungeprüft in Abfragen oder Befehle.

Hinzu kommt eine dritte Klasse von Fehlern, die es vorher so nicht gab: Abhängigkeiten, die es gar nicht gibt. Modelle schlagen gelegentlich Paketnamen vor, die plausibel klingen und nicht existieren. Wenn jemand einen solchen Namen später registriert, installiert deine Anwendung beim nächsten Durchlauf fremden Code. Der Schutz dagegen ist banal und wird trotzdem oft übersprungen: jede neue Abhängigkeit einmal ansehen, bevor sie in die Sperrdatei wandert.

Technische Schulden, die anders aussehen als früher

Klassische Schulden entstehen durch Abkürzungen, die jemand bewusst genommen hat und im Kopf hat. Hier entstehen sie durch Code, den niemand im Kopf hat. Er sieht ordentlich aus, ist einheitlich formatiert und kommentiert, und trotzdem kann niemand im Team sagen, warum eine Stelle so gelöst wurde.

Das schlägt beim ersten Fehlerbild durch: Die Suche dauert länger, weil das gemeinsame Bild von der Anwendung fehlt. Wer den Ansatz nutzt, sollte deshalb nicht am Testen sparen, sondern eher mehr davon einplanen. Tests sind hier die einzige Beschreibung des gewünschten Verhaltens, die noch stimmt.

Regeln, die den Ansatz nutzbar machen

Vier Vereinbarungen reichen für den Anfang. Erstens geht ein generierter Entwurf nicht anders in Betrieb als jeder andere Beitrag, also über dieselbe Prüfung. Zweitens hat jede Person, die einen Entwurf einreicht, ihn gelesen und kann jede Stelle erklären. Drittens werden neue Abhängigkeiten einzeln bestätigt. Viertens bekommen Prototypen niemals Zugriff auf echte Daten, sondern nur auf einen präparierten Bestand.

Diese Regeln sind keine Bremse, sondern das, was den schnellen Einstieg überhaupt bezahlbar macht. Ohne sie verschiebt sich der gesparte Nachmittag in Wochen an Fehlersuche.