Die Regel hast du geschrieben. Den Check nie gebaut.

pnpm test:integration hat das public-Schema meiner Datenbank gewiped. Viermal, bei vier verschiedenen Runs. Der Grund: eine Migrations-Testdatei droppt und baut public in beforeAll und afterAll neu auf, und sie fiel auf DATABASE_URL zurück, sobald TEST_DATABASE_URL nicht gesetzt war. Kein Race Condition, kein exotischer Bug — nur ein ??-Fallback an der falschen Stelle, viermal übersehen.

Danach hab ich eine Regel geschrieben: database-safety.md. Präzise, mit dem Vorfall selbst als erster Absatz dokumentiert, damit niemand — auch kein Agent — den Kontext verliert. Und trotzdem: Bis heute gibt es in dem Repo keinen einzigen automatisierten Check, der eine zukünftige Verletzung dieser Regel abfängt, bevor sie läuft. Nur die eine Datei, die den Schaden verursacht hat, wurde von Hand korrigiert.

Was ein Harness eigentlich ist#

Stell dir zwei Kletterer vor. Der eine klettert frei, ohne Sicherung — jeder Griff ist Glück, ein Fehler ist der letzte. Der andere klettert am Klettersteig: fixiertes Seil, Trittstifte, alle paar Meter ein Einhak-Punkt. Derselbe Kletterer. Nur einer von beiden kommt zuverlässig oben an. "Harness" heißt im Englischen wörtlich: Klettergurt.

Agent = Model + Harness, wie es Martin Böckeler (Thoughtworks, via martinfowler.com) auf den Punkt bringt. Das Model denkt — es generiert Text, schlägt Aktionen vor. Der Harness ist alles, was aus diesem Denken etwas Shippbares macht, und er zerfällt in zwei Hälften:

Guides (die vorbereitete Route) — was das Verhalten steuert, bevor gehandelt wird: System-Prompt, AGENTS.md, Skills, Rule-Files.
Sensors (die Einhak-Punkte) — was nach jedem Zug prüft: Tests, Linting, ein CI-Check, ein Script, das hart failt.

Zusammen bilden sie einen Loop: das Model nutzt die Guides, handelt, die Sensors prüfen das Ergebnis, das Feedback fließt zurück in die nächste Runde. Guide ohne Sensor heißt: die Regel wird kodiert, aber niemand erfährt, ob sie überhaupt greift. Sensor ohne Guide heißt: das System merkt jeden Fehler, wiederholt ihn beim nächsten Mal aber trotzdem, weil nichts das Verhalten vorher steuert.

Zwei echte Zahlen machen die Lücke konkret. Mit nichts als Bash-Terminal und Text-Editor erreicht Claude 3.5 Sonnet 49 % auf SWE-bench Verified. Mit durchgebautem Harness berichtet Ryan Lopopolo (OpenAI) von einem 3-Personen-Team, das über 1 Million Zeilen Code und rund 1.500 Pull Requests produziert hat — keine Zeile davon von einem Menschen geschrieben oder vor dem Merge reviewt. Gleiche Grundfähigkeit des Models, komplett andere Größenordnung.

Fast jeder baut Guides. Fast niemand baut die Sensoren dazu — und man merkt's erst, wenn's zu spät ist.

Warum eine gute Regel sich wie genug anfühlt#

database-safety.md ist kein schwammiger Vorsatz — sie benennt den exakten Fallback, der verboten ist, sie erklärt, warum Schema-Isolation in einem Fall reicht und im anderen nicht. Das ist gutes Guide-Engineering, und es hält, wenn jemand die Datei vor dem Schreiben eines neuen Tests liest. Die Bruchstelle ist genau dieses Wenn: eine Regel, die niemand automatisiert prüft, ist nicht sicherer als gar keine Regel, sobald die nächste Testdatei denselben Fallback nimmt wie beim ersten Mal. Man merkt eine fehlende Sensor-Schicht nicht, während man baut. Man merkt sie beim vierten Wipe.

Zwei Muster, eine Lücke#

billing-stripe.md sagt nicht nur, was zu tun ist — sie endet mit einer Anweisung, die tatsächlich läuft: vor dem Publizieren eines bezahlten Angebots scheitert pnpm db:validate-bindings hart, wenn ein Preis-Binding fehlt oder die Livemode nicht zum Secret passt. Das funktioniert, weil "richtig" hier ein Feldabgleich ist — ein computational sensor reicht.

Für database-safety.md gibt es kein Äquivalent. Sieben Rule-Files, vier Skills im Repo — genau eines hat einen belegbar laufenden Sensor. Die Regel, die aus dem teuersten Vorfall entstand, hat keinen. Sie fühlt sich erledigt an, weil der Text gut ist. Ist sie aber nicht, bis ein Script dieselbe Prüfung übernimmt, die die Datei bisher nur verspricht.

Nicht jede Prüfung lässt sich auf einen Feldabgleich reduzieren. Sobald die Frage nicht mehr "ist das Feld leer" ist, sondern "ist das Ergebnis inhaltlich richtig", brauchst du ein Urteil, kein Regex — Böckeler nennt diese Dimension Behaviour, die am wenigsten gelöste der drei Dinge, die ein Harness regulieren muss. Der Fallback dafür ist ein zweites Modell als Judge, aber das ist Risikominderung, keine Lösung: Qualität, Scope und Kalibrierung dieses Judge-Modells werden selbst zur Design-Entscheidung.

Der Test, der bei dir sofort funktioniert#

Ich hab mein eigenes Repo durchgezählt, nicht geraten: sieben Regeln, vier Skills, ein einziger belegter Sensor. Mach denselben Check an deinem eigenen Setup. Nimm eine Regel, einen Skill, eine AGENTS.md-Anweisung. Frag nicht, was das Modell tun soll — frag, woran du in sechs Monaten merkst, dass es aufgehört hat zu funktionieren. Keine Antwort — kein Script, kein Test, kein CI-Check? Dann hast du einen Wunsch mit guter Formatierung, keinen Harness.