KI-generierten Code testen: Warum die schreibende AI nicht prüfen sollte
AI Coding macht Entwicklung schneller. Aber wenn derselbe Agent Code schreibt und die Tests passend dazu korrigiert, entsteht schnell grüne Unsicherheit.
Dieser Artikel basiert auf einer Entwicklernotiz aus meinem LinkedIn-Feed. Die These ist bewusst spitz: AI kann Code schreiben und AI kann testen. Nur sollte es nicht derselbe Arbeitsgang sein. Originalpost auf LinkedIn.
„AI kann das nicht!“ Dann lass eine andere AI prüfen.
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.
Zwei Beispiele aus der Praxis
Der unnötige Test
Eine Datenbanktabelle wurde erweitert. Ein Titel kam dazu. Gleichzeitig wurde ein Test geschrieben, der prüft, ob dieser Titel in der SQL-Abfrage abgefragt werden kann. Der Test war grün. Er war auch fast wertlos.
So ein Test gibt ein gutes Gefühl, aber keine echte Sicherheit. Er bestätigt vor allem, dass die Implementierung so aussieht, wie sie gerade gebaut wurde.
Der gefährliche Test-Fix
Die Aufgabe war, einen Status in Feature A einzubauen. Verstanden wurde: Der Status in Feature B ist überflüssig. Also wurde er entfernt. Die Tests schlugen an, wie sie sollten.
Dann kam der eigentliche Schaden: Die Tests wurden angepasst, weil der Agent auf ein fertiges Ergebnis hinarbeitete. Aus einem Warnsignal wurde ein grünes Häkchen.
Coden und Prüfen sind gegensätzliche Modi
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.
Der bessere Workflow: trennen, prüfen, dann zurückgeben
Meine Regel ist inzwischen simpel: Der Feature-Agent darf nicht frei Tests schreiben oder anpassen, nur damit der Lauf wieder grün wird. Tests gehören in einen eigenen Loop.
- Feature-Entwicklung und Test-Änderungen getrennt betrachten.
- Test-Diffs strenger reviewen als normale Code-Diffs.
- Fehlgeschlagene Tests zuerst als Signal behandeln, nicht als Aufgabenliste zum Wegpatchen.
- Browser-Funktionen in einem echten Browser prüfen, statt nur Code und Snapshots zu lesen.
Wo QAgent in diesen Loop passt
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.
# Beispiel: Browser-Check aus einem AI-Coding-Loop
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.
Was das für PMs und Teams bedeutet
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.
Häufige Fragen
- Sollte AI Tests für ihren eigenen Code schreiben?
- Sie kann Tests vorschlagen. Kritisch wird es, wenn derselbe Workflow Code baut und Tests so anpasst, dass das Ergebnis grün wird. Für verlässliche QA braucht es einen separaten Prüf-Loop.
- Wie teste ich KI-generierten Code im Browser?
- Ein unabhängiger Check sollte die Seite öffnen, den erwarteten Ablauf ausführen und ein PASS/FAIL mit Belegen liefern. Genau dafür ist QAgent gebaut.
- Ersetzt QAgent Playwright?
- Nein. Playwright bleibt sinnvoll für Regressionstests. QAgent sitzt im schnellen Entwicklungsloop: Ziel formulieren, Browser prüfen lassen, Ergebnis an den Coding-Agent zurückgeben.