Check vor dem Launch: Der Verifikations-Loop des Agenten

Was „Check vor dem Launch“ bedeutet, einfach erklärt

Stell dir vor: Ein Kumpel schickt dir ein Foto von einer Torte. Glatt, glänzend, Kerzen brennen. „Fertig, hau rein!“ Du kommst an - und drinnen ist roher Teig. Außen sieht’s halt top aus. Nur hat keiner mit dem Zahnstocher reingestochen.

Genau dieses „fertig“ vom KI-Agenten ist exakt der Moment, in dem der Zahnstocher noch nicht rausgeholt wurde. Der Agent hat ehrlich gemacht, worum du gebeten hast. Und glaubt aufrichtig, dass alles super ist. Nur hat er es nicht überprüft. Bis du ihn darum gebeten hast.

Warum ein Vibecoder das Ergebnis des Agenten überprüfen sollte

Du bist Vibecoder. Du liest den Code nicht Zeile für Zeile - und das ist okay. Aber genau deshalb brauchst du einen Weg, das Ergebnis zu überprüfen, ohne den Code zu lesen. Der Check-Loop ist genau dieser Weg. Wenn du ihn drauf hast, kriegst du gleich mehrere Goodies:

• du hörst auf, Seiten online zu stellen, die beim allerersten Klick kaputtgehen;
• du fängst den Fehler, solange er klein ist - und nicht erst, wenn Freunde schreiben „bei dir ist da alles weiß“;
• du lernst, „der Agent denkt, er hat’s gemacht“ von „läuft wirklich“ zu unterscheiden;
• du schläfst ruhig. Weil du einen grünen Report in der Hand hast und nicht nur den Glauben ans Beste.

Zwischen „ich hab die Seite hochgeladen“ und „ich hab eine funktionierende Seite hochgeladen“ liegt ein einziger Check-Durchlauf. Zehn Minuten, die dir einen ganzen Abend voller Peinlichkeit sparen.

Wie der Verifikations-Loop (verification loop) bei Claude funktioniert

Ein vernünftiger Agent hat eine eingebaute Angewohnheit - die Verifikation Verifikation (verification) - die Überprüfung, dass das Gemachte wirklich funktioniert: es baut, es läuft, es besteht die Tests. Nicht „ich glaube, passt“, sondern „ich hab's geprüft, hier ist der Beweis“. . Keine Magie. Und kein einzelner Wundertest. Es ist eine Checkliste nach Phasen, die der Agent von oben nach unten durchgeht. Gehen wir sie mal ganz menschlich durch.

Schritt 1. Build des Projekts - baut das Ding überhaupt?

Die erste und wichtigste Frage: Lässt sich das Projekt zu einer fertigen Seite bauen - oder schmiert der Build mit einem Fehler ab? Das ist, als würdest du checken, ob aus den Zutaten eine Torte geworden ist und nicht eine Pfütze auf dem Backblech.

Schritt 2. Typencheck - passen alle Teile zusammen?

Als Nächstes der Typencheck Typencheck (type check) - eine automatische Kontrolle, dass die Daten zusammenpassen: eine Zahl dahin, wo eine Zahl erwartet wird, Text dahin, wo Text erwartet wird. Fängt einen Haufen dummer Fehler schon vor dem Start ab. . Einfach gesagt: die Kontrolle „passt Schräubchen A wirklich in Loch A und ist nicht schief mit dem Hammer reingekloppt“. Die Maschine läuft selbst das Projekt durch und zeigt, wo etwas nicht zusammenpasst. Kritische Fehler reparieren wir sofort. Nicht aufschieben.

Schritt 3. Linter - der pingelige Nachbar-Perfektionist

Der Linter Linter (linter) - eine automatische Prüfung von Stil und Sauberkeit des Codes. Bricht die Seite nicht, fängt aber Müll, Tippfehler und verdächtige Stellen ab. ist ein penibler Nachbar. Er geht durch die Wohnung und murrt: hier ist’s staubig, hier hängt’s schief, hier hast du die Glühbirne vergessen reinzudrehen. Von seinem Gemecker geht die Seite nicht kaputt. Dafür schafft er Ordnung - und fängt nebenbei oft echte Bugs ab.

Schritt 4. Tests - jemand drückt für dich alle Knöpfe

Tests Tests - kleine automatische Prüfungen: „drück hier - dann sollte Folgendes passieren“. Laufen in Sekunden durch und zeigen, dass nicht das kaputtgegangen ist, was vorher lief. sind ein Roboter, der statt dir auf alle Knöpfe drückt und abgleicht: tun sie das, was sie sollen, oder nicht. Der Agent startet sie und meldet ehrlich: wie viele Tests es insgesamt gibt, wie viele durchgegangen sind, wie viele abgeschmiert sind.

Schritt 5. Sicherheit - hast du die Schlüssel nicht im Schloss stecken lassen?

Hier sucht der Agent das, was niemals in öffentlichen Code geraten darf: Passwörter, geheime Schlüssel, Access-Tokens. Das ist, als würdest du checken, ob du nicht die Wohnungsschlüssel unter die Fußmatte mit der Aufschrift „SCHLÜSSEL HIER“ gelegt hast. Und nebenbei räumt er vergessene „Schreie in die Konsole“ zum Debuggen weg.

Schritt 6. Änderungen ansehen - was hat sich überhaupt geändert

Das Finale: Der Agent schaut sich die Liste von dem an, was er wirklich angefasst hat. Welche Dateien sich geändert haben, wie viele Zeilen. Genau hier tauchen die Überraschungen auf. „Ups, ich hab die falsche Datei umgeschrieben.“ Oder „warum haben sich 40 Dateien geändert - ich wollte doch nur einen Button anpassen?“

Wie ein guter Check-Report aussieht

Am Ende soll der Agent dir einen kurzen Ampel-Report ausgeben. Keine Textwand. So erkennst du auf den ersten Blick einen nützlichen Report von einem leeren.

Beispiel: warum „fertig“ vom Agenten die Seite kaputt macht

Du vibecodest eine Landingpage für deinen Kanal. Der Agent arbeitet eine Stunde lang ohne Pause durch - generiert Formulare, Animationen, Galerie. Und schreibt fröhlich: „Fertig! Die Seite läuft komplett 🎉“. Du stellst sie online, schickst den Link an Freunde - und da ist ein weißer Bildschirm und ein einsamer trauriger Fehler in der Ecke.

Was wirklich passiert ist:

1. Der Agent hat das letzte Feature fertiggeschrieben und das Projekt nicht neu gebaut - der Build ist leise abgeschmiert.
2. Irgendwo „passte das Schräubchen nicht“ (ein Typenfehler), und es war keiner da zum Überprüfen.
3. „Fertig“ hieß „ich hab fertig getippt“. Und nicht „ich hab überprüft, dass es läuft“.

Ein cleverer Vibecoder hätte es anders gemacht. Er hätte dem Agenten vorab verboten, „fertig“ ohne Report auszusprechen:

Wenn du die Aufgabe fertig hast, schreib mir kein „fertig“, bevor du den vollen Check durchgefahren bist und mir den Report gezeigt hast.
Geh die Schritte durch:

Bau das Projekt. Wenn der Build abschmiert - halt an und repariere ihn zuerst, fass Neues vorerst nicht an.
Prüfe Typen und Linter, liste die gefundenen Fehler auf.
Starte die Tests und schreib: wie viele insgesamt, wie viele bestanden, wie viele abgeschmiert.
Prüfe, dass keine Passwörter, Schlüssel und Tokens in den Code geraten sind.
Zeig die Liste der geänderten Dateien.
Gib am Ende einen kurzen Ampel-Report zu jedem Punkt aus: PASS oder FAIL. Und ein ehrliches Urteil: bereit zum Veröffentlichen oder nicht. Ist etwas rot - erst reparieren, dann berichten.

Wann du den Check vor dem Launch fahren solltest

Nach jedem Buchstaben mit dem Zahnstocher zu stechen, ist nicht nötig - das ist langsam und teuer in Tokens. Fahr den Check an den Grenzen:

1. Feature fertig - Check gefahren, sichergestellt, dass du Altes nicht angekratzt hast.
2. Vor dem Veröffentlichen - unbedingt. Die letzte Kontrolle, bevor deine Freunde die Seite zu sehen bekommen.
3. Nach einem großen Umbau - der Agent hat viel durchgerüttelt, da ist schnell mal was angekratzt.
4. Wenn etwas „sich komisch verhält“ - der Button lässt sich nicht drücken, das Bild lädt nicht. Der Check zeigt, wo genau.
5. In einer langen Session - alle 10-15 Minuten aktiver Arbeit, damit der Fehler nicht zur Lawine anwächst.

Häufige Anfängerfehler beim Check der Seite

• Dem Wort „fertig“ glauben. Das ist eine Hypothese. Fakt ist nur ein grüner Report nach dem Check.
• Neues auf einem abgeschmierten Build draufbauen. Build rot - alles andere ist sinnlos. Repariere ihn zuerst.
• Nur einmal ganz am Ende prüfen. Da häuft sich ein Berg an Fehlern an, und dann finde mal raus, welcher woher kommt. Fahr ihn an den Grenzen.
• „Tests bestanden“ ohne Zahlen akzeptieren. Wie viele waren’s denn überhaupt? Vielleicht waren’s genau null - dann „sind eben alle durchgegangen“.
• Sicherheit verpennen. Ein einziger vergessener Schlüssel im öffentlichen Code - und finden wird ihn garantiert der Falsche.
• Veröffentlichen, ohne die Seite selbst geöffnet zu haben. Selbst ein grüner Report ersetzt nicht, mit den eigenen Augen in die Live-Seite zu klicken.