Zum Inhalt springen

Wissensbasis

Harness-Grundlagen

Die Komponenten und Kontrollschichten, die aus einem Modell einen verlässlichen Engineering-Agenten machen.

Verfasst von

Aktualisiert:

Software Factories 5

Die Komponenten und Kontrollschichten, die aus einem Modell einen verlässlichen Engineering-Agenten machen.

Was ein Harness ist

Das Wort “Harness” hat drei Bedeutungen, und nur eine davon behandelt diese Seite. Ein Eval-Harness misst die rohen Fähigkeiten eines Modells. Er füttert tausende standardisierte Fragen ein (MMLU, HumanEval) und bewertet die Genauigkeit. Das kanonische Beispiel ist EleutherAIs lm-evaluation-harness, für Anwendungsarbeit spielt er keine Rolle. Ein Client-Harness ist die Anwendung, die einem sonst zustandslosen Textvorhersager Hände gibt. Cursor, Windsurf, Claude Code und OpenCode verwalten das Kontextfenster, rufen die API auf und erlauben dem Modell, Dateien zu lesen und Befehle auszuführen. Diesen Harness kauft oder installiert ihr, er ist das Fahrzeug, das ihr fahrt. Den Projekt-Harness baut ihr selbst. Er ist die eigene, repository-spezifische Infrastruktur, die die Arbeit des Agenten begrenzt, lenkt und prüft. Er besteht aus Test-Suites, Type-Checking-Konfigurationen, zentraler Dokumentation und den Agent-Config-Dateien, die das Tool bei jeder Aufgabe liest.

Ist das Modell der Motor und der Client-Harness das Fahrzeug, dann ist der Projekt-Harness die befestigte Straße. Er liefert Fahrbahnmarkierungen und Guardrails, ohne die ein starker Agent im Graben landet. Harness Engineering heißt, diese Guardrails zu bauen. Engineers schreiben dann keine Implementierungslogik mehr. Sie gestalten die Umgebung, die den Agenten dazu bringt, von selbst korrekte Logik zu schreiben.

Ein Interview aus der Praxis zieht dieselbe Linie mit anderen Begriffen. Die Tools und Integrationspunkte, die ein Coding-Client bietet, heißen dort innerer Harness. Die repository-spezifische Umgebung und die Anpassungen, die ein Team darum baut, heißen äußerer Harness (Interview zu Context Engineering (öffnet in einem neuen Tab), Juli 2026, Praxis und Anbieter). Im äußeren Harness landet die eigene Arbeit des Teams, und er hebt die Qualitätsuntergrenze jedes Turns, den der Agent macht (Interview zu Context Engineering (öffnet in einem neuen Tab), Juli 2026, Praxis und Anbieter).

Ein zweiter Praxisbericht weitet den Rahmen und stellt den Harness in einen Stack aus vier Schichten. Jede Schicht verlangt eine eigene Build-or-buy-Entscheidung. Unten steht das Compute, auf dem die Agenten laufen, darüber die Entwicklungsumgebung, in der sie handeln, dann der Harness selbst. Ganz oben verteilt eine Control Plane die Arbeit, hält Session-Traces fest und verwaltet Budgets. Die Aufteilung lohnt sich, weil ein Team pro Schicht entscheidet statt für den ganzen Stack. Es kann Compute mieten und einen fertigen Client-Harness übernehmen, während es seine eigene Control Plane baut. Selbst besitzen sollte es die Schicht, in der seine Randbedingungen ungewöhnlich sind (Boundary - How to Build a Software Factory for AI Coding Agents (öffnet in einem neuen Tab), August 2026, Praxis und Anbieter).

Dasselbe Gespräch nennt die Schnittstellen zwischen den Schichten als Schwachstelle. Die offenen Kandidaten zwischen Control Plane und Harness sind eng gefasst. ACP verbindet einen Coding-Harness mit einem Editor oder einer Web-App, AG-UI überträgt die Interface-Events eines Harness. Keiner der beiden unterstützt Hooks, also die Lifecycle-Events, auf die eine Control Plane reagieren muss. Bei Hooks unterscheiden sich Harnesses auch am stärksten. Claude Code, Codex, pi und OpenCode bieten jeweils ein anderes Modell an, deshalb bezweifeln die Hosts, dass eine gemeinsame Abstraktion schon möglich ist. Ihre Kritik an heutigen Produkten gilt der Bündelung. Wer eine Schicht kauft, kauft meist jede Schicht darunter mit. Ein Team, das nur Orchestrierung will, übernimmt so auch Harness und Sandboxes eines Anbieters. Mit Komposition könnte es pro Schicht wählen. Nach ihrer Darstellung behalten Enterprise-Kunden Compute und Teile der Entwicklungsumgebung selbst. Den Harness wollen sie austauschbar halten, weil sich Harnesses schneller ändern als der Rest des Stacks. Eine gemeinsame Open-Source-Control-Plane erwarten sie so bald nicht. Diese Schicht kodiert, wie jede Firma Arbeit definiert, etwa was als Issue zählt, und sie ist heute billig zu schreiben (Boundary - How to Build a Software Factory for AI Coding Agents (öffnet in einem neuen Tab), August 2026, Praxis und Anbieter).

In the loop, on the loop, above the loop

Ein Projekt-Harness verändert, wie Entwickler:innen gedanklich zum Code stehen. Dieses Verhältnis durchläuft drei Phasen. In the loop ist die alte Agentenarbeit. Der Mensch handelt selbst, promptet jeden Schritt, liest jeden Diff und führt jeden Check von Hand aus. Seine Lesegeschwindigkeit bleibt damit der harte Bottleneck für die Velocity des Teams (die Velocity-Falle). On the loop ist moderne Harness-Arbeit. Entwickler:innen tippen keine Implementierung mehr und führen die Disziplinen nicht mehr von Hand aus. Sie verdrahten Kontext, Spec, Tests und Gates einmal im Harness und überwachen das Ergebnis eine Abstraktionsebene höher.

Der entscheidende Schritt: Scheitert der Agent, reparieren sie den Harness statt des Codes. Ein halluziniertes Schema heißt, dass dem Harness eine Constraint fehlt. Sie ergänzen also den Test, der das Verhalten festnagelt, oder schärfen den Kontext und lassen den Agenten neu ansetzen. Die ganze Fehlerklasse kehrt danach viel seltener zurück, weil die Constraint jetzt im Harness lebt statt im Gedächtnis der Entwickler:innen. Above the loop beschreibt den künftigen Zustand, in dem Menschen Flotten spezialisierter Agenten steuern. Ein Architekt-Agent entwirft den Harness, ein Coder-Agent setzt um, ein Auditor-Agent versucht den Code zu brechen. Für die meisten Enterprise-Teams ist das noch experimentell, und es setzt voraus, dass sie die Arbeit on the loop beherrschen.

Diese Abfolge bildet die individuelle Hälfte einer Leiter, die sich in die Organisation fortsetzt. Die Meisterschaft on the loop gipfelt im Fleet Commander, der parallele Agenten steuert, aber selbst noch der Motor ist. Fällt diese Person weg, kühlt die Factory ab. Die nächste Sprosse ist der Factory Operator. Er baut das System, das die Agenten ohne einen Menschen in jedem Loop laufen lässt.

Die Framings der Branche laufen auf dieselbe Leiter zu. Onas AI-SDLC-Framework nennt drei Stufen. In the loop handelt der Mensch selbst, und die Gewinne bleiben begrenzt. On the loop orchestriert eine Entwickler:in parallele Agenten “the way a manager checks in on direct reports”. Bei autonomous loops startet ein Trigger wie ein Incident oder ein Ticket eine Kette, in der ein Agent zerlegt, einer fixt, einer reviewt und einer testet. Die Stufen sind keine aufeinanderfolgenden Gates. Die operative These des Frameworks lautet, dass sich der Bottleneck mit jeder Stufe verschiebt:

  • Auf Stufe eins wandert er zum Review, bei 3- bis 5-mal so vielen PRs, und verlangt automatisierte Quality Gates.
  • Auf Stufe zwei wandert er zu allem vor und nach dem Code, also zu Planungsdisziplin sowie CI/CD- und Release-Durchsatz.
  • Auf Stufe drei wandert er zur Organisation selbst, “the quality of human judgment at the top” (Ona – The AI-SDLC Framework (öffnet in einem neuen Tab), 2026).

Onas Field CTO formuliert das Factory-Versprechen in denselben Begriffen, “incrementally moving the human out of the loop within the SDLC”. Die schwächere Lesart, dass eine Engineer:in viele parallele Agenten betreibt, lehnt Onas Field CTO ausdrücklich ab (Ona – The Missing Primitive for Agent Swarms (öffnet in einem neuen Tab), 2026).

In Chatto is Robots teilt ein:e Praktiker:in eine Codebasis in weiche und feste Bereiche. Weiche Bereiche ändern sich leicht, feste tragen alles um sich herum. Diese Aufteilung entscheidet, wohin die Aufmerksamkeit geht. Vor jedem Code steht die Liste der geänderten Dateien, damit klar ist, was der Diff berührt, bevor jemand ihn bewertet. An den festen Stellen, also Protokolldefinitionen, öffentlichen APIs und Routing, wird genau gelesen und von Hand reviewt. In den weichen Bereichen fangen Tests und Konventionen die Fehler ab, weil sich ein Fehlgriff dort billig rückgängig machen lässt. Der Orchestrator folgt derselben Logik. Er hält an den Grenzen von Task, Review und Merge einen Menschen im Loop, statt volle Automatisierung anzustreben. Die Begründung lautet, dass sich Urteilsvermögen genau dort noch auszahlt. Das ist der Bericht einer einzelnen Person darüber, wie ihr Workflow läuft, keine kontrollierte Studie und kein allgemeiner Befund. (Chatto is Robots (öffnet in einem neuen Tab), 16. Juli 2026)

Die sechs Komponenten eines Harness

Ein vollständiger Projekt-Harness macht die drei Disziplinen Kontext, Intent und Feedback greifbar. Dazu kommt die Fähigkeitsschicht, die ein Agent zum Handeln braucht. Sechs Komponenten halten den Agenten, gruppiert nach ihrer Aufgabe: was er vor dem Handeln wissen soll, was er beim Handeln tun kann und wie seine Arbeit geprüft wird, bevor sie landet.

  • Wissen: Regeln und Kontextmanagement. Regeln enthalten, was der Agent nicht selbst herausfinden kann. Gemeint sind Konventionen und Hinweise, die weder im Modell stecken noch verlässlich aus einer Brownfield-Codebasis folgen, die stellenweise inkonsistent oder falsch ist. Sie tragen die Architekturgrenzen, die den Blast Radius des Agenten klein halten. Sie zwingen etwa jeden Datenbankzugriff durch einen Ordner repositories/, sperren ein Modul während eines Rewrites oder zeigen auf den einen Service, der ein Muster richtig umsetzt. Sie kommen über eine Agent-Config-Datei hinein, die das Tool bei jeder Aufgabe liest, manchmal eine gemeinsame AGENTS.md. Kontextmanagement steuert Retrieval und Memory. Beim Retrieval sorgen dichte, auffindbare Karten dafür, dass der Agent die relevanten Teile lädt, ohne das Fenster zu sprengen. Beim Memory wird aktiv entfernt, was nicht mehr gilt.
  • Tun: Tools und Skills. Tools geben dem bloßen Textvorhersager Hände. Er führt einen Testbefehl aus, liest eine Datei, fragt eine Datenbank ab oder ruft eine API auf. Das Model Context Protocol ist ein offener Standard, um eine Fähigkeit einmal anzubinden, sodass jeder MCP-fähige Client sie erreicht. Teams greifen dazu, wenn dem Client-Harness eine Fähigkeit von Haus aus fehlt. Skills sind wiederverwendbare Pakete aus Instruktionen und Skripten, die das Modell selbst aufruft und der Agent bei Bedarf hereinholt. Die wichtigsten sind die Prozessschritte, die Engineers früher von Hand ausgeführt haben, etwa erst die Spezifikation schreiben und dann Tests red-then-green. Als Paket ruft der Harness sie in der richtigen Reihenfolge auf, und das Vorgehen steht einmal geschrieben, statt in jedem Prompt neu erklärt zu werden.
  • Prüfen: Hooks und Verification Gates. Hooks sind die Reflexe des Harness. Diese deterministischen Aktionen feuern an festen Punkten im Loop, formatieren etwa eine Datei beim Speichern oder blocken einen Befehl auf einem verbotenen Pfad. Der Agent kann sie weder überspringen noch wegdiskutieren. Verification Gates sind die Checks, die jede Änderung bestehen muss, bevor sie landet: Linter, Formatter, strikte statische Type-Checker und die Test-Suite. Bestandene Gates sind notwendig, aber nicht hinreichend. Ein Agent kann jedes Gate mit einem multiply() bestehen, das das falsche Produkt liefert. Die Gates fangen die mechanische Ebene ab (Typfehler, ein verletztes Schema, eine fehlschlagende Assertion), können aber nicht beurteilen, ob die Logik stimmt.

Die Spezifikation pro Aufgabe ist keine siebte Komponente. Sie ist der Input, den der Harness verarbeitet. Ein vages Ticket in menschlichem Englisch ist ein Vorschlag, auf die Spezifikation wird der Agent verpflichtet.

Die Artefakte, in denen diese Komponenten ausgeliefert werden, tauchen in jeder veröffentlichten Implementierung wieder auf. Die wiederkehrenden kopiert ihr besser, statt sie neu zu erfinden. Verteilte AGENTS.md- oder CLAUDE.md-Dateien sind das universelle Muster unter verschiedenen Namen. Jedes größere Modul hat eine, der Agent liest sie zu Beginn jeder Session, und sie enthalten Architektur, Konventionen und aktuellen Stand. Anthropics JSON-Feature-Liste dient zugleich als Projekt-Spec und Fortschrittstracker. Jeder Eintrag beschreibt ein Feature mit seinen Prüfschritten und einem Pass/Fail-Status. Der Agent liest die Liste beim Start der Session und wählt das Feature mit der höchsten Priorität, das noch fehlschlägt. Die Datei ist aus einem bestimmten Grund JSON statt Markdown: Modelle überschreiben JSON seltener unpassend. Das zählt, wenn der Agent stundenlang unbeaufsichtigt läuft.

Der Chatto-Bericht beschreibt agentische Entwicklung, die auf projektspezifischen Skills statt auf einem einzigen gemeinsamen Setup aufbaut. Jedes Projekt hält seinen eigenen Satz. Ein Glossar legt die Fachbegriffe fest, ein Architekturinventar katalogisiert die Komponenten des Systems, und Decision Records halten die Begründungen dahinter fest. Dazu zählen Architecture Decision Records (ADRs) und Feature Decision Records. Mit diesen Skills arbeitet der Agent aus dem eigenen Vokabular und der Geschichte des Projekts. So bleibt sein Output nah daran, wie die Codebasis tatsächlich entworfen wurde. (Chatto is Robots (öffnet in einem neuen Tab), 16. Juli 2026)

Der Workflow hält oben in der AGENTS.md des Projekts einen kurzen Block zum aktuellen Stand, und dieser Block leistet echte Arbeit. Er hält fest, ob Chatto schon öffentlich ist und ob es echte Nutzer:innen und echte Daten gibt. Außerdem steht dort, welche Kompatibilität das Projekt ihnen schuldet und welche Version als nächste kommt. Diese wenigen Zeilen verändern, wie ein Agent entscheidet. Derselbe Refactor gilt bei einem privaten Prototyp ohne Nutzer:innen als sicher und als leichtsinnig, sobald Menschen von den Daten abhängen. Steht dieser Unterschied vorne, liefert der Agent keinen versehentlichen Breaking Change aus. Das ist der Bericht einer Person darüber, was auf einer Codebasis funktioniert hat, kein kontrolliertes Ergebnis. Der Mechanismus lässt sich aber leicht übernehmen: Ein Agent, der die aktuelle Lage des Projekts kennt, entscheidet besser als einer, der nur vom Code ausgeht. (Chatto is Robots (öffnet in einem neuen Tab), 16. Juli 2026)

Eine Praxis-Serie über den Aufbau einer Software Factory von unten legt dafür eine Messlatte für Reproduzierbarkeit an: Das Setup ist ein versioniertes Artefakt. Dazu gehören Repository-Instruktionen, projektbezogene Skills, Hooks und Plugin-Versionen. Skills, die nur auf dem Rechner einer einzelnen Person installiert sind, gehören nicht dazu, ebenso wenig das persönliche Memory des Agenten. Ein Workflow, der nur funktioniert, weil sich der Agent an eine frühere Session erinnert, ist also noch nicht reproduzierbar. Derselbe Bericht hält die Root-Instruktionsdatei klein und nennt jede Konvention an genau einer Stelle. Was der Agent billig selbst lesen kann, etwa Package-Skripte, fehlt darin. Verweise laden eine Konvention erst, wenn die Aufgabe sie braucht. Die einzige Messung ist selbst berichtet, ohne Methode und Stichprobengröße. Danach senkte die Repository-Guidance den Token-Verbrauch in den Planungsszenarien um rund 10 bis 20 Prozent. Wo der Code das Muster schon klar zeigte, wurden die Pläne nicht besser. Größer war der Effekt, wo der Code zwei konkurrierende Muster enthält und die Guidance das Muster für neue Arbeit benennt. Das änderte, welchen Ansatz der Agent wählte. Observability sammeln in diesem Setup Lifecycle-Hooks, statt dass der Agent sie berichtet. Wiederkehrende Fehler in den Traces werden zu Eval-Fällen für die Skills. Formatierung, Linting, Typen und Abhängigkeitsgrenzen erzwingen Commit-Hooks oder Pflicht-CI, statt einer Instruktion, daran zu denken (How I’d Build a Software Factory Today: Part I (öffnet in einem neuen Tab), Oktober 2026).

Die Serie stapelt ihre Factory in fünf Schichten: Fundamente, Fähigkeiten, Orchestrierung, Task-Rezepte und Automationen. Jede muss sich für sich allein lohnen. So kann ein Team Guidance und Evals übernehmen, ohne je einen Scheduler zu betreiben, der Tickets aufnimmt (dieselbe Quelle).

Die Session-Initialisierungsroutine ist die Boot-Sequenz, die ein frisches Kontextfenster produktiv macht. Sie bestätigt das Arbeitsverzeichnis, liest Git-Log und Fortschrittsdateien und wählt das nächste unfertige Feature. Dann startet sie den Dev-Server, prüft End-to-End, setzt ein Feature um und committet. Ohne sie verbrennt der Agent seine ersten zwanzig Minuten damit, wiederzuentdecken, was schon erledigt ist. Red Hats strukturiertes Task-Template analysiert zuerst die echte Codebasis mit Language-Server-Tooling. Daraus entsteht eine Aufgabe mit echten Dateipfaden, echten Symbolnamen und konkreten Akzeptanzkriterien, nichts daran ist halluziniert. Beim Sprint Contract schlägt der Generator vor, was er baut und wie der Erfolg geprüft wird. Der Evaluator prüft den Vorschlag, bevor Code entsteht (Harness Engineering: What Every AI Engineer Needs to Know in 2026 (öffnet in einem neuen Tab), April 2026).

Alle diese Artefakte beantworten dieselbe Frage: Was muss der Agent wissen, bevor er eine einzige Zeile schreibt? Er muss wissen, wo er steht, was schon erledigt ist, wie “gut” aussieht, was tabu ist und wie er seine eigene Arbeit prüft. Das ist keine Intelligenz, das ist Kontext.

Welchen Harness ihr braucht, hängt vom Problem ab, das ihr tatsächlich habt. Die drei Lager lösen verschiedene Probleme.

  • Solo-Entwickler:innen und kleine Teams holen den größten Teil des Werts aus AGENTS.md-Dateien plus einer soliden CI-Pipeline. Das ist das OpenAI-Muster in seiner einfachsten Form, und es ist meist schon installiert.
  • Ein Team, dessen Qualitätsfehler für Nutzer:innen sichtbar sind, sollte einen Evaluations-Loop ergänzen, aber nicht unbedingt eine volle Architektur aus drei Agenten. Herunterskalieren lässt sich das Prinzip, Ausführende und Bewertende zu trennen.
  • Eine Organisation, die Agenten über viele Teams ausrollt, sollte in die ThoughtWorks-Taxonomie investieren. Sie ordnet vorhandene Linter, Tests und CI in das Raster aus Feedforward/Feedback und computational/inferential ein, um die Lücken zu finden. Dazu baut sie Harness-Templates für gängige Service-Topologien, damit die Kosten pro Service sinken.
  • In einer regulierten Branche behandelt ihr den Harness als Kontrollrahmen, denn danach fragt irgendwann die Auditor:in. Das append-only Event-Log ist ein Audit Trail, und die strukturierten Task-Templates erzeugen Dokumentation, die sich auf Compliance-Anforderungen abbilden lässt (dieselbe Quelle).

Eine Praxis-Demo ergänzt einen Baustein, den die Liste offenlässt: ein billiges Modell, das nur klassifiziert. Es beantwortet eine Ja-Nein-Frage, wählt aus einer festen Liste oder liefert Scores mit einer Konfidenz. Frage und Optionen kommen als strukturierte Daten. Der bekannte Einsatz ist ein Pre-Tool-Hook, der fragt, ob ein Shell-Befehl irreversibel ist. Er fängt auch destruktive Befehle ab, die keine Deny-Liste nennt. Die Demo verlegt denselben Aufruf in den Agent-Loop. An einer Turn-Grenze entscheidet er, ob ein Aufgabenwechsel jetzt den richtigen Moment für einen Compact markiert. Vor einer Flotte leitet er eine Anfrage an den Agenten oder das Modell weiter, das sie übernehmen soll. Als Tool bereitgestellt, beantwortet er die Frage des Hauptagenten zu einer Datei, ohne dass die Datei in den Hauptkontext gelangt. Gefragt wird etwa, ob sie Tokens validiert oder zu welcher Schicht sie gehört. Eine Frage stellt er parallel über einen ganzen Glob. Die Demo bewirbt ein Produkt, und ihre Kostenvielfachen stammen von der vortragenden Person selbst und sind ungeprüft (10 Levels of Jev For Agentic Engineers (öffnet in einem neuen Tab), September 2026, Praxis). Die Dokumentation des Anbieters schränkt den Einsatz als Gate ein. Das Modell behandelt seinen Input nicht als feindlich. Eine eingeschleuste Instruktion oder ein Text, der für seine eigene Klassifikation argumentiert, kann die Antwort also verschieben, und der Anbieter erwartet, dies später zu verbessern. Ein Klassifikator vor einem destruktiven Befehl ergänzt deshalb einen Filter und ersetzt die Deny-Regeln nicht (TypeSafe - Jev 1.13 jaggedness (öffnet in einem neuen Tab), geprüft am 2. Oktober 2026).

Die Kontrollsicht: Guides, Sensoren und kostenlose Schichten

Die sechs Komponenten sortieren nach Aufgabe. Ein zweiter, orthogonaler Schnitt sortiert dieselbe Maschinerie danach, wie sie auf den Agenten wirkt. Der Artikel auf martinfowler.com fasst einen Harness regelungstechnisch als zwei Arten von Reglern. Guides (Feedforward-Kontrollen) nehmen Verhalten vorweg und formen es, bevor der Agent handelt. Sensoren (Feedback-Kontrollen) beobachten nach dem Handeln und treiben die Selbstkorrektur an. Beide sind entweder computational oder inferential. Computational heißt deterministisch und von der CPU ausgeführt, wie ein Type-Checker oder ein Formatter. Inferential heißt semantisch und von einem Modell ausgeführt, wie KI-Code-Review oder LLM-as-judge. Den größten Hebel haben Sensoren, die für den Agenten geschrieben sind. Eine Linter-Meldung, die den Fix gleich mitliefert, ist “a positive kind of prompt injection”. Sie korrigiert den nächsten Versuch, statt ihn nur scheitern zu lassen.

Die beiden Arten von Sensoren haben auch eine Reihenfolge. Die Continuous-Delivery-Community führt zuerst die computational arbeitenden Sensoren aus, als Hooks für Linting, Type-Checks, Secret Scanning und statische Analyse. Einen Review-Agenten ruft sie erst auf, wenn diese bestanden sind. So stoppt ein mechanischer Fehler die Änderung, bevor jemand für ein inferential arbeitendes Review bezahlt (MinimumCD.org and DojoConsortium.org - Getting Started: Where to Put What (öffnet in einem neuen Tab), Stand März 2026).

Ein Webbuch über Delegation nennt die schnelle Hälfte dieses Feedbacks Backpressure und gibt ihr ein Budget. Ein Check liefert Backpressure, wenn er an einem Schritt hängt, den der Agent ohnehin macht, etwa Speichern, Bauen oder Committen. Außerdem muss er schnell und billig genug antworten, in Zeit, Tokens und Kontext, um während der Arbeit wiederholt zu laufen. Das Buch nennt als Beispiele einen Pre-Commit-Hook, der einen Namen gegen die Projektregeln ablehnt, und den Build-Schritt einer strikten Sprache. Dazu kommen ein Architecture-Fitness-Test bei jedem Build und ein Check auf gespeicherten Interface-Dateien, der die freigegebene Palette neben die beanstandete Farbe stellt. Auch ein kleiner modellbasierter Check zählt, sobald er an geprüften Beispielen evaluiert und seine Kosten gemessen sind. Alles Langsamere gehört an ein Review-Gate. Der Output zählt gegen das Budget. Gebt den fehlschlagenden Fall mit genug Details zum Untersuchen zurück und haltet Erfolgsmeldungen kurz. Ein Check, der länger dauert als die Arbeit oder das Fenster flutet, verbraucht den Kontext, den der Agent zum Reagieren braucht (The Elastic Loop: Harness (öffnet in einem neuen Tab)). Das Buch hält außerdem vier Mechanismen auseinander, die ein gescheiterter Lauf leicht verwischt. Ein Dokument mit Akzeptanzkriterien ist Kontext, ein Check dagegen ist Backpressure. Eine Permission-Grenze beschränkt eine Aktion, und ein Gate entscheidet, ob Arbeit weitergehen darf. Wer einen gescheiterten Lauf diagnostiziert, fragt deshalb zuerst, welcher der vier gefehlt hat (The Elastic Loop: Harness (öffnet in einem neuen Tab)).

Der härtere Punkt des Artikels auf martinfowler.com: Regelung teilt sich in drei Harnesses. Ein Maintainability-Harness und ein Architecture-Fitness-Harness sind beide beherrschbar. Der Behaviour-Harness bleibt “the elephant in the room”, weil er auf KI-generierten Tests beruht, denen noch niemand trauen kann. Freigegebene Fixtures helfen teilweise. Codebasen unterscheiden sich auch in ihrer Harnessability. Starke Typisierung und saubere Modulgrenzen liefern Sensoren gratis mit. Daraus folgt das Legacy-Paradox: Der Harness ist dort am nötigsten, wo er am schwersten zu bauen ist. Wer sich auf eine feste Service-Topologie festlegt, setzt selbst eine Kontrolle, einen Schritt zur Varietätsreduktion im Sinne des Law of Requisite Variety. Offen bleibt, dass es noch keine Coverage-Metrik für einen Harness gibt, so wie Code Coverage Tests misst (Harness Engineering, martinfowler.com (öffnet in einem neuen Tab)).

Eine informationstheoretische Darstellung schärft dieselbe Intuition zu einer Regel und einer Einkaufsliste. Ein LLM ist ein verrauschter Kanal, die Spezifikation ist das Signal und der Harness die Fehlerkorrektur. Bei jeder Schicht entscheidet daher, ob sie closed-loop ist, ob also der Agent ihren Output lesen und sich selbst korrigieren kann. Das Gegenteil ist out-of-loop, wie ein PDF-Audit, das nie ein Agent zu sehen bekommt. Wirtschaftlich sortieren sich Schichten danach, wo ihre Regeln definiert sind. Extrinsische Schichten kommen von außerhalb des Projekts (CVE-Scanner, WCAG, OWASP, Type-Checker) und kosten beim Einschalten fast nichts. Intrinsische Schichten (Projekttests, ADRs) muss jemand schreiben. Es gibt rund zwanzig kostenlose extrinsische Schichten, und die meisten Repositories nutzen weniger als ein Drittel davon. Die pragmatische Untergrenze heißt deshalb, jede kostenlose Schicht einzuschalten, bevor ihr Tokens bezahlt, um Fehler zu jagen, die ein Linter gefunden hätte.

In diesem Rahmen ist Sprachstrenge Fehlerkorrektur. Strikte Modifier erhöhen die Kanalkapazität. Das ist ein konkreter Grund, Rust, Kotlin oder F# als Grundlage für agentisches Coding vorzuziehen. Pflichtschichten sollten mit dem Risiko wachsen, vom Prototyp bis zum sicherheitskritischen System. Ausdrücklich benannt ist auch, was kein Harness fängt. Dazu gehören falsche oder fehlende Anforderungen, Schwachstellen in der Logik und die “theory of the program” (die Programmiertheorie von 1985), die nur in den Köpfen der Entwickler:innen lebt. Automatisierte Accessibility-Checks finden zum Beispiel nur 30 bis 50 Prozent der WCAG-Probleme (The Harness Inventory: Semantic Anchors (öffnet in einem neuen Tab), 2026).

Agent gleich Modell plus Harness, und der Harness verfällt

ThoughtWorks bringt die Disziplin auf eine Gleichung, Agent = Model + Harness. Der Harness ist alles, was nicht Modell ist, und dasselbe Modell in einem anderen Harness ist ein anderer Agent. Die Behauptung lässt sich messen. Ein Anbieter von Agent-Frameworks ließ ein festes Modell auf Terminal Bench 2.0 einmal unter seinem alten und einmal unter seinem neuen Harness laufen. Der Score stieg von 52,8 auf 66,5 Prozent. Vercel strich rund 80 Prozent der Tools seines Agenten, und die Performance stieg (Harness Engineering: What Every AI Engineer Needs to Know in 2026 (öffnet in einem neuen Tab), 2026). Drei Teams kamen von verschiedenen Problemen zu dieser Disziplin und landeten bei denselben fünf Prinzipien:

  • Kontext schlägt Instruktionen.
  • Planung ist ein eigener Schritt neben der Ausführung.
  • Feedback-Loops sind nicht verhandelbar.
  • Arbeit läuft in atomaren Einheiten, eine nach der anderen.
  • Die Codebasis ist die Dokumentation.

OpenAI ging von der Umgebung aus. Das Team gestaltete das Repo so gründlich, dass Agenten reviewbaren Output liefern, und ließ sie dann los. Der Android-Build von Sora erschien mit vier Engineers in 28 Tagen bei einer Crash-free-Rate von 99,9 Prozent, Codex schrieb 70 Prozent der wöchentlichen PRs. Anthropic ging den Multi-Agent-Weg, ThoughtWorks baute die Taxonomie (dieselbe Quelle). Anthropics Antwort ist eine von GANs inspirierte Aufteilung. Ein Planner erweitert einen Prompt von einem bis vier Sätzen zu einer vollen Spec. Ein Generator setzt ein Feature nach dem anderen um. Ein Evaluator steuert die laufende App über Playwright und bewertet sie. Bevor Code entsteht, handeln Generator und Evaluator einen Sprint Contract aus. Die Aufteilung gibt es, weil Selbstbewertung scheitert. Agenten loben ihre eigene mittelmäßige Arbeit mit großer Überzeugung. Einen eigenständigen Evaluator auf Skepsis zu tunen ist viel leichter, als einen Generator sich selbst gegenüber kritisch zu machen.

Context Resets leeren das Fenster und übergeben die Arbeit über ein strukturiertes Artefakt. Sie schlagen die Compaction im laufenden Fenster, wenn ein Modell unter “context anxiety” leidet und vorzeitig abschließt. Ein ausreichend starkes Modell macht sie allerdings überflüssig (Harness Design for Long-Running Application Development (öffnet in einem neuen Tab), 2026).

Diese letzte Einschränkung trägt Gewicht. Jede Harness-Komponente kodiert eine Annahme darüber, was das Modell allein nicht kann. Werden die Modelle besser, laufen diese Annahmen ab, und die Komponente wird zu Overhead. Anthropic nennt das Harness Decay. Der Trend ist eindeutig. Derselbe Build kostete unter dem Harness für Opus 4.5 200 Dollar in sechs Stunden, unter dem für Opus 4.6 124,70 Dollar in unter vier. Der Unterschied kam allein daher, dass Sprint-Zerlegung und Bewertung pro Sprint wegfielen, die das neuere Modell nicht mehr brauchte. Anthropics Launch-Post für Opus 4.7 behauptet, das Modell entwickle eigene Wege, seinen Output zu prüfen, bevor es zurückmeldet. Das ist eine Selbstauskunft des Anbieters. Hält sie, schrumpft die verbleibende Aufgabe des Evaluators (Anthropic - Introducing Claude Opus 4.7 (öffnet in einem neuen Tab), April 2026, Anbieter). Wer Agenten baut, berichtet von derselben Unruhe. Manus schrieb im Juli 2025, das Team habe sein Agent-Framework viermal neu gebaut, jedes Mal nach einem besseren Weg, Kontext zu formen (Manus - Context Engineering for AI Agents: Lessons from Building Manus (öffnet in einem neuen Tab), Juli 2025). Im Oktober nannte ein Webinar mit dem Team fünf Neubauten seit dem Launch des Produkts im März (Context Engineering in Manus (öffnet in einem neuen Tab), Oktober 2025). Wer einen weit verbreiteten Open-Source-Deep-Research-Agenten gebaut hat, berichtet, dass der Agent in einem Jahr drei- oder viermal neu architektiert werden musste, um mit dem besseren Tool Calling Schritt zu halten (Delphina - From Context Engineering to AI Agent Harnesses: The New Software Discipline (öffnet in einem neuen Tab), November 2025).

Die kontraintuitive Regel leitet der Artikel aus der Bitter Lesson ab: Build to delete. Jede Komponente bekommt einen Kill Switch und wird regelmäßig abgeschaltet. Sobald die Output-Qualität ohne sie hält, fliegt sie raus. Eine veraltete Komponente kostet jeden Lauf Tokens und Latenz und bringt null Qualität (Harness Engineering (öffnet in einem neuen Tab), 2026). Ein Anthropic-Workshop liest dieselbe Kurve aus METRs Time-Horizon-Chart ab. Er zeigt die Aufgabenlänge, bei der ein Agent auf einem minimalen Scaffold die Hälfte der Aufgaben schafft. Für Claude 3.7 Sonnet liegt sie bei etwa einer Stunde, für Opus 4.6 ein Jahr später bei etwa zwölf Stunden, also beim Zwölffachen. Diese Fähigkeitskurve lässt Harness-Komponenten immer wieder ablaufen (AI Engineer - Anthropic Workshop: Build Agents That Run for Hours (öffnet in einem neuen Tab), Mai 2026, Anbieter).

Build to delete umzusetzen heißt, jede “don’t do X”-Regel als verfallenden Bestand zu behandeln. Koppelt sie an ein Eval, das prüft, ob das nächste Modell sie noch braucht. Lasst einen geplanten Sweep laufen, der jede Regel neu bewertet. Sonst sammeln sich die Regeln für immer an und ersticken die wichtigen. Der spiegelbildliche Sweep pflegt “pocket evals”, harte Aufgaben, an denen das aktuell beste Modell scheitert. Sie zeigen den Moment, in dem ein neues Modell einen Workaround entfernbar macht (Inside a Software Factory (öffnet in einem neuen Tab), 2026). Das mentale Modell, das den Verfall überlebt, ist der Kontext selbst. Der Talk beschreibt einen Harness als LLM, das wie ein unscharfer Compiler arbeitet. Regeln und Docs sind darin Optimierungsdurchläufe, die festlegen, welcher Code akzeptabel ist. Ein Modellwechsel tauscht nur das Codegen-Backend. Die dauerhafte Arbeit besteht deshalb darin, den richtigen Text zur richtigen Zeit sichtbar zu machen. Selbst die Struktur des Quellcodes wird zum Harness-Hebel. Tests sichern etwa, dass Dateien unter einer Zeilenzahl bleiben oder ein Zod-Schema genau eine kanonische Definition behält. Die Messlatte des Talks lautet “every time you have to type continue is a failure of the harness”, der genug Kontext zum Fertigwerden liefern muss (Talk zu Harness Engineering (öffnet in einem neuen Tab), OpenAI, 2026).

Welche Komponenten überleben, ist kein Zufall, und ein Praxisbericht liefert den Auswahlmechanismus. Modelle werden agentisch durch Reinforcement Learning auf Coding-Sessions. Diese lassen sich mechanisch bewerten (wurden die Tests bestanden, wurde committet), anders als “write a poem”. Fähigkeiten, die in diesen Trainingsdaten überrepräsentiert sind, bilden deshalb einen dauerhaften Unterbau für den Harness. Dazu zählen Unix-Workflows, Dateien und Diffs, inkrementelle Edits, Permission-Prompts, tmux und das Chrome DevTools Protocol. Unterrepräsentierte Fähigkeiten bleiben schwach, egal wie viel Mühe in den Harness fließt. Beispiele sind Klicks in proprietären UIs, Aufgaben, die sich nur schwer textuell zerlegen lassen, und Observability-Oberflächen mit wenig Volumen. Ein Harness aus dem, worauf die Modelle hintrainiert werden, übersteht Modellwechsel. Ein minimaler Agent wie pi läuft mit vier Tools und funktioniert trotzdem.

Dieselbe Linse benennt einen klaren Fehlermodus. Zustandsänderungen, die nie in die Session-Daten gelangen, verwirren das Modell. Deshalb fügt Claude Code bei externen Edits eine Nachricht “this file changed, reread it” ein. Und deshalb behauptete ein neu geladener Agent, der nichts von seinem Neustart wusste, er habe einen Fix erneut validiert, den er nie ausgeführt hatte (Talk darüber, wie Coding-Agenten arbeiten (öffnet in einem neuen Tab), 2026).

Quellen

Praxisberichte

Anbieterberichte