Agentic TDD: Warum Test-Driven Development der natürliche Partner von Coding-Agenten ist

Test-Driven Development hatte unter Menschen immer einen zwiespältigen Ruf. Die Idee ist alt, die Literatur überzeugend, und trotzdem hielten viele Teams TDD für zu teuer -- zu viel Overhead im Moment, zu wenig spürbarer Gewinn. Interessanterweise kippt diese Rechnung gerade komplett. Wer einen Coding-Agenten ernsthaft ohne permanentes Babysitting laufen lassen will, findet in TDD das wahrscheinlich stärkste verfügbare Steuerungswerkzeug. Nicht als Dogma, sondern als schlichter Mechanismus: Die Tests sind der Kontrakt, der Agent arbeitet dagegen, die Maschine entscheidet, wann Schluss ist.

Warum TDD für Agenten besser funktioniert als für Menschen

Die klassische Kritik an TDD zielte auf die Kosten: Tests vorab schreiben fühlt sich langsam an, weil ein Mensch im selben Kopf sowohl das Testdesign als auch die Implementierung halten muss. Bei Agenten verschwindet dieser Engpass. Ein Agent ermüdet nicht, wird nicht genervt, wenn ein Fehler in Schleife auftritt, und liest einen Stacktrace in Millisekunden. Rapide Iteration und stures Fehlersuchen sind genau die Stärken, bei denen Menschen langsam werden.

Gleichzeitig adressieren Tests die gefährlichste Schwäche heutiger Agenten: die Tendenz, plausibel aussehenden Code zu produzieren, der das Problem subtil falsch löst. Ohne objektive Verifikation ist jeder Agent-Output ein Versprechen -- mit einer grünen Testsuite wird daraus ein überprüftes Artefakt. Das ist der Unterschied zwischen "sieht richtig aus" und "erfüllt nachweislich die Spezifikation".

Der agentische TDD-Workflow in drei Schritten

Der Ablauf ist einfacher, als die Theorie vermuten lässt. Er besteht im Kern aus drei Phasen, die bewusst aufeinander aufbauen.

1. Tests zuerst, gründlich. Bevor der Agent auch nur eine Zeile Produktionscode sieht, entsteht eine robuste Testsuite. Umfassende Abdeckung der kritischen Pfade, klar formulierte Erwartungen, keine vagen Assertions. In dieser Phase werden die Requirements zementiert -- danach sind sie nicht mehr verhandelbar. Das ist anstrengend, aber es ist die Arbeit, die Menschen ohnehin am besten leisten: Intention festlegen.

2. Den Agenten isolieren, die Tests schützen. Die Implementierung wandert zum Agenten, aber mit strikten Grenzen. Die wichtigste Regel: Der Agent darf die Tests nicht modifizieren können. Sonst tut er es früher oder später -- nicht aus Bosheit, sondern weil "Test anpassen" aus der Innenperspektive des Agenten ein legitimer Weg zu einer grünen Suite ist. In manchen Setups lohnt es sich sogar, dem Agenten die Test-Sources gar nicht sichtbar zu machen, sondern nur die Execution-Results und Error-Logs zurückzuspielen. Das erzwingt echtes Problemlösen statt Reverse-Engineering des erwarteten Outputs.

3. Iterieren, bis grün. Danach läuft der Agent selbstständig. Er implementiert, führt die Suite aus, liest die Fehler, korrigiert, wiederholt. Ein Mensch muss nicht mehr bei jedem Schritt danebensitzen. Die Abbruchbedingung ist maschinenlesbar: alle Tests bestanden.

TDD vs. Babysitting -- die Abgrenzung, die zählt

Viele Teams haben heute einen Modus, den man ehrlicherweise Babysitting nennen muss: Agent macht einen Schritt, Mensch liest, Mensch korrigiert, Agent macht nächsten Schritt. Das ist produktiver als reines Handschreiben, aber es skaliert schlecht und frisst Aufmerksamkeit. Agentisches TDD verschiebt den Einsatzpunkt menschlicher Urteilskraft: nach vorne, in die Testdefinition. Während der Implementierung ist Aufmerksamkeit nicht mehr nötig. Das ist der eigentliche Produktivitätsgewinn -- nicht der Agent selbst, sondern die Tatsache, dass ein Entwickler parallel etwas anderes tun kann, während der Agent iteriert.

Die Abgrenzung zum Feedback Flywheel ist sauber: Der Flywheel strukturiert das Lernen des Teams über viele Sessions hinweg. Agentisches TDD strukturiert die einzelne Session so, dass sie ohne menschliches Eingreifen zum Ende kommt.

Praktische Umsetzung in Claude Code, Codex und Cursor

Die theoretische Trennung zwischen Agent und Tests ist nur die halbe Miete -- sie muss im Werkzeug verankert werden.

• Claude Code: Zugriffsbeschränkung über settings.json und Hook-basierte Guards. Ein PreToolUse-Hook, der Schreibzugriffe auf tests/, spec/ oder __tests__/ blockiert, ist in wenigen Zeilen geschrieben und wirkt zuverlässig. Zusätzlich hilft ein Subagent mit eigenem System-Prompt, der ausschliesslich Implementation bearbeitet, während die Test-Suite in einem separaten Verzeichnis liegt, das er gar nicht in seinen Kontext bekommt. Der Test-Runner-Output wird als reines Bash-Ergebnis zurückgereicht.
• Codex: Im CLI-Modus lassen sich Tests in einem Read-Only-Mount ablegen, während das Workspace-Verzeichnis schreibbar bleibt. Der Agent sieht die Fehler, kann sie aber nicht "wegoptimieren". Für CI-getriebene Läufe reicht ein schlichter Branch-Schutz auf Test-Dateien.
• Cursor: Die .cursorignore-Datei blendet Tests aus dem Indexing aus, was verhindert, dass der Agent sie in seinen Kontext zieht. Kombiniert mit einer Rules-Datei, die explizit das Anfassen von Test-Dateien verbietet, entsteht eine brauchbare Leitplanke -- nicht hart, aber wirksam.

Egal welches Werkzeug: Die Idee ist immer dieselbe. Execution-Feedback ja, Test-Source nein oder nur lesend.

Wo TDD an seine Grenzen kommt

Agentisches TDD ist kein Allheilmittel. Drew Breunigs Unterscheidung zwischen Phase 1 und Phase 2 der Agentic-Entwicklung ist hier nützlich: Bei Ports und Klonen sind Tests fast geschenkt, bei echten Neuerfindungen muss die Suite mühsam selbst entstehen -- und genau dort liegt dann der eigentliche Engineering-Aufwand. Ebenso lassen sich nicht alle Qualitätsziele in Tests gießen. Architekturgüte, Lesbarkeit, Wartbarkeit bleiben Review-Themen. Wer eine vollständige Absicherung sucht, kombiniert TDD mit einem Three-Agent Harness, in dem ein Evaluator zusätzlich auf subjektive Qualität achtet, und mit den gestaffelten Praktiken aus Fünf agile Praktiken gegen die Qualitätsfalle.

Der Kern bleibt aber einfach: Tests sind der Mechanismus, der einen Agenten ohne Babysitting arbeiten lässt. Alles andere ist Ergänzung.

Quellen

• How should you guide AI agents through complex tasks? | Elite AI-Assisted Coding (April 2026)