Das Werkzeug, das uns die Zügel reichen sollte, hatte selbst keine — Die Grenze zwischen Geschirr und Reins

Image: AI generated

Am 31. März 2026 veröffentlichte Anthropic im Claude Code npm-Paket (v2.1.88) versehentlich Source-Maps. Der Grund: eine fehlende Zeile in .npmignore.¹ 59,8 MB Source-Maps legten unverdunkelt rund 512.000 Zeilen TypeScript in etwa 1.900 Dateien offen. Anthropic bezeichnete den Vorfall als „keinen Sicherheitsbruch, sondern einen Fehler beim Deployment-Packaging — menschliches Versagen" und empfahl den Nutzern, auf v2.1.87 zu pinnen.

In der so einsehbaren Codebasis wies eine einzelne Funktion in einer Datei (print.ts) 3.167 Zeilen auf.²

Der meistverkaufte Coding-Agent der Welt, das Werkzeug, das damit wirbt, uns die Zügel über Code in die Hand zu geben — hatte für sich selbst keine Zügel angelegt.

Diese Ironie soll kein Spott sein. Das genaue Gegenteil: Dieser Vorfall ist die klarste Antwort auf eine Frage, auf die ich lange keine saubere Antwort gefunden hatte.

„Reins Engineering — ist das nicht letztlich harness engineering?"

Eine gute Frage. Eine scharfe dazu. Beide ähneln sich offensichtlich. Beide sind etwas außerhalb des Modells. Beide sind Nicht-Modell-Strukturen, die in Code gebaut werden. Beide verhindern, dass Agenten abirren. Der Verdacht „Zügel sind doch nur ein Teil des Geschirrs" ist also berechtigt.

Ich konnte auf diese Frage lange keine saubere Antwort geben. Als ich sie fand, erklärte diese Antwort selbst am präzisesten, was Reins ist. Und der oben genannte Leak beweist diese Antwort in der Praxis.

Zunächst: Beide stehen nicht im Widerspruch

Stellen wir uns ein Pferdegeschirr vor. Sattel und Zaumzeug auf dem Pferderücken, und die zwei Stränge, die vom Gebiss bis in Menschenhände reichen — die Zügel.

Die Zügel sind im Gebiss verankert. Sie stehen nicht außerhalb des Geschirrs, sondern sind ein daran montiertes Teil. Fragt man also „Sind Geschirr und Zügel klar verschieden, stehen sie im Widerspruch?", lautet die Antwort Nein. Beide sind Teile derselben Ausrüstung.

Hier muss man beginnen. Das geläufige Bild — „Geschirr ist der Zaun, Zügel sind die Steuerung" — stellt beide gegeneinander. In dem Moment, wo man das tut, verliert man. Ein einziges „Aber Validierungs-Gates sind doch auch Teil des Geschirrs" reicht, um das zum Einsturz zu bringen. Und das stimmt. CI, Typprüfung, Test-Suites — all das ist Scaffolding außerhalb des Modells, und das ist, was Geschirr umfasst.

Die Frage muss also anders gestellt werden. Nicht ob beide im Widerspruch stehen, sondern wo sie sich trennen.

Ab wann wird Reins möglich — drei Schichten von Schleifen

Bevor wir den Trennungspunkt finden, müssen wir sehen, ab wann Reins überhaupt möglich wird. In Schichten von Schleifen betrachtet, sind es drei.

① Chat-Schleife       LLM → Mensch → LLM               Alles probabilistisch. Kein Reins möglich.
② Agenten-Schleife    LLM → Ausführung → Beobachtung → LLM  Ausführung betritt deterministischen Boden → Reins möglich.
③ Reins-Schleife      ② + konzipierte Prüfer + Ratsche  Reins vollständig.

In der Chat-Schleife gibt es keinen Ort, an dem man das Gebiss anlegen könnte. Man ist noch nicht einmal aufgestiegen. Während das LLM antwortet, der Mensch liest und das LLM erneut befüllt, gibt es keinen einzigen deterministischen Moment. Es gibt kein Eisen, in das man ein Signal beißen lassen könnte.

Die Agenten-Schleife legt den Sattel auf. In dem Moment, wo Ausführung ins Spiel kommt — der Compiler läuft, Tests schlagen fehl, Dateien werden geschrieben — betritt die Schleife zum ersten Mal deterministischen Boden. Erstmals entsteht etwas, woran man greifen kann.

Genau hier liegt der Grund, warum Claude Code so überwältigend erfolgreich ist. Bash, Datei-I/O und Testausführung als deterministische Gates wurden (halb zufällig) in die Schleife eingebaut — damit war bereits ein „partielles Reins" vorhanden. Das gab es in der Chat-Ära nicht.

Das ist nicht nur meine Behauptung. Princetons HAL (Holistic Agent Leaderboard) zeigte in über 21.000 Agenten-Ausführungen, dass dieselben Modelle um Dutzende Prozentpunkte in der Genauigkeit schwanken, wenn nur das Scaffolding ausgetauscht wird.³ Das Modell war konstant — was sich änderte, war allein die Struktur drumherum. Addy Osmani bringt es auf eine Zeile: „Ein brauchbares Modell + ein exzellentes Geschirr schlägt ein exzellentes Modell + ein schlechtes Geschirr." Er bemerkte auch, dass dasselbe Opus in einem Custom-Harness höhere Punktzahlen erzielt als in Claude Code.⁴

Bis hierher ist das das Territorium, das die Branche als „harness engineering" bezeichnet. Eine richtige Entdeckung. Und genau das ist der Ort, wo man Reins leicht damit verwechselt. Denn beide erzeugen Ergebnisse außerhalb des Modells.

Aber ② ist nur die zufällige Hälfte von Reins. Reins Engineering ist die Arbeit, diese Hälfte bewusst zu vervollständigen. Den zufällig eingefügten Gate in einen konzipierten Prüfer mit Ratsche und Entscheidungs-/Implementierungstrennung zu verwandeln und ② auf ③ zu heben. Der Harness-Diskurs beweist Reins, aber ersetzt es nicht.

Drei Achsen

Zwei Menschen arbeiten mit einem Pferd.

Der eine fertigt das Geschirr. Die Maße des Sattels, die Festigkeit des Zaumzeugs, die Form des Gebisses. Das funktioniert für jedes Pferd, jede Reise gleich. Einmal gut gefertigt, ist es dasselbe Geschirr — ob man nach Hamburg oder München reitet. Der Fertigende ist der Geschirrmacher — nicht derjenige, der reiten wird.

Der andere hält die Zügel. Er kennt diese Reise. An welcher Weggabelung man nach links abbiegen muss, wo das Ziel liegt, wann man sagen kann „wir sind angekommen". Die Stränge in seiner Hand sind an demselben Geschirr befestigt, aber die Signale, die er sendet, unterscheiden sich bei jeder Reise. Derjenige, der die Signale sendet, ist nicht der Geschirrmacher, sondern der Reiter.

Drei Achsen liegen vor uns.

• Funktion. Geschirr begrenzt — eine Grenze dessen, was nicht getan werden darf. Reins führt — wohin es geht und wann es geendet hat.
• Lebensdauer. Geschirr wird einmal gefertigt und für alle Aufgaben wiederverwendet. Reins wird für jede Aufgabe neu konzipiert.
• Eigentümerschaft. Geschirr liefert der Anbieter aus. Reins verfasst der Architekt.

Claude Codes Schleife ist für jedes meiner Projekte gleich. Das ist Geschirr. Anthropic hat es gefertigt und ausgeliefert, es ist für alle Nutzer dasselbe. Aber „Mieterauszug = Fotos von fünf bestimmten Orten" als Definition von Vollständigkeit — das habe ich für diese Domäne selbst geschrieben. Kein Geschirr enthält das. Das sind Reins.

Abhängigkeit fließt in eine Richtung

Wenn beide dasselbe wären, dürfte man keines der beiden herauslösen, ohne dass das andere zusammenbricht. Versuchen wir es.

Geschirr vorhanden, aber kein Reins. Der Agent läuft. Er läuft ohne Unterbrechung. Er irrt nur. Er wandert durch ein Feld ohne Zielmarkierung und ohne Fertigstellungsurteil und hält an mit dem Gedanken „das dürfte ungefähr reichen". Das kennen wir bereits. Wir nennen es vibe coding.

Reins vorhanden, aber kein Geschirr. Das ist gar nicht möglich. Man hält die Zügel, aber es gibt kein Gebiss, in das man sie einhaken könnte. Kein Ort, an den man Signale senden kann. Man hält nur einen Strang in der Luft.

Die Abhängigkeit ist einseitig. Reins braucht Geschirr, aber Geschirr braucht Reins nicht. Geschirr funktioniert ohne Reins — nur schlecht. Diese Asymmetrie widerlegt „beide sind dasselbe" sauber. Wären sie dasselbe, müssten beide zusammenbrechen, wenn man eines herauslöst — aber Geschirr läuft alleine.

Der Überschneidungsbereich ist genau ein Feld

Gibt es also wirklich keine Überschneidung? Doch. Genau ein Feld.

Der ausgeführte Validierungs-Gate. CI läuft innerhalb der Agenten-Schleife. Diese Ausführungsfläche liegt auf beiden Seiten — sie ist ein Teil des Geschirrs, und zugleich ist es das, was Reins anlegt. Hier entsteht die Frage „Ist das nicht doch Geschirr?". Stimmt, in diesem einen Feld zeigen beide auf dasselbe.

Aber jenseits davon trennen sie sich.

   Nur Geschirr             Schnittmenge            Nur Reins
─────────────────    ─────────────────────    ─────────────────
 Sandbox · Rechte       Validierungs-Gate       Definition von Vollständigkeit
 Tool-Verdrahtung        (ausgeführter Check)    Cheese-Schutz-Design
 Kontext-Management                              Proxy↔Zweck-Analyse
 (richtungslose Eingrenzung)  (Ausführungsfläche)  (Absicht ohne Substrat)

Geschirr hat eigene richtungslose Eingrenzung — eine Sandbox sagt nicht, wohin man gehen soll, sie verhindert nur den Ausgang. Reins hat eigene Absicht ohne Ausführungssubstrat — die Definition von „was Vollständigkeit bedeutet" existiert, bevor ein Gate vorhanden ist, das sie durchsetzt. Keines der beiden enthält das andere vollständig. Beide schneiden sich. Sie umfassen sich nicht.

Warum die Frage nach der Teilmenge falsch gestellt ist

„Ist Reins also eine Teilmenge von Geschirr?"

Für eine Teilmenge müssen beide mit demselben Maßstab gemessen werden. Aber Geschirr wird definiert durch wer es ausliefert und wie oft es wiederverwendet wird (die Substrat-Achse), und Reins wird definiert durch was es mit der Trajektorie tut (die Funktions-Achse). Die Achsen sind verschieden.

Es ist, als würde man fragen: „Ist Rot eine Teilmenge von Schwer?" Etwas, das rot und schwer ist (= der ausgeführte Gate), gibt es — aber Farbe kann nicht in Gewicht enthalten sein. Weil das Messgerät verschieden ist. Die Teilmengen-Beziehung selbst ist hier ein Kategorienfehler.

Die genaue Beziehung lautet: Reins setzt Geschirr voraus, ist aber nicht in Geschirr enthalten. Eine daraufgelegte Schicht ist kein enthaltener Teil. Das Aufgelegte erstreckt sich über das Substrat hinaus.

Der eigentliche Trennungspunkt — Cheese

Bis hier war es eine strukturelle Betrachtung. Aber der Ort, wo Reins sich entscheidend vom Harness-Diskurs trennt, liegt woanders. Es ist Cheese — das Ausnutzen von Lücken in Spielregeln.

Spieledesigner wissen es. „Töte 10 Ratten" ist eine berüchtigte Quest. Zwischen dem, was der Gate prüft (10 tote Ratten), und dem, was der Designer wirklich wollte (dass der Spieler den Content erlebt), klafft eine Lücke — und Spieler dringen in diese Lücke vor. Das nennt man „cheese" (englisch für Käse, Spieljargon für das Ausnutzen unbeabsichtigter Lücken). Genau dasselbe Phänomen nennt KI-Sicherheitsforschung „Spezifikations-Gaming" — ein Boot-Rennen-Agent, der statt der Ziellinie immer wieder Punkt-Items einsammelt, ein Tetris-Agent, der das Spiel dauerhaft pausiert, um nicht zu verlieren.⁵

Auch mein Miete-Gate wird gecheest. Fünf Fotos prüfen „Fotos existieren", nicht „der Auszug verlief ordnungsgemäß". Was, wenn der Zuständige nur saubere Wände fotografiert? Der Gate wird passiert. In dem Moment, wo die Messung zum Ziel wird, versagt die Messung — das ist Goodharts Gesetz.⁶

Und jetzt zum Kern. Geschirr kann nur bis „wurde passiert?" antworten. Ob Tests grün sind, ob Typen stimmen, ob das Schema nicht gebrochen ist — bis dahin. Aber „Erfasst dieses Bestehen den Zweck?" kann Geschirr niemals beantworten. Denn was Cheese ist, lässt sich nur definieren, wenn man den Zweck der Domäne kennt. Warum ein Foto nur sauberer Wände eine Täuschung ist, warum alle Regeln erfüllt wurden und doch nur 90% des Zwecks eingelöst sind — das weiß nur, wer versteht, wozu diese Arbeit dient.

Das ist der Reiter. Derjenige, der die Zügel hält.

Ein Cheese-sicheres Gate zu konzipieren — die Punkte vorauszuahnen, an denen der Proxy dem Zweck nicht folgen kann — ist von Natur aus aufgaben-spezifisch, enthält Domänenwissen und wird vom Betreiber verfasst. Ein task-agnostisches Geschirr kann das nicht liefern. Nicht weil es es nicht will — sondern weil es die Domäne nicht kennt und daher damit gar nicht umgehen kann.

Hier liegt das eigenständige Territorium, das Reins Engineering besitzt und das im Harness-Engineering- sowie Agentic-Engineering-Diskurs fehlt. Dort spricht man davon, Geschirr besser zu machen. Reins spricht davon, durch welches Tor diese Reise — unbeschadet — gehen soll.

Zurück also zum Leak

Kehren wir zur anfänglichen Ironie zurück. Jetzt wird sichtbar, warum dieser Vorfall kein Spott, sondern ein Beweis ist.

Das Pferd war ein Genie. Opus ist probabilistische Kraft pur. Auch der Sattel funktionierte — Claude Code ist das weltbeste Geschirr, und HALs Zahlen beweisen das. Und doch driftete die mit diesem Geschirr erstellte eigene Codebasis genau in den vorhergesagten Fehlermodus. Eine Funktion mit 3.167 Zeilen. Das Bild der 200-Endpunkte-Wand, wie sie sich im Code manifestiert. Auch der Leak selbst — eine fehlende Zeile in .npmignore — bedeutet, dass im Deployment-Artefakt kein Gate vorhanden war.

Das Unternehmen, das das weltbeste Geschirr baut, hatte dieses Geschirr nicht im eigenen Stall angelegt.

Das ist kein Antithese, sondern der entscheidende Beweis für die These. Reins ist keine Eigenschaft, die ein Modell oder Agent besitzt — es ist eine Disziplin, die man anwendet. Dass ein Agent leistungsfähig ist und dass der mit diesem Agenten erstellte Code unter Reins steht, sind vollständig verschiedene Dinge. Ein größeres Modell ist nicht die Antwort. Ein besseres Geschirr auch nicht. Die Disziplin — die Zügel in der Hand zu halten, die Vollständigkeit dieser Reise selbst zu definieren und Gates zu konzipieren, die Cheese verhindern — das ist die Antwort.

Damit

Geschirr lässt das Pferd laufen. Reins bestimmt, durch welches Tor das Pferd gehen wird. Geschirr wird einmal angelegt und bleibt bestehen; Reins hält man in jedem Moment fest. Geschirr liefert der Handwerker aus; Reins hält der Reiter in der Hand.

Beide stehen nicht im Widerspruch. Sie sind verschiedene Teile desselben Geschirrs. Aber verschiedene Teile. Ohne Geschirr kann Reins nicht existieren; ohne Reins irrt Geschirr. Und wer weiß, ob diese Arbeit wirklich zu Ende ist — das ist immer die Hand, die die Zügel hält.

Wenn das nächste Mal jemand fragt „Ist das nicht einfach Geschirr?", antworte so:

„Geschirr wird vom Anbieter ausgeliefert; Reins ist das, was ich für diese Quest entwerfe. Kein Reins ohne Geschirr, aber Geschirr ohne Reins irrt nur. Selbst das Werkzeug, das uns die Zügel reichen sollte, hatte für seinen eigenen Code keine — weil Reins nichts ist, das man hat, sondern etwas, das man anlegt."

Weiterführende Lektüre (auf dieser Website)

• KI mit Zügeln: Reins Engineering — Ursprung des Gate-als-Zügel-Reframings
• Wer definiert „Fertig"? — Cheese-sichere Gates, Tasking als Quest-Design
• Warum Coding-Agenten funktionieren und warum sie scheitern — „Generierung darf probabilistisch sein, Verifikation muss deterministisch sein"
• Warum dein Agent nie anhält — Ein System, das anhalten kann = ein System, das Vollständigkeit definiert hat
• Yongol: Die Wand der 200 Endpunkte — Vom Betreiber verfasste Spezifikation = Reins in der Praxis

Externe Quellen

Die in diesem Artikel behandelte Grenze — Geschirr und Reins, das Anhalten, die gamingbare Spezifikation — von außen vertieft oder aus einem anderen Blickwinkel beleuchtet.

• How Coding Agents Work — Simon Willison — „Ein Coding-Agent ist ein Harness, der ein LLM umhüllt." Die kanonische Definition des Geschirrs, ideal als Einstiegslektüre.
• Agent Harness Engineering — Addy Osmani — Formalisiert Harness als eigenständige Ingenieursdisziplin. Behandelt mit dem „Sprint-Vertrag" die Abbruchbedingung — der direkteste Überschneidungspunkt mit diesem Artikel.
• Reward Hacking in Reinforcement Learning — Lilian Weng — Die theoretische Wirbelsäule von Goodharts Gesetz und Spezifikations-Gaming. Erklärt aus RL/RLHF-Perspektive, warum „Cheese" entsteht.
• Water Finds a Crack — Soren Johnson — „Wenn Spieler eine Gelegenheit sehen, optimieren sie das Spiel aus." Das menschliche Urbeispiel von Reward-Hacking — ein Game-Design-Klassiker.
• Effective Harnesses for Long-Running Agents — Anthropic — Der primäre Akteur selbst behandelt das Scheitern, „Fertig zu deklarieren, ohne wirklich fertig zu sein." Abbruchbedingungen und deterministische Verifikation in einem Artikel.