KI-TDD-Pipeline: Wie schlechte Anweisungen 3.400 Tests erzeugten und was das Problem löste

Das Problem: Wörtliche Interpretation im großen Maßstab
Ein Entwickler erstellte eine Multi-Agent-TDD-Pipeline mit Claude Code, bei der verschiedene Agenten spezifische Aufgaben übernehmen: einer schreibt Tests, einer schreibt Code, um sie zu bestehen, einer überprüft alles, und einer sucht nach Randfällen. Die ursprüngliche Anweisung war einfach: "Schreibe Tests für alles."
Das System schien zu funktionieren – die Testanzahl stieg stetig und die CI war grün. Eine Überprüfung zeigte jedoch Probleme mit den 3.400 generierten Tests:
- 44 % gültig
- 30 % benötigten Überarbeitung
- 26 % völliger Unsinn
Die unsinnigen Tests umfassten:
- Tests, die ein JSON-Konfigurationsobjekt erstellten und dann behaupteten, es sei gleich sich selbst
- Tests, die prüften, ob eine TypeScript-Schnittstelle die richtige Form hatte, indem sie das Objekt bauten und behaupteten, es passe zu dem, was sie gerade gebaut hatten
- Tests für statische Dateien, die sich nie ändern werden
Der Entwickler löschte fast 20.000 Zeilen Testcode und identifizierte das Kernproblem: "Claude hat nicht versagt. Ich habe es getan. Ich sagte 'Schreibe Tests für alles' und es hat mich deutlich verstanden. Jede Datei. Jede Konfiguration. Jede Typdefinition. Meine Anweisungen waren das Problem, und der Agent befolgte sie perfekt."
Die Lösung: Klassifizierung und Überprüfung
Die Lösung umfasste zwei wichtige Änderungen:
1. Klassifizierung von Arbeitselementen vor dem Testen:
- Features erhalten 3–5 Verhaltenstests (funktioniert dieses Ding tatsächlich?)
- Aufgaben erhalten 1–2 Rauchtests (hat es etwas Offensichtliches kaputtgemacht?)
- Fehler erhalten 2–3 Regressionstests (wird dieser spezifische Fehler zurückkehren?)
- Verbesserungen testen nur neues oder geändertes Verhalten
2. Hinzufügen eines Review-Agenten: Ein separater Agent betrachtet sowohl Tests als auch Implementierung mit frischem Kontext und erkennt Probleme, die die schreibenden Agenten übersahen, weil sie zu nah an ihrer eigenen Ausgabe waren.
Ergebnisse nach der Lösung
- 3.400 Tests reduziert auf 2.525
- Ausführungszeit sank von 117 Sekunden auf ~50 Sekunden
- Jeder verbleibende Test validiert tatsächliches Verhalten
Wesentliche Erkenntnis
"Das Bauen mit KI-Agenten macht Ihr schlampiges Denken im großen Maßstab sichtbar. Ein Mensch schreibt schlechte Tests, Sie bekommen ein paar schlechte Tests. Geben Sie eine schlechte Anweisung an eine Agenten-Pipeline, die Hunderte von Arbeitselementen verarbeitet? Sie bekommen Hunderte von schlechten Tests. Dasselbe schlechte Denken, nur verstärkt über alles, was es berührt. Korrigieren Sie das Denken, korrigieren Sie die Ausgabe."
📖 Read the full source: r/ClaudeAI
👀 Siehe auch

Verwendung von Claude zur Automatisierung von App Store Connect-Metadaten-Updates für 33 Sprachen
Ein unabhängiger iOS-Entwickler nutzte Claude (per Chat), um ein Python-Skript zu generieren, das sich bei der App Store Connect API authentifiziert, Metadaten in 33 Sprachen übersetzt und lokalisierte 'What's New'-Texte pusht – und so stundenlange manuelle Arbeit pro Update ersetzt.

Praktische KI-Agenten-Einrichtungen für Kleinunternehmen: Friseur, Therapeut, Rechtsanwaltskanzlei, Content Creator und Spieleentwickler
Ein Entwickler teilt spezifische KI-Agenten-Implementierungen für fünf Kleinunternehmenstypen, beschreibt die automatisierten Arbeitsabläufe und die eingesparte Zeit. Jedes Setup nutzt mehrere spezialisierte Agenten mit einer gemeinsamen Speicherarchitektur.

Entwickler baut Paartherapie-App mit Claude und teilt Einblicke in Prompt Engineering
Ein Entwickler hat TherapAI erstellt, eine progressive Web-App für Paare, bei der jeder Partner einen privaten KI-Begleiter erhält, der von Claude Sonnet angetrieben wird. Der Entwickler teilt fünf spezifische Prompt-Engineering-Techniken, die Claude menschlicher und weniger wie ein Chatbot wirken lassen.

Hinzufügen einer schlanken Browser-Schicht zu OpenClaw auf einem Headless-VPS
Ein Entwickler teilt seinen Ansatz zur Handhabung von Websites, die mehr als reines Headless-Browsing benötigen, indem er eine minimale visuelle Browserumgebung nur bei Bedarf hinzufügt, während der VPS standardmäßig headless bleibt und persistente Browserprofile wiederverwendet werden.