Wie Sie KI-generierten Code verifizieren, bevor Sie ihn mergen

Das Problem beim Review von Code, den man nicht selbst geschrieben hat

Ein KI-Coding-Agent kann ein funktionierendes Feature in Minuten liefern. Der Engpass hat sich verschoben: Die Einschränkung ist nicht mehr, wie schnell Code geschrieben wird, sondern wie sicher irgendjemand sagen kann, dass der Code tut, was er tun sollte. Einen großen Diff sorgfältig zu lesen dauert länger, als ihn zu erzeugen.

Typprüfungen und Unit-Tests bestätigen, dass der Code das tut, wofür er geschrieben wurde. Sie können Ihnen nicht sagen, ob die deployte Anwendung noch funktioniert, weil sie nie eine öffnen. Genau in dieser Lücke leben die tatsächlichen KI-generierten Regressionen.

Die Schleife, in drei Befehlen

Installieren Sie die Open-Source-TestSprite-CLI — kostenlos, Apache-2.0, Node 20.19+, 22.13+ oder 24+:

npm install -g @testsprite/testsprite-cli
testsprite setup

Dann die Schleife. Beschreiben Sie das Verhalten, das garantiert sein soll, führen Sie es gegen einen echten Browser aus und lesen Sie das Urteil aus dem Exit-Code:

# 1 — Test erstellen und ausführen
testsprite test create --project prj_abc123 --type frontend \
  --plan-from ./checkout-flow.plan.json --run --wait --output json
#   → exit 1: der Lauf ist fehlgeschlagen

# 2 — EIN in sich konsistentes Failure-Bundle abrufen
testsprite test failure get test_3a9f21c7 --out ./.testsprite/failure

# 3 — den Code beheben, dann denselben Test erneut abspielen
testsprite test rerun test_3a9f21c7 --wait --output json
#   → exit 0: bestanden

Das Bundle in Schritt zwei ist der Teil, der zählt. Es enthält den fehlgeschlagenen Schritt, dessen Nachbarschritte, Screenshots, DOM-Snapshots, den Testquellcode, eine Ursachenhypothese und ein empfohlenes Fix-Ziel — alle mit derselben Snapshot-ID versehen. Die CLI weigert sich, Daten aus zwei verschiedenen Läufen zu kombinieren, sodass ein Agent nie über einen Kontext nachdenkt, der aus zwei unterschiedlichen Zuständen der Anwendung zusammengesetzt ist.

Warum eine dauerhafte Suite ein größeres Kontextfenster schlägt

Jeder bestandene Test wird gesichert. Wenn der Agent das nächste Mal die Codebasis anfasst, wird diese Anforderung immer noch geprüft — egal ob sie irgendwo in der aktuellen Konversation auftaucht oder nicht.

Das ist das strukturelle Argument für externe Verifikation. Ein Kontextfenster enthält, worüber der Agent gerade nachdenkt. Eine Testsuite enthält jede Anforderung, die das Projekt jemals richtig erfüllt hat, und sie hält diese über Sitzungen hinweg, über Agenten hinweg und über Monate hinweg fest, in denen sich niemand mehr erinnert, warum ein bestimmter Grenzfall wichtig war.

Richten Sie Ihren Agenten so ein, dass er das selbst tut

Sie sollten Befehle nicht zwischen einer Webseite und Ihrem Coding-Agenten hin- und herreichen müssen. Ein Setup-Befehl installiert eine Skill-Datei im Repository, die die Schleife in der Form beschreibt, die ein Agent tatsächlich verarbeitet:

TESTSPRITE_API_KEY=sk-... testsprite setup --from-env --yes --agent claude

Unterstützte Umgebungen sind claude, codex, cursor, cline, antigravity, kiro, windsurf und copilot. Die Installation ist rein lokal. Danach weiß der Agent, wie man Tests erstellt, ausführt und triagiert, ohne dass es ihm in jeder Sitzung erneut gesagt werden muss.

Bevor Sie einen Zug auf einen Befehl verschwenden, der aus Umgebungsgründen fehlschlagen wird, prüfen Sie die Umgebung:

testsprite doctor    # CLI- und Node-Versionen, Profil, Zugangsdaten, Konnektivität

Was zuerst verifiziert werden sollte

Nicht alles verdient einen End-to-End-Test. In einer Codebasis, die sich unter einem KI-Agenten schnell ändert, ist die wertvollste Abdeckung schmal:

1. Die Abläufe, die Umsatz erzeugen. Sign-up, Checkout und Abrechnung. Eine Regression kostet hier sofort Geld und ist in Unit-Tests häufig unsichtbar.

2. Alles rund um Authentifizierung. Session-Handling, Weiterleitungen nach dem Login und Berechtigungsgrenzen sind dort, wo ein plausibel aussehendes Refactoring den größten Schaden anrichtet.

3. Formulare und Validierung. Günstig zu beschreiben, überproportional anfällig, kaputtzugehen, wenn eine Komponentenbibliothek aktualisiert oder ein Feld umbenannt wird.

4. Die letzten drei Bugs, die Sie ausgeliefert haben. Ein Regressionstest, der nach einem Fix geschrieben wird, ist der ertragreichste Test in jeder Suite.

Wenn Sie sich lieber die erste Auswahl vorschlagen lassen möchten, kann die Exploration Vorschläge entwerfen. Vorschläge werden zur Prüfung bereitgestellt, und nichts wird auf Ihre Festplatte geschrieben, bis Sie zustimmen:

testsprite test plan generate --project prj_abc123
testsprite test plan accept --project prj_abc123           # alle davon
testsprite test plan accept --project prj_abc123 --only prop_2 prop_5

Den Check verpflichtend machen

Ein Verifikationsschritt, der nur läuft, wenn jemand sich daran erinnert, ihn auszuführen, ist keine Verifikation. Bringen Sie ihn in CI:

testsprite ci init github

Das erstellt .github/workflows/testsprite.yml unter Verwendung von TestSprite/testsprite-action@v1, das den PR-Checks-Tab mit einem Fehler pro Fehlschlag annotiert, dem Job-Summary eine Ergebnistabelle anfügt, einen JUnit-Report hochlädt und — wichtig — den Job bei einem partiellen Lauf fehlschlagen lässt, statt ihn als grün zu melden.

Das ist der Weg, bei dem Ihr Workflow den Lauf steuert. TestSprite installiert sich auch als GitHub App, die auf die Deployment-Events lauscht, die Ihre Pipeline bereits erzeugt, und Ergebnisse als Kommentar auf den Pull Request zurückmeldet, was überhaupt keine Workflow-Datei und keine Repository-Änderungen benötigt.

In jedem anderen CI-System braucht die CLI nur einen API-Schlüssel in der Umgebung:

export TESTSPRITE_API_KEY="$TESTSPRITE_API_KEY"
testsprite test run --all --project prj_abc123 --wait \
  --report junit --report-file testsprite-junit.xml \
  --summary-file testsprite-summary.json

Exit-Codes, auf die es sich zu verzweigen lohnt

Die Codes 129, 130 und 143 bedeuten, dass der Prozess durch ein Signal unterbrochen wurde (128 plus die Signalnummer), nicht dass ein Test fehlgeschlagen ist — das lohnt sich zu unterscheiden, bevor man einen Lauf als kaputt meldet.

Häufig gestellte Fragen