Die Regel hast du geschrieben. Den Check nie gebaut.

pnpm test:integration hat das public-Schema meiner Datenbank gewiped. Nicht einmal — 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 Hard Rules, 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. Alles andere hängt daran, dass jemand — ich, oder ein Agent — die Markdown-Datei vorher liest.

Okay, aber was ist ein Harness überhaupt?#

Stell dir zwei Kletterer vor. Gleiche Wand, gleiches Können. 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.

Und "Harness" heißt im Englischen wörtlich: Klettergurt.

Ein AI Harness ist genau das — die Ausrüstung um das Model herum. Agent = Model + Harness, wie es Martin Böckeler (Thoughtworks, via martinfowler.com) auf den Punkt bringt. Das Model denkt: es generiert Text, trifft Entscheidungen, schlägt Aktionen vor. Der Harness ist alles drumherum, das aus diesem Denken etwas macht, das man tatsächlich shippen kann.

Vier Teile gehören dazu, jeder mit seinem Gegenstück am Klettersteig:

• Kontext (die Trittstifte) — was das Model bei jedem Call überhaupt sieht: Konversation, abgerufene Dokumente, aktueller State. Ohne sie fängt jeder Schritt wieder bei null an.
• Tools (das Fixseil) — was das Model tun kann: eine Datei lesen, einen API-Call machen, im Browser klicken. Das Seil bewegt dich vorwärts, Denken allein tut das nicht.
• Guides (die vorbereitete Route, Feedforward) — was das Verhalten steuert, bevor gehandelt wird: System-Prompt, AGENTS.md, Skills, Rule-Files. Jemand ist die Wand schon einmal abgeklettert und hat die Route markiert.
• Sensors (die Einhak-Punkte, Feedback) — was nach jedem Zug prüft, ob du noch gesichert bist: Tests, Linting, ein CI-Check, ein Script, das hart failt.

Guides und Sensors bilden zusammen 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. Erst beide zusammen korrigieren sich selbst.

Das ist keine hübsche Analogie ohne Substanz — zwei echte Zahlen zu genau diesem Gegensatz. Free Solo, minimale Ausrüstung: Claude 3.5 Sonnet erreicht 49 % auf SWE-bench Verified mit nichts als einem Bash-Terminal und einem Text-Editor als Tools. Voller Klettersteig: Ryan Lopopolo (OpenAI) berichtet von einem 3-Personen-Team, das mit einem durchgebauten Harness ü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. Nicht "Free Solo schlecht, Klettersteig gut" — du musst nur wissen, an welcher Wand du gerade kletterst.

So weit die Theorie. Jetzt meine These.#

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#

Naive Sicht, und sie ist nicht dumm: Eine klar geschriebene Regel ist schon die halbe Miete. 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, sie sagt genau, welche Statements schema-qualifiziert sein müssen. Das ist gutes Guide-Engineering. Wenn jemand — Mensch oder Agent — sie vor dem Schreiben eines neuen Tests liest, hält sie.

Die Bruchstelle: Wenn. Eine Regel, die niemand automatisiert prüft, ist nicht sicherer als gar keine Regel, sobald die nächste neue Testdatei denselben Fallback nimmt wie beim ersten Mal — process.env.TEST_DATABASE_URL ?? process.env.DATABASE_URL sieht harmlos aus, bis ein Environment ohne TEST_DATABASE_URL läuft. Man merkt eine fehlende Sensor-Schicht nicht, während man baut. Man merkt sie beim vierten Wipe.

Drei Muster, die tatsächlich im selben Repo nebeneinander existieren#

1. Guide + Sensor, richtig gepaart#

billing-stripe.md sagt nicht nur, was zu tun ist — sie endet mit einer Anweisung, die tatsächlich läuft: "Before publishing a paid offering ... run pnpm db:seed followed by pnpm db:validate-bindings." Das Script scheitert hart, wenn ein Preis-Binding fehlt, der Modus falsch ist, oder die Livemode nicht zum Secret passt. Tradeoff: Das funktioniert, weil "richtig" hier ein Feldabgleich ist — existiert die Price-ID, stimmt das Flag. Ein computational sensor reicht.

2. Guide ohne Sensor, die teure Lücke#

database-safety.md — präzise, aus einem echten Incident entstanden, und trotzdem ohne jeden automatisierten Gegencheck im Repo. Sieben Rule-Files insgesamt, vier Skills. Genau eines der Rule-Files hat einen belegbar laufenden Sensor. Die Regel, die aus dem teuersten Vorfall entstand, hat keinen. Tradeoff: fühlt sich erledigt an, weil der Text gut ist — ist es aber nicht, bis ein Script dieselbe Prüfung übernimmt, die gerade nur eine Markdown-Datei verspricht.

3. Wo kein reiner Sensor reicht#

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. Martin Böckeler (Thoughtworks, via martinfowler.com) nennt genau diese Dimension — er nennt sie Behaviour — explizit 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: die Qualität, der Scope und die Kalibrierung dieses Judge-Modells werden selbst zur Design-Entscheidung, nicht zum Abhaken.

Der Test, der bei dir sofort funktioniert#

Bevor ich das hier geschrieben hab, hab ich mein eigenes Repo durchgezählt, nicht geraten. Sieben Regeln, vier Skills, ein einziger belegter Sensor. Das war mir vorher nicht bewusst — und ich schreibe diese Regeln selbst.

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 keinen Harness an dieser Stelle. Du hast einen Wunsch mit guter Formatierung.