3 Doku-Verfütterer 4 Der Lotse ~9 Min

Regression beim Vibecoding: Bug-Test, damit die KI nichts kaputtmacht

Derselbe Bug zum fünften Mal - das ist kein Pech. Das ist ein Muster.

Die KI fixt einen Bug, eine Stunde später macht sie ihn wieder kaputt, und das im Kreis. Wie ein einziger Regressionstest fängt, was die KI selbst einfach nicht sieht. Guide für Vibecoder.

ECC-Skills in dieser Lektion: ai-regression-testing

Warum die KI ihren eigenen Fehler nicht sieht

Stell dir vor: Du gibst eine Klausur ab und korrigierst sie selbst. Das Wort „Pfert“ mit t am Ende fällt dir weder beim ersten noch beim zehnten Mal auf - in deinem Kopf schreibt es sich genau so. Du kannst es zwanzig Mal durchlesen. Jedes Mal sagst du selbstbewusst: „alles korrekt“.

Die KI ist genau dieser Schüler. Sie schreibt selbst und prüft selbst. Und sie stolpert immer an denselben Stellen. Sie fixt einen Bug, schaut sich ihre Arbeit an, sagt „sieht richtig aus“ - und der Bug ist immer noch da. Lebendig und zufrieden. Eine Stunde später bittest du sie, etwas daneben anzupassen, und sie macht das kaputt, was sie gerade gefixt hat. Und sieht es wieder überhaupt nicht.

Ein und derselbe Roboter sitzt auf zwei Stühlen: links schreibt er Code, rechts prüft er seinen eigenen Code und sieht den Fehler nicht
Autor und Prüfer - ein und dieselbe Person. Deshalb schiebt sie den Fehler einfach von der linken in die rechte Hand.

Warum du das als Vibecoder wissen musst

Du bist Vibecoder. Tests schreibst du nicht von Hand. Aber du musst verstehen, warum die KI immer wieder in dieselbe Falle tappt - und sie bitten können, vorzusorgen. Verstehst du die Mechanik, bekommst du Folgendes:

  • du hörst auf zu denken „wieder Pech gehabt“ und siehst ein vorhersehbares Muster;
  • du zahlst nicht fünfmal für denselben Bug (jede Korrektur sind deine Tokens und Nerven);
  • du bekommst eine Seite, die nicht bei jeder neuen Bitte auseinanderfällt;
  • du kannst dem Agenten den Zauberspruch sagen - „schreib einen Test auf diesen Bug“ - und ruhig schlafen.

Der Unterschied zwischen „die KI macht mir ständig was kaputt“ und „die KI macht mir das nicht mehr kaputt“ - das ist ein kleiner automatischer Test, im richtigen Moment geschrieben.

Die größte Falle: Die KI prüft sich selbst

Gehen wir das Schritt für Schritt durch - wie das live aussieht. Das ist keine Schauergeschichte. So wurde der Bug viermal hintereinander gefixt, in einem echten Projekt:

  1. Die KI hat ein neues Feld in die Server-Antwort gepackt - aber vergessen, es aus der Datenbank zu holen. Selbst geprüft, nichts gemerkt.
  2. Aus der Datenbank geholt - ein anderer Fehler tauchte auf, bei den Typen. Wieder Schritt 1 geprüft, das neue Unheil übersehen.
  3. Korrigiert - aber nur den echten Modus gefixt, den Demo-Modus vergessen. Geprüft - wieder daneben. Vierter Anlauf.
  4. Und erst der Test hat den Fehler sofort gefangen, beim ersten Lauf. Ohne Diskussion und Selbstberuhigung.

Wie man es heilt: Test auf den gefangenen Bug

Die Heilung ist simpel - und ein bisschen kontraintuitiv. Du musst nicht das ganze Projekt mit Tests abdecken - das dauert lange, kostet viel und ist fast nutzlos. Es geht um etwas anderes.

Regression - das ist, wenn schon Gefixtes wieder kaputtgeht. Und die wichtigste Regel lautet so:

Schreib einen Test nicht auf Code, der funktioniert, sondern auf den Bug, den du schon gefunden hast.

Automatischer Test - das ist ein Wächter. Du stellst ihn genau an die Tür, durch die schon einmal jemand eingestiegen ist. Einmal geschrieben - und dieser konkrete Bug kann physisch nicht zurückkommen: Bei der nächsten Änderung schreit der Wächter sofort durchs ganze Haus.

Ein kleiner Wächter-Roboter mit Taschenlampe steht an einer Tür, auf der steht „diesen Bug haben wir schon gefangen“
Der Test ist ein Wächter an genau der Tür, durch die der Bug letztes Mal reinkam.

Die häufigste Wiederholung: eins gefixt, das zweite vergessen

In diesem echten Projekt waren 3 von 4 Bugs derselben Sorte. Im Code gibt es zwei Pfade: den echten (mit echten Daten) und das Demo (mit Beispieldaten, um die Seite schnell zu zeigen). Die KI fixt den einen Pfad und vergisst den zweiten komplett. Klassiker. Wie die zweite Socke vergessen.

Wie es sein sollte
  • Beide Modi liefern denselben Datensatz - der echte und das Demo.
  • Ein Feld an einer Stelle angepasst - sofort die zweite geprüft.
  • Es gibt einen Test, der vergleicht: im Demo dieselben Felder wie im echten Modus.
Wie die KI es kaputtmacht
  • Ein Feld nur in den echten Pfad gepackt, das Demo blieb alt.
  • Eine neue Spalte in die Antwort eingebaut, aber vergessen, sie aus der Datenbank zu holen - und sie bleibt immer leer.
  • Bei einem Fehler eine Meldung gezeigt, aber die alten Daten nicht vom Bildschirm entfernt - es kam Chaos raus.

Beispiel aus dem Leben: Benachrichtigungseinstellungen

Du baust mit der KI eine Buchungs-Seite. Du bittest: „füg ins Profil Benachrichtigungseinstellungen ein“. Sie fügt sie ein, meldet munter „fertig“. Du öffnest es - leer. Du bittest um Fix - gefixt, wieder leer. Und so im Kreis. Du kochst schon und denkst, die KI sei endgültig kaputt.

In Wahrheit ist alles einfacher. Die KI fixt ein Stück und macht das Nachbarstück kaputt - und sieht es selbst nicht. Sie prüft mit demselben Kopf, der auch geschrieben hat.

Ein erfahrener Vibecoder bittet hier nicht zum sechsten Mal „fix es nochmal“. Er bittet darum, einen Wächter aufzustellen:

Prompt - kopier ihn und probier es aus

Dieser Bug kommt schon mehrfach zurück: Die Benachrichtigungseinstellungen sind mal in der Profil-Antwort da, mal verschwinden sie.

Mach es strikt in dieser Reihenfolge:

  1. Schreib zuerst einen kleinen automatischen Test, der prüft, dass in der Profil-Antwort das Feld für die Benachrichtigungseinstellungen vorhanden und nicht leer ist. Benenn den Test nach dem Bug.
  2. Lass den Test laufen. Er muss durchfallen - das beweist, dass der Bug echt ist und nicht erfunden.
  3. Jetzt fix den Bug. Wichtig: Prüf BEIDE Modi - den echten und das Demo. Sie müssen denselben Satz an Feldern liefern.
  4. Lass den Test erneut laufen. Jetzt muss er bestehen.
  5. Bevor du „fertig“ sagst - lass alle Tests komplett durchlaufen, um sicherzugehen, dass du nichts Benachbartes kaputtgemacht hast.

Checkliste: wirklich prüfen, nicht aufs Wort glauben

Die KI verkündet fröhlich „alles läuft, ich hab geprüft“? Glaub ihr nicht aufs Wort. Bitte sie, der Reihe nach vorzugehen: zuerst die Maschine, dann die Augen.

  1. Zuerst Tests laufen lassen. Durchgefallen - das ist Bug Nummer eins, ohne jede Diskussion. Die Maschine streitet nicht.
  2. Dann den Build prüfen. Der Code lässt sich gar nicht bauen - das ist wichtiger als jede schöne Meinung.
  3. Und erst jetzt - Code-Review mit eigenen Augen, die bekannten blinden Flecken im Kopf (zwei Pfade, vergessene Felder).
  4. Auf jeden gefundenen Bug - ein neuer Test. Damit es beim nächsten Mal von selbst gefangen wird, ohne dich.
Meme: Die KI sagt mit stolzem Gesicht „ich hab alles geprüft, sieht richtig aus“, und im Hintergrund brennt derselbe Bug
Klassiker. Mit demselben Kopf geprüft, mit dem auch geschrieben wurde.

Häufige Anfängerfehler

  • „Ich hab geprüft, alles läuft“ glauben. Derselbe Kopf, dieselben blinden Flecken. Bitte um einen Testlauf.
  • Im Kreis „fix es nochmal“ bitten. Ohne Wächter kommt der Bug ein sechstes Mal zurück. Bitte um einen Test auf den Bug.
  • Das ganze Projekt mit Tests abdecken. Langwierig und nutzlos. Ein Test gehört dorthin, wo wirklich was kaputtging.
  • Den zweiten Pfad vergessen. Den echten Modus gefixt - bitte sofort, auch den Demo-Modus zu prüfen.
  • Code-Review vor dem Testlauf machen. Zuerst die seelenlose Maschine, dann die Meinung der KI. Nicht umgekehrt.
  • Den Test nach dem Fix schreiben und es dann schleifen lassen. Besser zuerst der Test (er fällt durch), dann der Fix (der Test besteht).

TL;DR - если коротко

  • Die KI schreibt Code und prüft ihn selbst - mit einem Kopf, mit denselben blinden Flecken. Ihren eigenen Fehler sieht sie nicht.
  • Die häufigste Wiederholung: einen Pfad gefixt, den zweiten vergessen. Der echte Modus läuft, das Demo ist vergessen.
  • Das Heilmittel - ein Test auf genau den Bug, den du schon gefunden hast. Einmal geschrieben - und der Bug kann physisch nicht zurückkommen.
  • Pack nicht alles wahllos in Tests. Stell einen Wächter dorthin, wo wirklich was kaputtging.
  • Zuerst Tests laufen lassen, dann Code mit eigenen Augen reviewen. Die Maschine fängt still, ohne Diskussion.
  • Willst du ruhig schlafen - sag dem Agenten den Zauberspruch: „schreib einen Test auf diesen Bug“.

Wiki durchsuchen

Esc zum Schließen drücken

Geben Sie einen Suchbegriff ein, um alle Lektionen und Kurse zu durchsuchen.