80 Prozent Code Coverage waren in jedem Durchlauf Pflicht, und trotzdem war die Coverage am Ende nicht die interessante Zahl. Interessanter war die Rangfolge der fertigen Lösungen: In fünf Testreihen mit je vier Varianten schnitt der TDD-Workflow im Agent Loop nicht besser ab als der Verzicht darauf. Wer KI-gestützte Softwareentwicklung betreibt und seinen Coding-Agenten gerade auf strikte Testdisziplin trainiert, sollte sich die Ergebnisse ansehen. Sie sind klein, zeigen aber in eine unangenehme Richtung.
Der Autor beschreibt das selbst als exploratives Setup, nicht als saubere Evaluation. Statt einer fertigen Antwort liefert er mehrere Hypothesen, an denen sich der eigene Workflow prüfen lässt.
Die Beobachtung, auf die es ankommt, lässt sich mit einer Analogie greifen: Hausbau. Wer ein Haus Zimmer für Zimmer baut und jedes Zimmer passend zum vorherigen anlegt, bekommt am Ende Räume, die alle ineinander übergehen – aber keinen Flur. Niemand hat ihn geplant, weil beim Bauen nie ein Zimmer danach verlangt hat.
Der Aufbau: drei Aufgaben, vier Lösungen pro Runde
Für das Experiment entstanden drei Aufgaben – eine kleine, eine mittlere, eine größere –, alle als Greenfield-Implementierung von Geschäftslogik. Der Autor ließ sich von Claude mehrere Vorschläge machen und achtete darauf, dass die Anforderungen eigenwillig und spezifisch genug waren, um Streuung zwischen den Lösungen zu erzeugen. Sonst reproduzieren Modelle bei Standardaufgaben, was in den Trainingsdaten dominiert – dann misst man nicht den Workflow, sondern die Erinnerung.
Generiert wurde mit Sonnet 4.6. Die Einhaltung des TDD-Workflows bewertete ebenfalls Sonnet 4.6 auf Basis der Session-Transkripte, damit keine Läufe in die Auswertung rutschten, die TDD nur behauptet hatten. Die Qualitätsbewertung übernahm Opus 4.8, und zwar blind: Das Modell bekam die vier Lösungen eines Stapels zu sehen, ohne zu wissen, welche davon mit TDD-Anweisung entstanden waren. Opus baute sich für die Bewertung spontan eine eigene Rubrik und reichte sie an Subagenten weiter.
Diese Blindheit ist der methodisch stärkste Teil des Aufbaus. Der Autor hätte Kriterien für gute Qualität vorgeben können, verzichtete aber bewusst darauf, weil sich ein Modell an jeder vorgegebenen Liste festbeißt. Der Preis dafür ist, dass der Qualitätsbegriff am Ende weitgehend bei Opus lag – ein Vorbehalt, den der Autor selbst nennt.
Die weiteren Einschränkungen: Die Stichprobe ist klein, alle Aufgaben waren Greenfield und eher überschaubar, und kein einziger Lauf hielt TDD perfekt ein. Wer daraus harte Regeln ableitet, überdehnt das Ergebnis.
Wie zuverlässig Agenten TDD überhaupt befolgen
Bevor die Qualitätsfrage Sinn ergab, musste sicherstehen, dass die TDD-Anweisung tatsächlich umgesetzt wurde. Der Autor beschreibt eine lange Vorgeschichte von Enttäuschungen: Agenten schreiben die Implementierung zuerst und die Tests danach, sie überspringen die Bestätigung des roten Schritts, oder sie implementieren so weit voraus, dass der nächste Test sofort grün wird und nie rot war.
Mit einem nachgeschärften Prompt wurde die Einhaltung gut genug, um vergleichen zu können – sauber war sie nie. In allen Sessions zeigten sich diese Muster in irgendeiner Ausprägung. Ein Coding-Agent, der auf Zuruf TDD praktizieren soll, tut das ungefähr so zuverlässig wie ein Praktikant, der die Methode aus einem Blogpost kennt.
Deshalb bewertete pro TDD-Lauf ein unabhängiger Agent die Transkripte und stufte die Einhaltung ein. Ohne diesen Schritt hätte man Lösungen verglichen, die nur auf dem Papier testgetrieben entstanden sind. Für eigene Experimente heißt das: Der Prozess muss gemessen werden, nicht nur das Ergebnis.
Was die Rangfolge zeigte: keine klare Überlegenheit
Fünf Stapel entstanden, jeder mit zwei Nicht-TDD- und zwei TDD-Lösungen; in einem Stapel kamen zwei Läufe hinzu, die nur die Tests zuerst schrieben, ohne roten und grünen Schritt einzeln zu bestätigen. Bei der kleinen und den drei mittleren Aufgaben zeigte sich ein Muster: Opus setzte die beiden Nicht-TDD-Lösungen auf Platz eins und zwei, die beiden TDD-Lösungen auf Platz drei und vier.
Nur ein einziges Mal landete eine TDD-Lösung auf Platz eins – nachdem der Autor den Prompt um einen ausdrücklichen Refactor-and-Design-Review-Schritt erweitert hatte. In genau diesem Stapel wurde die andere TDD-Lösung mit demselben Prompt Letzter. Bei der größeren Aufgabe lagen die TDD-Varianten in der Mitte, während die beiden Nicht-TDD-Läufe den besten und den schlechtesten Platz belegten.
Über alle Stapel hinweg schnitten also sowohl TDD- als auch Nicht-TDD-Läufe mal am besten und mal am schlechtesten ab, mit einem leichten Vorteil für die Nicht-TDD-Seite. Auch die Mutation Scores, die über Regressionsqualität Auskunft geben, zeigten kein Signal in eine Richtung. Wer gehofft hatte, der Agent Loop mache Testdisziplin automatisch messbar besser, wird enttäuscht.
Das fehlende Design vor dem ersten Test
Der aufschlussreichste Teil des Berichts ist nicht die Rangliste, sondern die nachgelagerte Analyse. Der Autor gab Opus die Transkripte und fragte, welche Arbeitsweise die Unterschiede erklären könnte. Das Muster: Die Nicht-TDD- und die Test-first-Läufe bauten immer erst das vollständige Design – Architektur, Datentypen, Randfälle, Verträge –, bevor sie eine Zeile Code oder einen Test schrieben. Die TDD-Läufe arbeiteten sich Anforderung für Anforderung vor, ein Test nach dem anderen.
Der Unterschied lag im Design. Das vorgelagerte Design führte zu vergleichsweise besseren Datenmodellen, zu Randfällen, die quer zu einzelnen Anforderungen liegen, und zu einer vollständigeren Funktionalität. Die TDD-Anweisung arbeitet diesem Schritt aktiv entgegen, weil sie Design immer nur als Nebenprodukt des nächsten Tests zulässt.
In den TDD-Läufen entstand das Design entsprechend als Summe vieler lokal minimaler Entscheidungen. Es wurde selten überprüft und landete meist bei der Form, die der erste geschriebene Test zufällig festgelegt hatte. Verhalten, für das der Agent keinen Test erfunden hat, wurde gar nicht implementiert – der Flur im Haus, den niemand bestellt hat, fehlt am Ende komplett.
Ivett Ördög lieferte gegenüber dem Autor eine Erklärung, die über den Einzelfall hinausgeht. Modelle hätten in ihren Trainingsdaten vor allem fertige Funktionen und Beschreibungen davon gesehen, nur einen winzigen Bruchteil echte TDD-Beispiele Schritt für Schritt. Ein Modell besitze damit eine interne Repräsentation von Code als direkter Übersetzung aus Anforderungen, nicht als Prozess, der zu dieser Repräsentation hinführt.
Welche Ziele von TDD im Agent Loop verloren gehen
Der Autor geht anschließend die Ziele durch, die er persönlich mit TDD verfolgt, und fragt, was davon übrig bleibt, wenn der Mensch aus der Schleife verschwindet. Beim Test-first gegen Tautologie gelingt das nur halb: Eigentlich soll der zuerst geschriebene Test das gewünschte Verhalten festhalten, statt die Implementierung nachzubeten. In einem besonders deutlichen Fall prüften Tests die Ausgabe der Implementierung gegen sich selbst, indem sie denselben Code erneut laufen ließen. Test-first macht das unwahrscheinlicher, verhindert es aber nicht.
Der Red-Green-Schritt verliert im Agent Loop seinen eigentlichen Zweck. Ein Test, der rot war und dann grün wird, beweist in Menschenhand, dass er einen Rückschritt fangen würde. Wenn derselbe Agent den Test schreibt und den roten Lauf bestätigt, ist das Protokoll eines Ablaufs, kein Beweis über den Grund der Fehlschläge. Die Einhaltungsanalyse zeigt zudem, dass Agenten den roten Schritt weiterhin gelegentlich überspringen oder vortäuschen.
Am stärksten wiegt das beim Design. Beim Menschen erzwingt Test-first, dass man die Nutzung vor der Implementierung durchdenkt und die Reibung aushält, ein Verhalten zu spezifizieren, ohne zu wissen, wie man es baut. Ein Agent spürt diese Reibung nicht, er schreibt den Test im selben Moment, in dem er die Implementierung plant. Ohne einen menschlichen Prüfpunkt dazwischen bleibt vom Test-first wenig übrig.
Auch YAGNI, das Prinzip, nur so viel Code zu schreiben, wie der nächste Test verlangt, ist ein menschliches Gut. Es geht um Zurückhaltung gegenüber Abstraktionen, die niemand bestellt hat. Agenten halten sich nicht daran: Minimal-Implementierungs-Anweisungen stoppten sie im Experiment nicht zuverlässig, sie schossen häufig über den aktuellen Test hinaus, weil die Gesamtanforderung ohnehin im Kontext lag.
Was das für den eigenen Workflow bedeutet
Die Konsequenz ist nicht, TDD mit KI-Agenten zu verwerfen. Der Wert liegt an den Prüfpunkten, an denen ein Mensch hinsieht. Die Variante, in der ein Mensch die Testfälle vorgibt – als natürliche Sprache, im BDD-Stil oder direkt als Code – und der Agent nur die Implementierung liefert, behält die Reibung dort, wo sie nützt. Dasselbe gilt für die Variante mit Review-Checkpoint zwischen rotem Test und Implementierung.
Die vollautomatische TDD-Schleife im Agenten dagegen misst ihre eigene Arbeit. Sie liefert dir Tests, aber keine unabhängige Bestätigung, dass diese Tests das Richtige prüfen. Wenn du Regressionsqualität wissen willst, ist Mutation Testing das ehrlichere Instrument als die Prozessdisziplin – der Autor hat dazu an anderer Stelle geschrieben, und die Mutationswerte in diesem Experiment stützten keinen Vorteil der TDD-Läufe.
Für die eigene Arbeit heißt das: Fordere einen Designschritt vor dem ersten Test ein, statt TDD als Ritual zu verlangen. Ein Coding-Agent, der Architektur, Datentypen und Randfälle einmal durchdenkt und dann testgetrieben implementiert, hat den Grundriss, bevor die erste Wand steht. Ob die Tests dabei vor oder nach dem Code entstehen, ist zweitrangig – wichtig ist, wer sie prüft und woran du erkennst, dass sie greifen.
Der Autor wünscht sich größere Experimente mit mehr Läufen und mehr Token. Bis dahin gilt: TDD mit KI-Agenten läuft nicht von selbst, und die Anweisung, den Workflow einzuhalten, beweist noch nicht, dass er etwas verbessert.
Quelle: martinfowler.com
