Harness Engineering: das Netz um den Agenten

Wo die zwei Handgriffe aufhören

In Die 79-Prozent-Falle standen am Ende zwei Handgriffe: vor dem Akzeptieren einen Fall benennen, in dem die Änderung falsch wäre, und in den Pull Request schreiben, was ungeprüft durchgegangen ist. Beide greifen, solange ein Mensch jede Änderung ansieht. Läuft der Agent Stunden allein und legt mehr vor, als jemand in einer Sitzung durchgehen kann, wird der Mensch vom Prüfer zum Engpass. Wie es dazu kam, steht in Von Vibe Coding zu Agentic Engineering. Die Handgriffe bleiben richtig, sie skalieren nur nicht mit. Die Frage lautet ab da nicht, wie man gründlicher prüft, sondern was prüft, während man nicht hinsieht.

Was ein Harness ist

Birgitta Böckeler bringt es auf eine Gleichung: Ein Agent besteht aus Modell und Harness. Harness heißt Geschirr, das Gurtzeug, mit dem ein Zugtier geführt wird. Wir nennen es hier das Netz um den Agenten. Das Modell erzeugt die Änderungen. Der Harness ist alles drumherum: die Werkzeuge, die der Agent aufrufen darf, die Regeldateien, die er zu Beginn liest, die Prüfungen, deren Ergebnisse bei ihm zurücklaufen. Am Modell kannst du nichts ändern, da wartest du auf die nächste Version. Am Harness kannst du alles ändern, und zwar heute.

Was dabei mit der Sorgfalt passiert, hat Chad Fowler beschrieben: Sie verschwindet nicht, sie zieht näher dorthin, wo die Wahrheit liegt. Das vertraute Kontrollsignal, das eigene Lesen jeder Zeile, fällt weg. Übrig bleibt die Frage, was der Code erfüllen muss, und die steht in Tests, Regeln und Prüfungen. Fowlers Muster dafür lautet: "probabilistic inside, deterministic at the edges."

Die Landkarte

Böckeler ordnet den Harness auf zwei Achsen. Die erste ist der Zeitpunkt: Was vor der Aktion wirkt, heißt bei ihr Guides, feedforward. Was danach misst und zurückmeldet, sind Sensors, feedback. Ab hier nennen wir sie Leitplanken und Messpunkte.

flowchart LR
  GUIDE["Leitplanken<br/>wirken vorher<br/>Regeldateien, Konventionen"] --> AGENT["Agent<br/>Modell plus Harness"]
  AGENT --> SENSOR["Messpunkte<br/>wirken nachher<br/>Tests, Linter, Reviews"]
  SENSOR --> LOOP["Rückkopplung<br/>was hat überrascht?"]
  LOOP -.->|"was sich bewährt"| GUIDE
  classDef guide fill:#1A3A4A,stroke:#00BCEC,color:#BAE6FD
  classDef agent fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5
  classDef sensor fill:#14532D,stroke:#22C55E,color:#86EFAC
  class GUIDE guide
  class AGENT agent
  class SENSOR,LOOP sensor

Die zweite Achse ist die Art der Prüfung. Die einen sind deterministisch, laufen in Sekunden und liefern ein verlässliches Ergebnis: Linter, Typprüfer, Tests, Strukturanalysen. Böckeler nennt sie computational. Die anderen sind erschließend, inferential: semantische Analyse, KI-Code-Review, ein Modell beurteilt ein anderes. Böckeler beschreibt sie als langsamer, teurer und weniger deterministisch. Eingesetzt werden sie trotzdem, weil sich für vieles keine Regel formulieren lässt. Der Aufräum-Agent, der weiter unten veraltete Doku meldet, ist ein erschließender Messpunkt. Ein Modell, das den Plan gegenliest, bevor der Agent loslegt, wäre eine erschließende Leitplanke.

Zwei Achsen ergeben vier Felder. Eines davon ist schnell besetzt, deterministische Prüfungen nach der Tat: Die Tests laufen, der Linter meckert, die Pipeline wird rot. Bleiben die anderen drei leer, wundert man sich, dass der Agent denselben Fehler noch einmal macht.

Karte statt Handbuch

Die naheliegendste Leitplanke ist eine Regeldatei: AGENTS.md, CLAUDE.md, je nach Werkzeug, alles an einer Stelle, was der Agent über das Projekt wissen muss. OpenAI hat das für die Arbeit mit Codex versucht und ausdrücklich als gescheitert beschrieben. Der Bericht nennt vier Gründe.

Der Kontext ist knapp: Jede Zeile aus der Regeldatei fehlt dem Agenten für die eigentliche Aufgabe. Wenn alles wichtig ist, ist nichts wichtig: Wo Namenskonventionen neben Architekturentscheidungen neben Formatierungsdetails stehen, ist keine Zeile hervorgehoben. Ab einer gewissen Länge zieht niemand die Datei mehr nach, sie veraltet also sofort. Und maschinell prüfen lässt sie sich nicht: Dass ihr Inhalt nicht mehr stimmt, merkt niemand, bis der Agent darauf etwas Falsches tut.

Was OpenAI stattdessen macht: Die AGENTS.md ist auf rund hundert Zeilen zusammengestrichen und funktioniert als Inhaltsverzeichnis. Die Wissensbasis liegt in einem docs/-Verzeichnis dahinter, dazu kommt ein Agent, der regelmäßig veraltete Dokumentation meldet und Korrekturen vorschlägt.

Bevor das zu gut klingt: Das ist ein Herstellerbericht über das eigene Werkzeug, nachgeprüft hat ihn niemand, und ein Projekt ohne Altlasten ist der günstigste Fall überhaupt. Übertragbar ist die Trennung dahinter.

Russ Miles kommt von der anderen Seite und landet am selben Punkt. In seinem offenen Repo ai-literacy-superpowers ist die HARNESS.md über tausend Zeilen lang und von Hand kuratiert, eigene Befehle propagieren daraus die Konventionsdateien, die der Agent im Alltag vorfindet. Sein Verfahren dazu erzählt er im Bootiful Podcast vom 16.07.2026. Der eine kürzt radikal, der andere generiert die kurze Fassung, die Trennung ist dieselbe: Was Menschen verstehen müssen, ist nicht das, was ins Kontextfenster gehört.

Bei uns sieht das so aus. CLAUDE.md und die Dateien unter .claude/rules/ sind die kuratierte Ebene, kurz gehalten und von Hand gepflegt. Alles, was nur für eine bestimmte Aufgabe gilt, steckt in Skills, die erst dann geladen werden. Was ein Skill ist und wie du einen einrichtest, steht in Skills erklärt. Als Leitplanke betrachtet ist ein Skill eine Regel, die keinen dauerhaften Platz im Kontext kostet.

Was sich leicht prüfen lässt

Böckeler nennt die erste Kategorie Maintainability Harness, also alles, was die interne Codequalität reguliert. Sie lässt sich am leichtesten bauen, weil die Werkzeuge dafür schon da sind: Linter, Formatierer, Typprüfer, Testrunner. Wie du daraus ein Gate machst, das niemand vergessen kann, steht in Quality-Gates gegen KI-Fehler, samt Git-Hooks.

Ein Punkt kommt dazu, sobald ein Agent den Code schreibt: Die Fehlermeldung hat einen zweiten Leser, der daraufhin handelt. Für einen Menschen reicht meistens "verboten", er weiß selbst, was stattdessen richtig ist. Ein Agent probiert die nächste plausible Variante, und du bezahlst eine weitere Runde. Eine Regel, die die Alternative mitliefert, wird beim ersten Versuch befolgt.

Unser Content-Linter blockt zum Beispiel Gedankenstriche, weil sie ein typisches Merkmal von KI-Text sind. Die Meldung lautet:

Gedankenstrich (\u2014) gefunden (Komma oder Bindestrich nutzen)

In der echten Meldung steht in der ersten Klammer das Zeichen selbst, hier die Unicode-Schreibweise, weil die Regel auch für diesen Artikel gilt. Worauf es ankommt, steht in der zweiten Klammer. Das ist die billigste Verbesserung am ganzen Harness: bessere Sätze in den Regeln, die schon da sind.

Regeln über die Form

Die zweite Kategorie lässt beiseite, was der Code tut, und prüft, wie er gebaut ist. Böckeler nennt sie Architecture Fitness Harness und fasst zusammen: "Basically: Fitness Functions."

Das klingt abstrakter, als es ist. In der Java-Welt gibt es dafür ArchUnit: Damit schreibst du eine Architekturentscheidung als Test auf, Klassen aus domain dürfen nichts aus infrastructure aufrufen. Verstößt jemand dagegen, wird der Test rot wie bei einem fachlichen Fehler. Die Entscheidung liegt dann in der Pipeline statt in einem Dokument, das niemand öffnet.

Für andere Sprachen gibt es Äquivalente: In TypeScript übernehmen das Importregeln in ESLint oder dependency-cruiser, in Python etwa import-linter.

Uns scheint, so eine Regel wiegt bei einem Agenten schwerer als bei einem Menschen. Ein Mensch hält Schichtgrenzen ein, weil er weiß, warum es sie gibt. Ein Agent sieht nur den Code in seinem Kontextfenster, und der kürzeste Weg zum grünen Test führt von dort oft quer durch die Architektur.

Böckeler nennt das Harnessability: Nicht jede Codebasis lässt sich gleich gut einspannen. Eine streng typisierte Sprache bringt den Typprüfer als Messpunkt schon mit, klare Modulgrenzen machen Architekturregeln überhaupt erst formulierbar. Fehlen diese Eigenschaften, lassen sich die passenden Prüfungen nicht bauen: "the harness is most needed where it is hardest to build." Wer eine gewachsene Skriptsammlung ohne Typen und ohne Grenzen betreut, braucht das Netz am dringendsten und hat am wenigsten, woran er es aufhängen kann. Modularisierung hat damit einen zusätzlichen Grund, und der entscheidet mit, wie viel Arbeit du einem Agenten übergeben kannst.

Die offene Flanke

Bleibt die dritte Kategorie, und das ist die, an der es hängt. Den Behaviour Harness nennt Böckeler den Elefanten im Raum: die Frage, wie du feststellst, ob die Anwendung fachlich das tut, was sie soll.

Hier rächt sich, wenn nur dieses eine Feld besetzt ist. Deterministisch prüfen nach der Tat heißt für fachliches Verhalten: Die Testsuite ist grün. Nur schreibt die Tests inzwischen oft derselbe Agent, der auch den Code geschrieben hat. Böckeler beschreibt das als heute übliches Vorgehen und urteilt klar: "This approach puts a lot of faith into the AI-generated tests, that's not good enough yet."

Was heute hilft, ist nicht neu. Akzeptanztests, die vor der Aufgabe stehen und die der Agent erfüllen muss. Property-based Testing, das Grenzfälle sucht, statt zu warten, bis jemand sie aufzählt. Und einmal den echten Nutzerweg durchspielen, von Hand oder automatisiert.

Alle drei prüfen gegen eine Spezifikation. Ist die falsch, prüfen sie den falschen Zustand sehr gründlich, und am Ende ist alles grün. Ob das Richtige beschrieben war, beantwortet keines dieser Werkzeuge.

Wir haben nachgesehen, ob sich seit Böckelers Artikel vom 02.04.2026 etwas bewegt hat. Gefunden haben wir nichts. Ihre Anschlussveröffentlichung mit Chris Ford vom 13.05.2026 vertieft nur die Messpunkt-Seite und kündigt vorkonfigurierte Bündel für Anwendungstypen an, fachliches Verhalten kommt nicht vor. Ihr Satz vom April steht also unverändert: "So overall, we still have a lot to do to figure out good harnesses for functional behaviour that increase our confidence enough to reduce supervision and manual testing."

Das ist keine schlechte Nachricht, sondern eine Ortsangabe. Der Harness nimmt dir Formatierung, Struktur und Regressionen ab, nicht die Frage, ob das Richtige gebaut wird. Genau dorthin gehört die Aufmerksamkeit, die anderswo frei geworden ist.

Wie der Harness wächst

Bis hierher klingt das nach etwas, das man einmal aufstellt. So funktioniert es nicht. Böckeler beschreibt die Aufgabe des Menschen als Nachziehen: "Whenever an issue happens multiple times, the feedforward and feedback controls should be improved to make the issue less probable to occur in the future, or even prevent it." Ein Fehler, der sich wiederholt, ist kein Charakterzug des Modells, sondern eine fehlende Leitplanke oder ein fehlender Messpunkt.

Nur passiert das nicht von allein. Nach einer Sitzung ist die Aufgabe erledigt, der Kopf beim nächsten Ticket, und die Beobachtung, dass irgendwas komisch lief, ist am Nachmittag weg. Es braucht einen Moment, an dem sie eingesammelt wird.

Russ Miles macht daraus im Bootiful Podcast ein kleines Verfahren. Am Ende einer Sitzung steht eine einzige Frage: Was hat uns beide überrascht? Die Antworten bleiben zunächst Vorschläge. Sie landen in einem Log im Repository, und erst später entscheidet das Team, was in die Regeln wandert. Sein oben verlinktes Repo steht laut Lizenzdatei unter Apache 2.0, auch wenn GitHub kein Badge dazu anzeigt.

Die Frage nach der Überraschung ist dabei nicht Kosmetik. Wer nach Fehlern fragt, bekommt Rechtfertigungen und Symptome. Wer nach Überraschungen fragt, bekommt die Stellen, an denen die eigene Erwartung nicht zum Werkzeug passte, dazu die Fälle, in denen etwas unerwartet gut lief. Auch die sind brauchbar: Wenn der Agent etwas hinbekommt, das man ihm nicht zugetraut hätte, war die Leine zu kurz.

Ein Eintrag braucht drei Zeilen: was überrascht hat, was daraus folgen könnte, der Stand. Einer aus der Arbeit an diesem Artikel:

## 13.08.2026

**Überrascht hat:** Der Agent hat die Umlautregel im Fließtext sauber
befolgt und im Codeblock direkt daneben wieder Ersatzschreibungen
benutzt. Die Regel steht in CLAUDE.md, ohne den Fall zu nennen.

**Könnte daraus folgen:** Linter-Regel auf Codeblöcke ausweiten, statt
den Regeltext zu verschärfen.

**Status:** offen

Das Muster dahinter: Die Regel stand da, sie war nicht falsch, sie nannte den Fall nur nicht. Formal war nichts kaputt, und ohne die Frage hätte niemand hingesehen.

Dass im Status "offen" steht und nicht "erledigt", ist der zweite Teil des Verfahrens. Wer jede Beobachtung sofort in die Regeldatei schreibt, hat nach ein paar Wochen das Dokument, das OpenAI als gescheitert beschrieben hat, und niemand weiß mehr, welcher Vorfall hinter welcher Zeile steckt. Retrospektiven trennen aus demselben Grund Sammeln und Entscheiden. Wer schon einmal eine moderiert oder ein Incident-Review geschrieben hat, kennt das Format. Neu ist nur, worauf es zeigt: nicht auf den Agenten und nicht auf das Team, sondern auf das Netz zwischen beiden.

Wie eng du führen musst

Ein Harness soll nicht jeder Aufgabe die Aufsicht abnehmen. Böckeler formuliert das Ziel so: "A good harness should not necessarily aim to fully eliminate human input, but to direct it to where our input is most important." Wo das ist, beantwortet sie im CaSE-Podcast mit einer Risikoabschätzung vor der Aufgabe, sinngemäß in drei Fragen.

Wie wahrscheinlich bekommt die KI das hin? Was passiert, wenn nicht? Und würde ich es überhaupt merken?

Die dritte trägt am meisten und wird nach unserem Eindruck am seltensten gestellt. Ein Fehler, der die Pipeline rot macht, ist billig, weil er sich selbst meldet. Teuer ist der, der grün durchgeht: eine Berechnung, die knapp danebenliegt, eine Bedingung, die im Normalfall stimmt, eine Migration, die auf einer leeren Tabelle funktioniert. Woran generierter Code knapp vorbeizielt, steht in KI-Code: Fast richtig reicht nicht.

Aus den Antworten ergibt sich die Leinenlänge, und die hat mehr als zwei Stufen. Kleine Aufgabe mit lauten Messpunkten: laufen lassen, Ergebnis ansehen. Wird es teurer oder leiser, lass dir erst den Plan geben, denn ein falscher Plan fällt auf einer Seite auf und im langen Diff nicht mehr. Und bei dem, was still kaputtgehen kann, liest du Zeile für Zeile wie früher, ohne dich rückständig zu fühlen.

Diese Einschätzung hat dieselbe Richtung wie der Rest des Harness. Das Prinzip dahinter heißt bei Böckeler Keep quality left: "You want to have checks as far left in the path to production as possible, since the earlier you find issues, the cheaper they are to fix." Einen Plan liest du in einer Kaffeepause, einen fertigen Pull Request nicht mehr, und was erst in Produktion auffällt, kostet ein Vielfaches.

Wo wir selbst stehen

Damit das nicht nach einer Empfehlung für andere klingt: unser Stand, am 13.08.2026 im Repository nachgezählt.

Die linke Spalte ist die leichte Hälfte: deterministische Prüfungen auf Textform und Frontmatter, an einem Nachmittag gebaut, am nächsten Tag wirksam. Die rechte macht Arbeit, und am meisten stört uns die erste Zeile: Wir empfehlen ein Verfahren, das wir bisher nur anlassbezogen anwenden. Das ist eher die Reihenfolge, in der so ein Netz entsteht, als ein Versäumnis.

Womit du anfängst

Drei Schritte, nach Wirkung sortiert.

Die eine Frage nach der nächsten Sitzung, zwei Minuten. Was hat uns beide überrascht? Die Antwort in eine Datei im Repository, Status "offen", mehr nicht. Das ist der einzige Schritt, der weiterwächst, weil er die Beobachtungen für die anderen einsammelt.

Die erste eigene Linter-Regel, eine halbe Stunde. Nimm den Fehler, der bei euch ständig wiederkommt, und schreib die Prüfung dafür. Entscheidend ist nicht die Regel, sondern der Satz, den sie ausgibt: Er muss sagen, was stattdessen zu tun ist.

Die Regeldatei aufteilen, ein Nachmittag. Vorne eine kurze Karte mit dem, was immer gilt, dahinter die ausführlichen Dokumente, die nur bei Bedarf dazukommen. Das lohnt sich, sobald niemand mehr die ganze Datei liest, bevor er etwas darin ändert.

Keiner der drei braucht ein besseres Modell, eine Freigabe oder ein Budget. Sie verschieben nur, wie viel davon abhängt, dass gerade jemand hinsieht.