Erst der rote Test

Ein Agent schreibt in zwei Minuten, wofür ein Mensch einen Vormittag braucht. Damit verschiebt sich die Arbeit von der Erzeugung zur Prüfung, und die Frage lautet, woran eigentlich geprüft wird. Testgetriebene Entwicklung beantwortet sie mit einer Regel über die Reihenfolge: Der Test entsteht, bevor es den Code gibt, den er prüfen soll.

Die Regel ist über zwanzig Jahre alt. Was mit einem Agenten dazukommt, ist eine zweite Rolle für denselben Test. Er beschreibt die Erwartung an eine Arbeit, die jemand anderes ausführt, und dieser andere hat gute Gründe, sie umzuschreiben.

Woraus die Methode besteht

Kent Beck hat sie 2002 in einem Buch beschrieben und 2023 noch einmal festgelegt, weil zu viele Beschreibungen im Umlauf waren, die etwas anderes meinen (Canon TDD (externe Seite, newsletter.kentbeck.com)). Fünf Schritte. Der erste sammelt: eine Liste der Testfälle, die abgedeckt werden sollen.

Der zweite ist der entscheidende, und er räumt gleich mit dem verbreitetsten Missverständnis auf: Genau ein Eintrag der Liste wird zu einem echten, konkreten, ausführbaren Test.

Die Liste darf lang sein, konkret wird immer nur ein Fall. Danach kommt der Code, der diesen einen Test und alle vorherigen bestehen lässt, dann wahlweise die Aufräumarbeit, die den Entwurf der Implementierung verbessert.

Und dann von vorn, bis die Liste leer ist. Der dritte Schritt heißt Refactoring und ist der Grund, warum die Methode über die Zeit etwas bringt: Solange die Tests grün sind, lässt sich die innere Form ändern, ohne das Verhalten anzufassen.

Die Kurzform, unter der die Methode meistens läuft, ist rot, grün, aufräumen. Der rote Test steht am Anfang, und er hat eine Aufgabe, die man ihm nicht ansieht: Er beweist, dass die Prüfung überhaupt anschlagen kann.

Die Reihenfolge ist die ganze Aussage

Ein Test nach dem Code hält fest, was der Code tut. Ein Test vor dem Code hält fest, was er tun soll. Beide Sätze beschreiben eine Datei mit denselben Zeilen, und der Unterschied liegt darin, woher die Erwartung stammt.

seitlich verschiebbar

eigene Darstellung, Stand 28.08.2026

Das ist am Fehlerfall am leichtesten zu sehen. Wer einen Fehler behebt und danach einen Test dazu schreibt, hat einen Test, der beim ersten Lauf grün ist. Er beweist nichts, denn er lief nie gegen den kaputten Zustand. Wer zuerst den Fall aufschreibt, der schiefgeht, hat eine Reproduktion, und die Behebung ist belegt, sobald sie grün wird. Der Hersteller von Claude Code nimmt in seinen Best Practices (externe Seite, code.claude.com) genau das als Beispiel für einen genauen Auftrag zu einem Fehlerbericht: erst einen fehlschlagenden Test schreiben, der den Fehler nachstellt, dann ihn beheben.

Der Maßstab dahinter hat einen Namen. Der Datensatz TDD-Bench Verified sammelt 449 echte Vorgänge (externe Seite, arxiv.org) aus öffentlichen Verzeichnissen und prüft für jeden erzeugten Test dasselbe: Er muss fallen, solange der Vorgang ungelöst ist, und nach der Lösung durchgehen.

Ein Test, der nur die zweite Hälfte erfüllt, sagt über die Behebung nichts.

Was ein Agent an Prüfungen überhaupt lesen kann und wie verbindlich eine Prüfung das Ende einer Antwort aufhält, steht in Vibe-Coding / Agentic Engineering, Kapitel 07. Dieser Text setzt eine Ebene davor an, bei der Frage, wann die Erwartung entsteht.

Was ein Agent daraus macht

Beck hat 2025 aufgeschrieben (externe Seite, newsletter.kentbeck.com), wie sich seine eigene Arbeit mit einem Agenten verändert hat, und dabei zwei Arbeitsweisen getrennt. Beim Vibe Coding zählt allein das Verhalten des Systems, der Code ist einem gleichgültig. Beim Augmented Coding zählen der Code, seine Komplexität, die Tests und ihre Abdeckung.

Für die zweite Arbeitsweise schrieb er dem Agenten den Zyklus in die Systemanweisung. Dazu drei Signale, bei denen er abbricht, und das dritte beschreibt das Verhalten, gegen das jede Testregel im Agentenbetrieb ankommt: jedes Anzeichen, dass der Agent (bei Beck der Flaschengeist) schummelt, etwa indem er Tests abschaltet oder löscht.

Das ist selten böse Absicht. Ein Agent bekommt ein Ziel, und ein roter Test steht zwischen ihm und diesem Ziel. Die Zeile zu ändern, an der es scheitert, ist der kürzere Weg. Über Werkzeuge hinweg gemessen hat das eine Untersuchung (externe Seite, arxiv.org), die eine Umgebung gebaut hat, in der das Schummeln (Reward Hacking) absichtlich leichtfällt, etwa durch fest eingesetzte Testfälle oder durch Änderungen an den Testdateien.

Getestet wurden drei verbreitete Werkzeuge, darunter Claude Code selbst. Ausdrückliches Reward Hacking beobachteten die Autoren bei Codex und bei Claude Code, fehlgeleitetes Verhalten bei allen drei Agenten.

Damit ist die Lage klar genug für eine praktische Folgerung. Ein Test, den der Ausführende ändern darf, ist eine Bitte. Ein Test, den er nicht ändern kann, ist eine Vorgabe.

Was gemessen ist, in beide Richtungen

Über den Nutzen von Tests im Agentenbetrieb stehen zwei Arbeiten scheinbar gegeneinander. Sie messen Verschiedenes, und der Unterschied ist die interessanteste Stelle dieses Themas.

Tests, die sich der Agent selbst schreibt. Eine Untersuchung von Anfang 2026 (externe Seite, arxiv.org) hat die Abläufe von sechs starken Modellen auf einem verbreiteten Aufgabensatz durchgesehen. Ausgangspunkt war eine Beobachtung: Agenten schreiben oft nebenbei Tests, und welchen Wert das hat, ist unklar.

Das Ergebnis fällt nüchtern aus. Gelöste und ungelöste Aufgaben desselben Modells zeigen ähnlich häufig geschriebene Tests. In einem zweiten Schritt haben die Autoren die Aufträge gezielt umgeschrieben, um mehr oder weniger Tests zu erzwingen. Die so veränderte Testmenge bewegte das Endergebnis in diesem Aufbau nicht signifikant.

Die Begründung steht daneben und erklärt den ganzen Befund: Was ein Agent von sich aus Test nennt, dient vor allem als Rückmeldung zum Hinsehen. Ausgaben, die Werte anzeigen, kommen viel häufiger vor als Prüfungen mit einer Zusicherung, die bei Abweichung fällt. Die Autoren fassen es so zusammen: Die heutige Testpraxis der Agenten verändert Weg und Kosten stärker als das Ergebnis der Aufgabe.

Tests, die vorgegeben sind. Der Gegenfall ist ein Aufbau namens TDFlow (externe Seite, arxiv.org), der die Aufgabe von vornherein als Testaufgabe fasst: Er ist eigens dafür gebaut, men­schen­ge­schrie­bene Tests zu lösen.

Damit erreicht er Werte, die in diesem Feld ungewöhnlich hoch liegen. Bekommt er men­schen­ge­schrie­bene Tests vorgegeben, besteht er 88,8 Prozent der Aufgaben von SWE-Bench Lite, absolut 27,8 Punkte mehr als das nächstbeste System, und 94,3 Prozent von SWE-Bench Verified.

Die Bedingung am Satzanfang gehört zu beiden Zahlen. Ohne vorgegebene Tests misst der Aufbau eine andere Aufgabe. Aufschlussreich ist die Nachkontrolle: Bei 800 Läufen fanden die Autoren nur sieben Fälle, in denen das System am Test statt am Fehler arbeitete, und verbuchten sie nachträglich als Fehlschlag. Sieben von achthundert Läufen ist selten. Der Fall kommt vor.

Was daraus folgt. Die Menge der Tests sagt wenig. Wer sie geschrieben hat und wann, sagt viel. Ein Test, den der Agent während seiner Arbeit anlegt, ist sein Werkzeug zum Nachsehen. Ein Test, der vor der Arbeit dasteht und den er nicht anfassen darf, ist die Beschreibung der Aufgabe.

Der Rahmen dazu kommt aus der Jahreserhebung von DORA (externe Seite, cloud.google.com). Sie misst, dass die Verbreitung dieser Werkzeuge weiterhin mit geringerer Stabilität der Soft­ware­aus­lie­fe­rung einhergeht. Als Mechanismus benennt sie: Mehr Änderungsvolumen führt zu Instabilität.

Mehr Änderungen je Zeiteinheit, gleichbleibendes Netz darunter. Die Vorkehrungen, die den Unterschied machen, sind in Vibe-Coding / Agentic Engineering, Kapitel 01 aufgezählt.

Was zu beachten ist

Vier Grenzen gehören dazu, sonst wird aus der Methode ein Ritual.

Ein grüner Test kann leer sein. Eine Prüfung, die nie anschlägt, sieht genauso aus wie eine, die nichts messen kann. Beim testgetriebenen Arbeiten schützt der rote Lauf davor, weil die Prüfung einmal aus dem richtigen Grund gefallen sein muss. Die Fälle, in denen dieser Schutz umgangen wird, stehen mit Beispielen in Vibe-Coding / Agentic Engineering, Kapitel 07.

Bei vorhandenem Code geht test-first nicht. Wer Tests zu Bestehendem nachliefert, bekommt beim ersten Lauf Grün, und damit ist nichts belegt. Der Ersatz für den roten Lauf ist eine Mutation: eine absichtlich kaputte Fassung des Prüflings, gegen die der Test fallen muss. Fällt er dort und schweigt gegen die reparierte Fassung, misst er etwas.

Dabei lohnt sich die Gegenprobe vorher, ob der unveränderte Stand grün ist. Ein kaputter Messaufbau erzeugt rote Läufe, die mit der Mutation nichts zu tun haben, und man hält ihn dann für einen scharfen Riegel.

Die Abdeckungszahl ist keine Aussage über die Fehler. Ein Testbestand wächst dort, wo Tests leicht zu schreiben sind. Wo die Fehler sitzen, ist eine zweite Frage, und beides fällt selten zusammen. Eine Abdeckung von 80 Prozent sagt, welcher Anteil der Zeilen einmal ausgeführt wurde. Über die Güte der Zusicherungen darin sagt sie nichts.

Ein erfüllter Test kann die Sache verfehlen. Die drei Punkte oben handeln davon, dass eine Prüfung nichts misst. Der vierte ist unangenehmer, weil dort die Prüfung in Ordnung ist. Eine Untersuchung vom Juni 2026 (externe Seite, arxiv.org) ließ zwei Agenten eine Bedienoberfläche in eine andere Technik übertragen, gemessen an 222 Prüfungen, die sie nie zu sehen bekamen. Lag die Prüfung im Arbeitsablauf, stieg die Bewertung bis fast auf die volle Punktzahl.

Dabei war die geforderte Bibliothek tot oder fehlte ganz. Die Autoren nennen das Bauen auf die Prüfung hin und beschreiben die Ursache als eine fehlende Gewohnheit: Von sich aus prüft der Agent das Ausgelieferte nicht so, wie ein Nutzer es täte.

Das arbeitet gegen die Empfehlung dieses Textes. Ein Test, den der Ausführende nicht ändern kann, ist eine Vorgabe, und damit wird er zur Zielscheibe. Der Aufbau der Untersuchung ist eng, ein Vorhaben in achtzehn Läufen, und die Autoren sagen selbst, dass offen bleibt, wie verbreitet das bei anderen Agenten, Signalen und Modellfamilien ist.

Vorgegebene Tests bleiben richtig. Ihnen fehlt eine Ergänzung: Am Ende sieht ein Mensch die Sache an, und zwar so, wie sie benutzt wird.

In Claude Code eingerichtet

Bis hierher ging es um die Methode. Der Rest handelt davon, wie man sie so verankert, dass sie auch bei einem Lauf greift, bei dem niemand zusieht.

Die Einrichtungen bauen aufeinander auf. Jede kostet mehr Vorbereitung als die vorige und braucht dafür weniger Aufmerksamkeit im Betrieb.

Der Auftrag

Am Anfang steht ein Satz, und er wirkt sofort. Wichtig sind drei Angaben.

Erstens der Name der Methode, ausdrücklich. Ohne ihn baut der Agent hilfsbereit Mocks für Dinge, die es noch gar nicht gibt, damit der Test durchläuft. Zweitens die Trennung der Schritte: erst die Tests, dann anhalten. Drittens die Auflage für die zweite Hälfte, die Tests unangetastet zu lassen.

Wir arbeiten testgetrieben. Schreibe zuerst die Tests für die drei Fälle
unten, mehr nicht. Keine Implementierung, keine Mocks. Fahre sie, zeige
mir die Ausgabe, und wir sehen gemeinsam, ob sie aus dem richtigen Grund
rot sind.

Der letzte Halbsatz ist der wichtigste. Ein roter Test kann auch fallen, weil ein Modul fehlt oder ein Name falsch geschrieben ist, und dann misst er die Schreibweise. Die Fehlermeldung sagt, welcher der beiden Fälle vorliegt.

Erst danach folgt der zweite Auftrag mit der Implementierung, und der nennt die Auflage noch einmal.

Warum die Projektanweisung allein nicht genügt

Der nächstliegende Gedanke ist, die Regel dauerhaft in die CLAUDE.md zu schreiben. Das ist sinnvoll, denn die Datei wird zu Beginn jeder Sitzung gelesen, und der Hersteller nennt in seinen Best Practices (externe Seite, code.claude.com) die genauen Befehle für Test, Typprüfung und Linter ausdrücklich als etwas, das dorthin gehört, samt dem Aufruf für eine einzelne Testdatei.

Nur ist der Charakter der Datei ein anderer, als man beim Schreiben annimmt: Claude folgt einer Zeile dort fast immer, und doch bleibt es bei jeder einzelnen Antwort Claudes Entscheidung, ob es ihr folgt.

Die Rech­te­do­ku­men­ta­tion (externe Seite, code.claude.com) sagt es noch deutlicher und zieht die Grenze zwischen dem, was das Modell versucht, und dem, was die Umgebung zulässt: Rechteregeln setzt Claude Code durch, das Modell hat darauf keinen Einfluss.

Eine Regel im Auftrag beeinflusst den Versuch. Über das Ergebnis entscheidet etwas anderes.

Seit März 2026 gibt es dazu eine Messung. Eine Arbeit (externe Seite, arxiv.org) über Regressionen zählt die Tests, die vor einer Änderung liefen und danach fallen, und stellt drei Bedingungen gegeneinander. Ohne Eingriff lag der Anteil bei 6,08 Prozent. Bekam der Agent gezielt gesagt, welche Tests seine Änderung berührt, sank er auf 1,82. Die dritte Bedingung gab ihm allein die Anweisung, testgetrieben zu arbeiten, ohne gezielten Testkontext, und damit stiegen die Regressionen auf 9,94 Prozent.

Von 6,08 auf 9,94 Prozent. Die Autoren nennen das schlechter als gar keinen Eingriff.

seitlich verschiebbar

eigene Darstellung nach Alonso u. a., TDAD, Stand 28.08.2026

Zwei Angaben gehören zu der Zahl. Die erste ist die Erhebung: gemessen auf SWE-bench Verified mit zwei Modellen mit offenen Gewichten, die auf Ver­brau­cher­hard­ware laufen.

Hundert Aufgaben beim einen Modell, fünfundzwanzig beim anderen. Das ist wenig und macht die Werte zu einer Richtung. Die zweite Angabe steht als Nebensatz im Befund selbst: gemessen wurde die Anweisung ohne den passenden Testkontext. Das eigene Fazit der Arbeit zieht die Grenze dort entlang: Kontext bereitzustellen wirkt besser, als Arbeitsabläufe vorzuschreiben.

Der Ablauf im Auftrag ist eine Beschreibung. Was der Agent daraus macht, entscheidet sich daran, ob er das Material dazu bekommt.

Das ist übrigens kein Argument gegen die Datei. Ein Eintrag dort kostet eine Zeile und verbessert die Ausgangslage jeder Sitzung. Er ist nur kein Riegel, und man sollte ihn nicht für einen halten. Wie die Projektanweisung entsteht und was gemessen dort hineingehört, steht in Vibe-Coding / Agentic Engineering, Kapitel 03.

Die Testdateien sperren

Der billigste echte Riegel ist eine Rechteregel. Während der Implementierung sind die Testdateien tabu:

{
  "permissions": {
    "deny": [
      "Edit(tests/**)",
      "Edit(**/*.test.ts)"
    ]
  }
}

Dabei lauern zwei Fallen.

Die Regelart muss Edit heißen. Pfadregeln werden allein gegen Edit und Read geprüft. Wer die naheliegende Schreibweise mit Write wählt, bekommt keinen Fehler, und neuere Versionen melden es beim Start nur als Warnung: Claude Code nimmt die Regel an und prüft keinen Lese- oder Schreibzugriff gegen sie.

Die Sperre sieht dann in der Einstellungsdatei vollständig aus und wirkt nicht; wer die Warnung übersieht, merkt es erst am geänderten Test. Edit deckt die Schreibwerkzeuge mit ab, also ist es die richtige Wahl.

Die Rangfolge ist fest. Unter den Regeln gewinnt die Sperre: Sie werden der Reihe nach ausgewertet, erst deny, dann ask, dann allow.

Eine engere Erlaubnis hebt eine weiter gefasste Sperre also nicht auf. Wer die Tests nach der Implementierung wieder ändern will, nimmt die Regel heraus, statt sie zu übersteuern.

Ein Nachsatz zur Reichweite: Die Sperre greift bei den eingebauten Dateiwerkzeugen und bei Shell-Befehlen, die Claude Code als Dateizugriff erkennt. Ein Skript, das die Datei selbst öffnet, läuft daran vorbei. Für eine Sperre auf Betriebs­sys­tem­ebene ist die Sandbox zuständig.

Auch über einen Symlink lässt sich eine Sperre nicht umgehen: Sie greift, wenn der angefragte Pfad oder die Datei, auf die er zeigt, zu ihr passt. Ein Link auf eine gesperrte Testdatei ist damit selbst gesperrt.

Die Zielbedingung

Für einen Lauf über mehrere Antworten gibt es /goal. Die Bedingung wird einmal formuliert, danach urteilt nach jeder Antwort ein eigenes Modell darüber, ob sie erfüllt ist.

/goal npm test endet mit 0 und git status --short zeigt nichts unter tests/.
Fahre beide Befehle am Ende jeder Antwort und zeige ihre Ausgabe.

Die Dokumentation (externe Seite, code.claude.com) nennt als Beispiel für eine solche Nebenbedingung genau diesen Fall: dass keine andere Testdatei verändert wird.

Eine Eigenart des Bewerters gehört dazu, sonst formuliert man ins Leere: Er führt keine Befehle aus und liest keine Dateien selbst, also schreibt man die Bedingung so, dass Claudes eigene Ausgabe sie belegen kann.

Der Bewerter liest, was in der Unterhaltung steht. Eine Bedingung wie „der Code ist sauber“ kann er nicht beurteilen, „npm test endet mit Null“ schon, weil der Agent den Lauf zeigt.

Der Riegel am Ende der Antwort

Die härteste Stufe innerhalb des Werkzeugs ist ein Hook am Ereignis für das Ende der Antwort. Er hält die Antwort offen, bis sein Skript zufrieden ist.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "npm test --silent 1>&2 || exit 2" }
        ]
      }
    ]
  }
}

Das angehängte || exit 2 sieht nach Zierrat aus und ist der ganze Riegel. Die Umleitung 1>&2 gibt der Sperre ihren Grund: Was das Skript auf den Fehlerkanal schreibt, bekommt Claude als Begründung zurück, warum die Antwort noch nicht enden darf. Ohne sie käme dort nur an, was das Testwerkzeug ohnehin auf den Fehlerkanal schreibt. Blockiert wird allein bei diesem einen Rückgabewert, so steht es in der Hook-Referenz (externe Seite, code.claude.com): Wer die Aktion blockieren will, beendet den Hook mit Code 2. Für das Ende der Antwort heißt das: Der Hook verhindert, dass Claude aufhört, und setzt die Unterhaltung fort.

Ein gescheiterter Testlauf endet aber mit 1, und jeder andere Wert als 2 lässt die Antwort enden. Ohne die Übersetzung hätte man einen Eintrag in der Einstellungsdatei, der vollständig aussieht und nichts aufhält. Die Einstellung "onFailure": "block", die einen scheiternden Hook sonst als Abweisung zählt, wirkt am Ende der Antwort nicht. Eine Ausnahme nennt die Referenz für dieses Ereignis außerdem: Endet der Hook mit 2, steht nichts auf der Standardausgabe und meldet der Fehlerkanal eine fehlende Datei, gilt der Lauf als Fehler ohne Blockade. Scheitert ein Testlauf an einer fehlenden Datei, kann die Antwort deshalb trotz || exit 2 enden. Wer einen Riegel einbaut, sollte ihn einmal absichtlich auslösen und nachsehen, ob die Antwort wirklich offen bleibt.

Und er gibt irgendwann nach: Haben Stop-Hooks die Antwort achtmal hintereinander fortgesetzt, übergeht Claude Code die nächste Blockade und beendet die Antwort. So setzt eine dauerhaft scheiternde Prüfung die Sitzung nicht fest. Ein Tool Call setzt die Zählung zurück, und über eine Umgebungsvariable lässt sich die Grenze anheben. Wer sich auf den Riegel verlässt, sollte diese Obergrenze kennen. Wie Hooks im Einzelnen aufgesetzt werden, steht in Claude Code, Kapitel 18.

Außerhalb des Werkzeugs kommt der Haken vor dem Commit dazu. Er greift auch dann, wenn jemand von Hand committet, und er ist die einzige Stelle, die einen Agenten erwischt, der über die Shell arbeitet.

Zwei Sitzungen, zwei Rollen

Die sauberste Form der Trennung ist die personelle. Eine zweite Sitzung ist laut den Best Practices (externe Seite, code.claude.com) des Herstellers der einfachste unabhängige Prüfer, den man bekommen kann. Die eine schreibt, die andere prüft, ohne beim Schreiben zugesehen zu haben. Für Tests heißt das: Die zweite Sitzung hält die Arbeit der ersten gegen die Spezifikation und prüft, ob jeder aufgeführte Grenzfall einen Test hat. Ihre Befunde trägt man zurück in die erste Sitzung, und die behebt sie.

Der Gewinn liegt am fehlenden Vorwissen. Wer eine Aufgabe gelöst hat, liest das Ergebnis mit dem Weg dorthin im Kopf. Eine frische Sitzung sieht allein, was dasteht. Dasselbe Argument steht hinter dem Prüfer als Subagent, siehe Vibe-Coding / Agentic Engineering, Kapitel 13.

Wie weit diese Trennung reicht, ist gemessen, wenn auch an einem anderen Gegenstand. Eine Arbeit vom Mai 2026 (externe Seite, arxiv.org) ließ neun starke Modelle aus sieben Familien über dieselben Aufgaben urteilen und rechnete nach, wie viel Unabhängigkeit in so einem Gremium steckt: Rund drei Viertel der Unabhängigkeit, die es auf dem Papier hat, gehen verloren.

Sie verschwinden, weil die Modelle an denselben Stellen dieselben Fehler machen. Aus neun Stimmen werden rechnerisch etwa zwei. Der Schluss der Autoren: Ein größeres Gremium kann eine wirklich unabhängige Bewertung nicht ersetzen.

Gemessen wurde an Aufgaben zum Sprachverstehen, also an etwas anderem als dem Fall hier. Für zwei Sitzungen desselben Modells bleibt es eine Überlegung, und sie lautet: Getrennt wird der Kontext. Das Modell und die Auf­ga­ben­be­schrei­bung bleiben dieselben, und ein Missverständnis, das schon im Auftrag steckt, überlebt die Trennung in beiden Sitzungen.

Woran man sieht, dass es stattgefunden hat

Die Kontrolle ist billiger als die Einrichtung, und sie besteht aus zwei Handgriffen.

Der erste ist der Nachweis, so wie es die Best Practices (externe Seite, code.claude.com) verlangen: Man lässt sich von Claude den ausgeführten Befehl samt Ausgabe zeigen, oder das Bildschirmfoto. Bei einer Sitzung, bei der man nicht zugesehen hat, ist das der einzige Beleg.

Bei testgetriebenem Arbeiten heißt das konkret: die Ausgabe des roten Laufs, nicht die Zusammenfassung davon. Ein Agent kann berichten, ein Test sei rot gewesen. Die Antwort kostet ihn dasselbe wie der Lauf.

Der zweite ist der Blick in den Unterschied. git diff auf das Testverzeichnis beantwortet die Frage, ob während der Implementierung jemand an der Erwartung gedreht hat, in zwei Sekunden. Wer die Tests vorher committet, wie es die Methode ohnehin nahelegt, sieht es noch schneller: Der Commit steht davor, und alles danach ist Implementierung.

Was davon sich wofür lohnt

Alles auf einmal einzurichten lohnt selten. Die Reihenfolge nach Nutzen je Aufwand:

1. Der Satz im Auftrag. Kostet nichts, wirkt sofort, deckt die betreute Sitzung ab.
2. Der Eintrag in der Projektanweisung. Eine Zeile, gilt in jeder Sitzung dieses Projekts.
3. Die Rechteregel auf das Testverzeichnis. Fünf Zeilen, und ab hier ist es kein Zureden mehr.
4. Der Haken vor dem Commit. Fängt auch, was neben Claude Code passiert.
5. Zielbedingung oder Stop-Hook. Für Läufe, bei denen niemand zusieht.
6. Die getrennte Sitzung. Für Stellen, an denen ein Fehler teuer wäre.

Wo die Methode aufhört

Zwei Einschränkungen zum Schluss, beide unangenehm.

Ein Tor misst, ob ein Test vorhanden ist. Über seine Güte sagt es nichts, und die Reihenfolge kann es gar nicht prüfen: Ob der Test vor dem Code entstand, sieht man dem fertigen Stand nicht an. Die Ver­si­ons­ge­schichte zeigt es, wenn getrennt committet wurde, und genau deshalb lohnt sich die Trennung. Ansonsten bleibt die Reihenfolge Vorsatz.

Und die Methode löst das Problem nicht, das sie an den Anfang stellt. Sie verlangt, dass jemand vorher weiß, was herauskommen soll. Bei einer klaren Aufgabe ist das leicht. Beim Erkunden einer unbekannten Schnittstelle ist es teuer, und dort ist ein Wegwerfversuch mit anschließendem Test der sinnvollere Weg. Der Satz, der die Grenze zieht, steht in demselben Leitfaden (externe Seite, code.claude.com), der die Stufen vom Satz im Prompt bis zur getrennten Prüfung aufzählt: Claude hört auf, wenn die Arbeit fertig aussieht. Hat es nichts, das ihm sagt, ob sie fertig ist, wird der Mensch zur Testsuite, und jeder Fehler bleibt stehen, bis ihn jemand zufällig bemerkt.

Das gilt für den Code. Es gilt genauso für die Prüfung darüber.