Warum Vibe-Coding-Bugs in Clustern auftreten
Ein Agent optimiert auf den Pfad, den Sie beschrieben haben. Sie beschreiben das, was passieren soll – also entsteht der Happy Path sorgfältig und alles drumherum entsteht plausibel. Plausibel ist dabei das entscheidende Wort: Der Code kompiliert, der Bildschirm rendert, und die Annahmen wurden nie mit der Realität abgeglichen.
Genau deshalb sind die Fehler vorhersehbar. Sie liegen immer an den Rändern der Beschreibung.
Die vier Cluster, in der Reihenfolge, in der sie zuschlagen
Persistenz. Die Anzeige aktualisiert sich, die Datenbank nicht. Ein Reload macht es sofort sichtbar. Laden Sie nach jedem Schreibvorgang neu, bevor Sie irgendetwas glauben.
Leere Zustände und Fehlerzustände. Keine Treffer, eine fehlgeschlagene Anfrage, eine abgelehnte Eingabe. Nichts davon stand in Ihrem Prompt. Probieren Sie jeden Fall gezielt aus. Sie brechen häufiger als der Happy Path.
Das zweite Konto. Eigentümerschaft, Berechtigungen und Sichtbarkeit werden aus der einen Sitzung abgeleitet, in der die App entstanden ist. Melden Sie sich als jemand anderes an, bevor es jemand anderes tut.
Der vierte ist subtiler: die Features von gestern. Jede neue Anweisung kann unbemerkt etwas rückgängig machen, das funktioniert hat, und niemand prüft das alte Verhalten, weil das Gespräch längst weitergezogen ist.
Die Prüfung, die mit dem Prompten mitwächst
Manuelles Prüfen funktioniert einen Nachmittag lang und lässt dann nach, denn der Prüfumfang wächst mit jedem Prompt, Ihre Geduld nicht. Was Sie brauchen, sind Prüfungen, die in natürlicher Sprache festgehalten und automatisch ausgeführt werden – damit die Features von gestern erneut verifiziert werden, ohne dass Sie sich jedes Mal dafür entscheiden müssen.
Die Einrichtung legt genau das in die Hände des Agenten, sodass das Prüfen parallel zum Bauen passiert und nicht als separate Pflichtübung.
Nichts davon erfordert ein Terminal. Legen Sie im TestSprite-Dashboard ein Projekt an, beschreiben Sie die Prüfung in natürlicher Sprache und richten Sie sie auf Ihre App. Entwickler in Ihrem Team können dasselbe über die Kommandozeile steuern, wenn ihnen das lieber ist – zu finden im CLI-Repository.
Zehn Minuten, die das meiste davon finden
Registrieren, abmelden, wieder anmelden. Der häufigste Totalausfall – und das Erste, was ein echter Nutzer tut.
Etwas anlegen, neu laden, prüfen, ob es überlebt hat. Deckt das Persistenz-Cluster unmittelbar auf.
Etwas Ungültiges absenden. Sie prüfen, ob es klar fehlschlägt, statt stillschweigend durchzugehen.
Den Hauptablauf mit einem ganz neuen Konto durchgehen. Deckt das Berechtigungs-Cluster auf.
Keine dieser Prüfungen erfordert, Code zu lesen, und zusammen finden sie das meiste von dem, was sonst jemand Fremdes finden würde.
Warum derselbe Bug immer wiederkommt
Die häufigste Beschwerde über diese Art zu bauen ist nicht, dass Dinge kaputtgehen, sondern dass das Beheben einer Sache immer wieder eine andere kaputt macht. Das ist kein Modellversagen. Es fehlt eine Aufzeichnung.
Jede Anweisung wird ausschließlich gegen den aktuellen Stand des Codes interpretiert. Es gibt keine Liste von Verhaltensweisen, die bereits weiter funktionieren mussten, also kann der Agent nicht wissen, dass die gewünschte Änderung mit etwas kollidiert, das Sie letzten Dienstag festgelegt haben. Aus seiner Sicht gibt es keinen Konflikt, denn der letzte Dienstag ist nicht im Raum.
Aufgeschriebene Prüfungen sind genau diese Aufzeichnung. Sie machen den Agenten nicht klüger, sie machen Ihre Absicht dauerhaft. Praktisch heißt das: Die dritte und vierte Änderungsrunde machen die ersten beiden nicht mehr zunichte – und genau ab diesem Punkt fühlt sich diese Art zu bauen verlässlich an statt zermürbend.
Bevor es irgendwo ernst wird
Sobald andere Menschen die App nutzen, sollten die Prüfungen bei jeder Änderung laufen und nicht dann, wenn Sie daran denken.
Die GitHub App ist ein Webhook, den Sie im TestSprite-Dashboard einrichten. Er lauscht auf das Deployment-Event, das Ihre Pipeline ohnehin erzeugt – in Ihrem Repository ändert sich also nichts.
GitHub Actions bindet den Schritt in Ihren eigenen Workflow ein, konfiguriert über das Terminal.
Die Prüfungen von selbst laufen lassen
Mit TestSprite hören die zehn Minuten Prüfarbeit auf dieser Seite auf, Handarbeit zu sein. Sie beschreiben jeden Ablauf einmal in natürlicher Sprache, und TestSprite führt ihn nach jeder Änderung gegen Ihre App aus.
Damit ist genau das behoben, was die meisten an dieser Art zu bauen am frustrierendsten finden. Die aufgeschriebenen Prüfungen sind die Aufzeichnung dessen, was bereits weiter funktionieren musste – eine neue Anweisung wird also gegen sie verifiziert statt isoliert interpretiert. Die Schleife, in der das Beheben einer Sache eine andere kaputt macht, ist nicht länger der Normalfall.
Nichts davon erfordert ein Terminal oder eine Testdatei. Legen Sie im Dashboard ein Projekt an, richten Sie es auf Ihre App und beschreiben Sie die vier Prüfungen von oben. Entwickler in Ihrem Team können dasselbe über die Kommandozeile steuern, wenn ihnen das lieber ist.
Ist Vibe Coding einfach riskanter?
Es verschiebt, wo das Risiko liegt. Weniger Risiko durch Tippfehler, mehr Risiko durch ungeprüfte Annahmen. Die Antwort darauf ist nicht, wieder jede Zeile zu lesen, sondern Verhalten systematisch zu prüfen.
Warum macht das Beheben einer Sache eine andere kaputt?
Weil jede Anweisung im Kontext des aktuellen Codes interpretiert wird und nicht gegen eine Aufzeichnung dessen, was bereits weiter funktionieren musste. Aufgeschriebene Prüfungen liefern diese Aufzeichnung.
Muss ich Tests schreiben?
Nicht in Code. Beschreiben Sie den Ablauf in natürlicher Sprache, halten Sie ihn fest und lassen Sie ihn nach jeder Änderung automatisch laufen.
Woher weiß ich, dass die Prüfung wirklich greift?
Machen Sie absichtlich etwas kaputt und bestätigen Sie, dass die Prüfung fehlschlägt. Eine Prüfung, die nie fehlschlägt, schützt nichts – und das lässt sich in einer Minute verifizieren.
Wann sollte ich mit dem Prüfen anfangen?
Bevor Sie es jemandem zeigen. Eine jetzt geschriebene Prüfung kostet Minuten; nachdem jemand anderes den Bug gefunden hat, kostet es deutlich mehr.
Prüfen Sie die vier Cluster, nicht den Code.
Vibe-Coding-Bugs sammeln sich rund um Persistenz, leere Zustände, zweite Konten und Features, die Sie gestern gebaut haben. Zehn Minuten decken die meisten davon ab, und erst das Aufschreiben dieser Prüfungen verhindert, dass sie beim Weiterprompten zurückkommen.