KI-generierten Code testen: Warum die schreibende AI nicht prüfen sollte

Meine Entwicklung ist inzwischen fast komplett AI-unterstützt. Copilot, Claude, Pi-Dev, Fusion, verschiedene Modelle und Workflows. Das volle Programm.

Was viele dieser Tools gut können: Code erzeugen, umbauen, Varianten ausprobieren, Fehler direkt reparieren. Was sie in meinem Alltag deutlich schlechter können: sinnvolle Tests schreiben, die dem eigenen Ergebnis wirklich widersprechen dürfen.

Test-driven Development gilt oft als Standardantwort auf AI Coding. Ich halte das für zu kurz gedacht. TDD hilft nur, wenn der Test unabhängig genug ist, um dem Code im Zweifel weh zu tun.

Beim Coden geht es um Vorwärtsbewegung: bauen, verbinden, reparieren, weitermachen. Beim Testen geht es um Abstand: Was wurde übersehen? Welche Annahme ist falsch? Was bricht, wenn die Oberfläche anders reagiert als erwartet?

Genau dieser Schritt zurück fehlt in vielen AI-Workflows. Die Modelle sind auf Handlung trainiert. Fehler sehen, Patch schreiben, nächstes Problem. Das ist beim Entwickeln nützlich. In der QA ist es gefährlich.

Wenn dieselbe AI den Code baut und anschließend die Tests „repariert“, kann sie den Fehler verteidigen, den sie gerade eingebaut hat. Nicht mit Absicht. Aber aus dem Workflow heraus.

Für Browser-Checks nutze ich QAgent: ein CLI-Tool, das ein Ziel in natürlicher Sprache nimmt, die Seite im Browser prüft und ein strukturiertes PASS/FAIL mit Belegen zurückgibt.

Mir geht es dabei weniger um ein weiteres Testtool. Wichtig ist die Trennung. Der Coding-Agent baut. Ein separater Verifikations-Loop öffnet den Browser und prüft, ob die Funktion aus Nutzersicht funktioniert.

qagent --url http://localhost:3000 "Kontaktformular absenden und Erfolgsmeldung prüfen"

Das ersetzt keine langlebige Playwright-Suite. Es ist ein schneller Gegencheck während der Entwicklung. Genau dort, wo AI-Coding sonst Kontext verbrennt oder Tests passend zum gerade erzeugten Code biegt.

Der separate Verifikations-Loop endet nicht beim Merge. Beim Deploy treffen KI-generierte Änderungen auf die echte Website – und kein noch so grüner Check davor ersetzt eine Beobachtung danach. Ein Agent kann einen plausiblen Diff bauen, der eine Journey bricht, die er nie durchlaufen hat, oder ein Layout verschiebt, das niemand neu gescreenshotet.

Deshalb ist die Verifikation nach dem Deploy eine eigene Schutzschicht: Nach jeder Änderung öffnet ein synthetischer Monitor die Seite, sendet Formulare ab, läuft die kritischen Journeys durch und vergleicht die Optik mit dem letzten bekannt-guten Zustand. Er läuft außerhalb des Coding-Loops, mit Nutzeraugen und ohne Interesse daran, dass der Diff richtig ist.

Das ist dasselbe Prinzip wie beim separaten QA-Loop, nur eine Stufe später in der Pipeline. Während der Entwicklung gibt ein Browser-Check ein PASS/FAIL an den Coding-Agent zurück. Nach dem Deploy führt das Monitoring dasselbe rund um die Uhr fort – und es erwischt, was der Agent nicht erwischt hat, weil es die Seite prüft und nicht den Code. Die komplette Routine kennen Sie aus dem Guide Website nach jedem Deployment testen.

Schnellere Entwicklung verschiebt das Problem. Wenn Features in Minuten entstehen, wird QA nicht automatisch einfacher. Sie muss unabhängiger werden.

Für PMs heißt das: Akzeptanzkriterien müssen browserfähig formuliert sein. Statt „Status einbauen“ besser: „Nutzer sieht Status X in Feature A, Feature B bleibt unverändert“. Solche Ziele lassen sich prüfen, ohne dass der Prüf-Loop die Implementierung kennen muss.

Für Entwickler heißt es: Der grüne Test ist weniger wert, wenn er aus demselben Loop kommt, der gerade den Code geschrieben hat. Vertrauen entsteht durch Abstand.