- Ein AI-Agent zum Schreiben von Code erzeugt Code und übernimmt Änderungen in den Branch, selbst während Entwickler schlafen, aber die Überprüfung von Genauigkeit und Verlässlichkeit der Ergebnisse ist schwierig
- Wenn dieselbe AI den von ihr geschriebenen Code auch testet, wird sie zur „Selbstbejubelungsmaschine“ und erkennt Missverständnisse gegenüber der ursprünglichen Absicht nicht
- In Anlehnung an das Kernprinzip von TDD werden Akzeptanzkriterien zuerst vor dem Schreiben des Codes formuliert, und der Agent implementiert danach anhand dieser Kriterien und führt eine separate Verifikation durch
- Als Verifikationswerkzeug wurde eine 4-stufige Pipeline aufgebaut, die den Headless-Modus von Claude Code (claude -p) mit Playwright MCP kombiniert; ein separates Backend ist nicht nötig
- Um den Ergebnissen eines Agenten zu vertrauen, muss die Definition von „fertig“ vor Arbeitsbeginn klar festgelegt werden; das ist schwieriger als Prompting, aber ein unverzichtbarer Prozess
Das Problem der Code-Verifikation bei autonomen Agenten
- Mit AI-Tools wie Gastown können Agenten stundenlang Code schreiben und Änderungen in einen Branch übernehmen, aber es gibt keine verlässliche Methode zu prüfen, ob das Ergebnis tatsächlich korrekt ist
- Aus Workshops zu Claude Code mit mehr als 100 Engineers in den vergangenen 6 Monaten zeigte sich in allen Teams dasselbe Problem
- Teams, die Claude für alltägliche PRs nutzen, steigerten ihre gemergten PRs pro Woche von 10 auf 40–50 und verbringen dadurch deutlich mehr Zeit mit Code-Reviews
- Je autonomer das System arbeitet, desto stärker verschärft sich das Problem – irgendwann wird nicht mehr der Diff geprüft, sondern nur noch beobachtet, ob das Deployment hoffentlich ohne Probleme läuft, und Fehler werden erst nach dem Rollout entdeckt
Grenzen bisheriger Lösungen
- Zusätzliche Reviewer einzustellen hält mit dem Tempo nicht Schritt, und es ist ineffizient, wenn Senior Engineers den ganzen Tag AI-generierten Code lesen
- Wenn Claude Tests für den von ihm selbst geschriebenen Code erstellt, prüft es nicht das, was der Nutzer tatsächlich wollte, sondern was Claude für gewollt hielt
- Regressionsfehler lassen sich finden, aber das ursprüngliche Missverständnis (misunderstanding) nicht
- Wenn dieselbe AI sowohl Schreiben als auch Verifikation übernimmt, entsteht eine „Selbstbejubelungsmaschine (self-congratulation machine)“
- Der eigentliche Zweck von Code-Review ist ein zweiter Blick, der nicht vom ursprünglichen Autor stammt; eine gegenseitige AI-Prüfung stammt jedoch aus derselben Quelle und übersieht daher dieselben Dinge
Was TDD im Kern richtig erkannt hat
- Das Prinzip von TDD: Zuerst Tests schreiben, dann Code schreiben und aufhören, sobald die Tests bestehen (nichts weiter implementieren)
- Der Grund, warum die meisten Teams kein TDD machen, ist, dass es Zeit kostet, im Voraus darüber nachzudenken, was der Code tun soll
- AI löst das Geschwindigkeitsproblem, also fällt diese Ausrede weg — der langsame Teil ist nun, zu beurteilen, ob der Code korrekt ist
- Statt Unit-Tests ist es einfacher, in Klartext zu beschreiben, was die Funktion tun soll
- Beispiel: „Benutzer authentifiziert sich mit E-Mail und Passwort. Bei falschen Zugangsdaten wird 'Invalid email or password' angezeigt. Bei Erfolg Weiterleitung zu /dashboard. Das Session-Token läuft nach 24 Stunden ab.“
- Diese Kriterien lassen sich schreiben, bevor der Code-Editor überhaupt geöffnet wird; der Agent implementiert sie, und etwas anderes verifiziert sie
Praktische Anwendungsfälle
-
Frontend-Änderungen
- Auf Basis einer Spec-Datei werden Akzeptanzkriterien (Acceptance Criteria) erstellt
- AC-1: Bei Aufruf von /login mit gültigen Zugangsdaten Weiterleitung zu /dashboard und Setzen eines Session-Cookies
- AC-2: Bei Eingabe eines falschen Passworts wird exakt „Invalid email or password“ angezeigt, und die Seite /login bleibt bestehen
- AC-3: Wenn Felder leer sind, ist der Submit-Button deaktiviert oder es wird ein Inline-Fehler angezeigt
- AC-4: Nach 5 Fehlversuchen wird der Login für 60 Sekunden gesperrt und eine Wartezeit-Nachricht angezeigt
- Jedes Kriterium lässt sich eindeutig als bestanden oder nicht bestanden bewerten
- Nachdem der Agent die Funktion gebaut hat, führt ein Playwright-Browser-Agent für jedes AC die Verifikation aus, erstellt Screenshots und erzeugt einen Bericht mit der Bewertung je Kriterium
- Bei Fehlern ist genau erkennbar, welches Kriterium fehlgeschlagen ist und was im Browser zu sehen war
-
Backend-Änderungen
- Dasselbe Muster lässt sich ohne Browser anwenden
- Es werden beobachtbare API-Verhalten (Statuscodes, Response-Header, Fehlermeldungen) festgelegt und mit curl-Befehlen verifiziert
-
Grenzen
- Missverständnisse in der Spec selbst lassen sich nicht auffangen — wenn die Spec von Anfang an falsch ist, kann die Verifikation bestehen und die Funktion trotzdem falsch sein
- Was Playwright erkennt: Integrationsfehler, Rendering-Bugs und Verhalten, das in echten Browsern kaputtgeht
- Das ist ein engerer Anspruch als „verifizierte Korrektheit“, erfasst aber mehr als das, was Code-Review typischerweise zuverlässig findet
-
Workflow-Zusammenfassung
- Akzeptanzkriterien vor dem Prompt schreiben → Agent implementiert anhand der Kriterien → Verifikation ausführen → nur fehlgeschlagene Punkte reviewen (Review von Fehlern statt vom Diff)
Aufbau: 4-stufige Pipeline
- Implementiert als Claude Skill (github.com/opslane/verify) mit claude -p (Headless-Modus von Claude Code) und Playwright MCP
- Kein separates Custom-Backend und keine zusätzlichen API-Keys nötig, nur das vorhandene Claude-OAuth-Token wird verwendet
-
Schritt 1: Pre-flight
- Reines bash, kein LLM-Aufruf
- Prüft, ob der Dev-Server läuft, ob die Auth-Session gültig ist und ob die Spec-Datei vorhanden ist
- Schnelles Fail-fast, bevor Tokens verbraucht werden
-
Schritt 2: Planner
- Einmaliger Opus-Aufruf
- Liest die Spec und die geänderten Dateien und entscheidet, was für jede Verifikation nötig ist und wie sie ausgeführt wird
- Liest den Code, um die richtigen Selektoren zu finden, statt Klassennamen zu erraten
-
Schritt 3: Browser Agents
- Ein Sonnet-Aufruf pro AC, alle parallel ausgeführt
- Bei 5 ACs navigieren und fotografieren 5 Agenten unabhängig voneinander
- Sonnet ist im Vergleich zu Opus 3–4-mal günstiger und bei klickbasierten Aufgaben gleich leistungsfähig
-
Schritt 4: Judge
- Ein letzter Opus-Aufruf liest alle Belege und gibt je Kriterium ein Urteil zurück: pass, fail oder needs-human-review
-
Installation
- Kann als Claude-Code-Plugin installiert werden:
/plugin marketplace add opslane/verify
- Alternativ kann das Repo geklont und angepasst werden — jeder Schritt besteht aus einem einzelnen claude -p-Aufruf mit klaren Eingaben und strukturierten Ausgaben
- Modellwechsel, zusätzliche Schritte und CI-Integration mit der Option --dangerously-skip-permissions sind möglich
Zentrale Erkenntnis
- Entscheidend ist: „Wenn die Definition von fertig nicht im Voraus festgelegt wird, kann man dem Ergebnis nicht vertrauen.“
- Das Schreiben von Akzeptanzkriterien ist schwieriger als Prompting, erhöht aber die Qualität, weil Edge Cases vorab durchdacht werden
- Engineers wehren sich aus demselben Grund wie früher gegen TDD: Es fühlt sich am Anfang langsamer an
- Ohne Akzeptanzkriterien bleibt nur, das Ergebnis zu lesen und zu hoffen, dass es korrekt ist
- Das ist ein unverzichtbarer Prozess, um Verlässlichkeit in einer AI-getriebenen Entwicklungsumgebung sicherzustellen
2 Kommentare
So viel TDD man auch betreibt – auf dem aktuellen Stand, bei dem das LLM Tests manipuliert, damit sie bestanden werden, ist menschliches Review unbedingt nötig..
Hacker-News-Kommentare
Ich habe das Gefühl, dass die aktuellen LLM-Frameworks die Entwicklung eher schwieriger und teurer machen
Mit den Standardeinstellungen kommt man schon ziemlich weit, und in einer Situation, in der sich die Modelle ständig ändern, halte ich es für ineffizient, unzählige Wrapper und Harnesses zu bauen
Diese Art, etwas über Nacht laufen zu lassen und dabei Geld zu verbrennen, wird später wohl wie das PHP-Meme als Witz in Erinnerung bleiben
Laut dem Artikel hat er „in den letzten sechs Monaten Workshops zu Claude Code für mehr als 100 Ingenieure durchgeführt“
Wenn sie Tag und Nacht laufen, am Ende die AI-Firma pleitegeht und nur noch zu 80 % von AI geschriebener Spaghetti-Code übrig bleibt, wird man sehen, wer zuletzt lacht
Ich habe das Gefühl, dass manches, was ich vor 15 Jahren mit PHP gebaut habe, besser war als die heutigen Full-Stack-JS/TS-Umgebungen
PHP lebt noch immer und entwickelt sich weiter. Mit LLM-Tooling wird es am Ende ähnlich laufen und es wird einfach zu einem Basiswerkzeug werden
Die Grenzen zwischen BA, PO, QA und SWE verschwimmen. Es entstehen jetzt hybride Rollen, die zwischen Business und Entwicklung liegen
Es wirkt, als wollten die Leute heutzutage einfach nur Agenten einsetzen
Ich lasse nur zwei laufen, einen fürs Schreiben und einen fürs Review, und selbst damit sind 5- bis 7-fache Produktivitätsgewinne locker drin
Ich investiere mehr Zeit in die Prüfung der Spezifikation, und das Coding erledigt der Agent in 10 bis 30 Minuten, also gibt es keinen Grund zur Eile
Morgen gibt es auch noch Arbeit, deshalb sehe ich keinen Grund, ihn die ganze Nacht laufen zu lassen
Aus Kundensicht macht es keinen großen Unterschied, ob ein Bug aus Indien, San Francisco oder von einer AI kommt
Das ist viel kontrollierter als die derzeit populäre „Agent-Orchestrierung“
Deshalb habe ich selbst den verify skill gebaut, um zu prüfen, ob Claude die Spezifikation sauber befolgt
Wenn man Claude das Red-Green-Refactor-Muster verwenden lässt, steigt die Qualität der Tests deutlich
Noch besser funktioniert es, wenn man Red/Green/Refactor-Subagenten erstellt, die sich gegenseitig überprüfen
Der Kernpunkt ist, den Kontext nicht zu vermischen
Reward Hacking existiert tatsächlich und ist schwer abzuwehren
Selbst mit diesem Leitfaden bleibt das Problem schlechter Tests groß
Die Ergebnisse waren gut genug, dass ich Prinzipien und Beispiele sowie ein Starter-Repo veröffentlicht habe
Wichtig ist die Trennung zwischen Autor und Prüfer; selbst beim gleichen Modell steigt die Qualität, wenn der Kontext getrennt bleibt
Wegen der aktuellen Kontextgrenzen von LLMs sind echte Agenten derzeit noch nicht möglich
Bei Code mit mehr als 500 Zeilen steigt die Fehlerzahl stark an, und die praktische Grenze liegt eher bei rund 200 Zeilen
Letztlich ist ein LLM nur ein Werkzeug, das man wie einen Taschenrechner wiederholt einsetzen muss
Ich nenne dieses Phänomen „Test Theatre“
Ich habe hier darüber geschrieben. Man sollte es aktiv vermeiden
Gute Tests sollten Entwurfsmuster und Abhängigkeiten validieren und beim Debugging helfen
Mit Schemathesis lasse ich zum Beispiel automatisch Benutzerrechte oder das Auftreten von 5xx-Antworten prüfen
Ein entsprechendes POC habe ich hier veröffentlicht
Ich experimentiere derzeit mit Agent-Orchestrierung
Der Kern besteht darin, LLM-Aufrufe zu reduzieren und sie über eine deterministische Skript-Pipeline zu verbinden
Mehr Details stehen in diesem Beitrag
Wie in diesem Experimentbericht stehen eher Skripte als das LLM im Mittelpunkt
Ich lasse sechs Agenten für den Geschäftsbetrieb laufen
Sie übernehmen unterschiedliche Rollen wie Marktrecherche, Content-Erstellung und Videoskripte
„Über Nacht laufen lassen“ ist ein übertriebenes Konzept; in der Praxis sind klare Ziele und ein enger Umfang wirksamer
Der echte Engpass ist nicht die Ausführung, sondern das Kontextmanagement
Ich weiß nicht, was diese Person eigentlich konkret baut
Auf LinkedIn sehe ich nur Beiträge über Claude
Für ein seriöses Unternehmen wäre so etwas unvorstellbar
Am Ende liegt der Code nur herum, während man darüber nachdenkt, wie man ihn verkaufen soll
Das ist dasselbe Problem, wie wenn man jemanden einstellt, der nur Tests schreibt
Am Ende bestätigt man nur, dass „der Code sich so verhält wie der Code“
Eine klare Definition der Spezifikation ist viel wichtiger
Erstaunlich, dass andere Ingenieurdisziplinen diesen Fehler nicht ständig wiederholen, während Software das besonders häufig tut
Selbst wenn die erste Version falsch war, stellen sie sicher, dass sich das Verhalten danach nicht unbemerkt ändert
Viele Beratungsunternehmen arbeiten mit Validierung auf Basis von Acceptance Criteria
Die heutige AI ist nicht mehr nur ein Werkzeug zur Unterstützung der Entwicklung, sondern hat ein Niveau erreicht, auf dem sie Entwickler ersetzt
Dass wir den Code nicht mehr kontrollieren oder validieren können, ist ein ernstes Problem
Das wirkt nicht wie eine neue Art der Entwicklung, sondern eher wie ein religiöser Wandel, der Verständnis durch Vertrauen ersetzt
Auch wenn die Autonomie geringer ist, merge ich nur Code, den ich validieren kann