Harness Engineering: Das Zeitalter des Arbeitsumfeld-Designs ist wichtiger als das Modell

Dies ist eine Analyse zum Thema „Harness Engineering“, zusammengefasst von Addy Osmani. Er diagnostiziert, dass sich das Interesse der Branche in den vergangenen zwei Jahren fast ausschließlich auf die Frage konzentriert habe, „welches AI-Modell intelligenter ist“. Endlos wurde verglichen, ob GPT saubereren Code schreibt oder Claude weniger halluziniert, doch seine These lautet, dass die tatsächliche Leistung von Coding-AI in der Praxis weniger vom Modell selbst als vielmehr vom Harness bestimmt wird, das dieses Modell umgibt. Mit Harness ist alles außer dem Modell gemeint: der System-Prompt, mit dem der AI Arbeit zugewiesen wird, nutzbare Tools und externe Server, Richtlinien für das Kontextmanagement, automatisch eingreifende Kontrollmechanismen während der Ausführung (Hooks), sichere Ausführungsumgebungen (Sandboxes), unterstützende AI-Systeme (Subagents), Feedback-Loops und sogar Recovery-Flows für Situationen, in denen die Arbeit ins Stocken gerät. Viv Trivedy hat dieses Konzept mit der Formel „AI-Agent = Modell + Harness“ auf den Punkt gebracht, und Akteure wie das Engineering-Team von Anthropic, HumanLayer und Simon Willison verfeinern diesen Ansatz weiter. Osmani ist der Ansicht, dass sich daraus inzwischen ein eigenständiges Engineering-Feld entwickelt hat.

Die Kernaussagen lassen sich wie folgt aufschlüsseln.

• Was ein Harness ist Mit einem Modell allein wird AI noch nicht zu einer Instanz, die Aufgaben tatsächlich erledigt. Erst wenn Code und Konfiguration hinzukommen, die Fortschritt speichern, Tools ausführen, Ergebnisse auswerten und neu entscheiden sowie unerwünschte Aktionen blockieren, entsteht eine „arbeitende AI“. Produkte wie Claude Code, Cursor, Codex, Aider und Cline sind allesamt Harnesses, und selbst wenn darin dasselbe Modell steckt, wird das von uns wahrgenommene Verhalten vom Harness bestimmt. In Simon Willisons Worten sind AI-Agenten „Systeme, die wiederholt Tools einsetzen, um ein Ziel zu erreichen“ – und die eigentliche Qualität hängt davon ab, wie diese Tools und Iterationsstrukturen entworfen sind.

• Nicht das Modell ist schuld, sondern die Konfiguration Wenn AI etwas Unsinniges tut, geben Engineers oft dem Modell die Schuld und landen bei dem Schluss: „Warten wir auf die nächste Version.“ Harness Engineering weist diese Reaktion zurück. Mit den Worten von HumanLayer: „Das ist kein Modellproblem, sondern ein Konfigurationsproblem (skill issue).“ Es gibt Fälle, in denen dasselbe Modell, Claude Opus 4.6, im Standard-Harness Claude Code im unteren Bereich von Terminal Bench 2.0 blieb, mit einem eigens überarbeiteten Harness jedoch in die Spitzengruppe aufstieg. Vivs Team verbesserte allein durch einen Wechsel des Harnesses die Platzierung desselben Modells von etwa Rang 30 auf etwa Rang 5. Das deutet darauf hin, dass das Potenzial eines Modells oft vom Harness ausgebremst wird.

• Das „Ratchet“-Prinzip: Fehler in Regeln überführen Wenn AI auch nur einmal einen Fehler gemacht hat, wird das nicht als Zufall abgetan, sondern als dauerhaftes Signal verstanden. Damit derselbe Fehler beim nächsten Mal nicht wieder auftritt, wird die Regeldokumentation um eine Zeile ergänzt, ein automatischer Sperrmechanismus eingebaut oder eine prüfende Hilfs-AI hinzugefügt – Schritt für Schritt wird das System enger gezogen. Wenn eine AI etwa Testcode auskommentiert hat, wird in der nächsten Version der Regeln eine Zeile wie „Tests nicht auskommentieren, sondern löschen oder korrigieren“ ergänzt, und vor dem Commit kommt ein Checker hinzu, der genau dieses Muster erkennt. Entscheidend ist, dass jede Zeile in einer guten Regeldokumentation mit einem konkreten früheren Fehlschlag verbunden sein sollte. Deshalb bedeutet Harness Engineering nicht, einfach ein fertiges Framework zu übernehmen, sondern ähnelt eher einer „Disziplin“, die entlang der Fehlerhistorie der eigenen Codebase wächst.

• Vom gewünschten Verhalten rückwärts entwerfen Die nützlichste Denkweise, die Viv vorschlägt, ist Reverse Design: „Dieses Verhalten wollen wir sehen → welche Harness-Bausteine machen dieses Verhalten möglich?“ Wenn sich nicht in einem Satz erklären lässt, für welches Verhalten ein Bauteil existiert, ist es besser, es zu entfernen. Konkret heißt das: Dateisystem und Git dienen dazu, Arbeitsinhalte langfristig zu speichern und zurückzusetzen, bash und Code-Ausführung sind universelle Werkzeuge zum Ausprobieren, die Sandbox ist ein sicherer Ausführungsraum ohne Auswirkungen auf das Hauptsystem, Memory-Dateien sowie Websuche- und MCP-Tools sind Kanäle zum Aufbau neuen Wissens, Summary-Komprimierung, die Trennung von Tool-Ausgaben und Skill-Funktionen erweitern die Grenzen des AI-Gedächtnisses, und der Ralph loop sowie die Trennung von Planer und Evaluator helfen dabei, lang laufende Aufgaben über mehrere Tage hinweg zu Ende zu bringen.

• Das Problem der context rot AI kann nur eine begrenzte Textmenge auf einmal lesen, und je näher sie an diese Grenze kommt, desto spürbarer lässt die Urteilsfähigkeit nach. Daher ist ein Harness auch ein Bündel von Mechanismen, um mit begrenztem Kontextplatz effizient umzugehen. Erstens wird alter Inhalt intelligent zusammengefasst und komprimiert, wenn das Limit näher rückt. Zweitens werden große Ausgaben wie 2.000-zeilige Logs auf Anfang und Ende reduziert, während der Mittelteil in eine Datei ausgelagert und nur bei Bedarf erneut gelesen wird. Drittens werden Tools und Anweisungen nicht von Anfang an vollständig offengelegt, sondern erst dann eingeblendet, wenn sie für die jeweilige Aufgabe tatsächlich benötigt werden – ein Ansatz der „progressiven Offenlegung“. Bei wirklich langen Aufgaben beginnt man teils sogar in einem neuen Fenster komplett neu und nimmt nur ein Übergabedokument mit. Anthropic weist darauf hin, dass bei langen Aufgaben reine Summary-Komprimierung nicht immer reicht und manchmal ein strukturierter Handover nötig ist, um neu zu starten. Das ähnelt dem Vorgehen, einer neuen Person bei der Übergabe eines Jobs eine sauber geordnete Dokumentation zu übergeben.

• Muster für lang laufende Aufgaben Zu den heutigen Schwächen von Modellen gehört, dass sie Aufgaben zu früh abschließen wollen, große Probleme schlecht in kleine Teile zerlegen und bei einem Wechsel des Kontextfensters den roten Faden verlieren. Das Harness muss diese Schwächen ausgleichen. Der Ralph loop ist eine einfache Technik: Jedes Mal, wenn das Modell die Arbeit beenden will, greift ein Hook ein und injiziert das ursprüngliche Ziel erneut in ein neues Kontextfenster, damit die Arbeit weitergeht. Jede Iteration startet in einem sauberen Zustand, aber die Ergebnisse der vorherigen Runde bleiben über das Dateisystem erhalten. Anthropic betont außerdem, dass „Generator“ und „Evaluator“ von unterschiedlichen AI-Systemen übernommen werden sollten. Wenn AI ihre eigenen Ergebnisse selbst bewertet, neigt sie dazu, zu großzügig zu sein. Hinzu kommt das Muster des „Sprint Contract“, bei dem schon vor Beginn der Arbeit festgelegt wird, was genau „fertig“ bedeutet. Das hilft, zu verhindern, dass das Ziel während der Arbeit schleichend ausgeweitet wird.

• Die Rolle von Hooks Es macht einen Unterschied, ob man „der AI sagt, sie solle etwas tun“ oder ob „das System sie dazu zwingt“. Hooks schließen genau diese Lücke. Sie greifen an bestimmten Zeitpunkten automatisch ein – etwa vor dem Einsatz eines Tools, nach Änderungen an Dateien, vor einem Commit oder beim Start einer Session. So können bei jeder Code-Änderung automatisch Syntaxprüfung, Linting und Tests laufen, gefährliche Befehle wie rm -rf oder git push --force blockiert oder vor dem Erstellen eines PRs menschliche Freigaben eingefordert werden. Das Prinzip lautet: „Erfolg bleibt still, Fehler werden laut.“ Wenn eine Prüfung besteht, hört die AI nichts davon; wenn sie fehlschlägt, wird die Fehlermeldung direkt in den Ablauf eingespeist, damit die AI sie selbst beheben kann. Das ist eine Struktur, die im Normalfall fast nichts kostet und nur im Problemfall punktgenau hilft.

• Regeldokumente und Tool-Auswahl: kurz und eindeutig AGENTS.md im Projekt-Root ist die einflussreichste Konfigurationsdatei, weil sie bei jedem Turn in den System-Prompt eingeht. HumanLayer empfiehlt, dieses Dokument auf unter 60 Zeilen zu halten. Je länger es wird, desto mehr verliert jede einzelne Zeile an Gewicht. Es soll kein Leitfaden für den allgemeinen Stil sein, sondern eher eine Checkliste wie für Pilotinnen und Piloten, die nur wirklich notwendige Punkte enthält. Dasselbe gilt für Tools: Weil Name, Beschreibung und Schema bei jeder Anfrage in den Prompt eingebettet werden, sind 10 gut ausgearbeitete Tools besser als 50 ähnliche. HumanLayer weist auch auf den Sicherheitsaspekt hin. Da Tool-Beschreibungen letztlich Text sind, den die AI liest, kann das Einbinden eines nicht verifizierten externen MCP-Servers zu einem Kanal werden, über den heimlich vorformulierte Anweisungen in die AI eingeschleust werden.

Das sind die Punkte, die als Vorteile gelten können.

• Klarerer Fokus für Investitionen Benchmark-Daten zeigen, dass sich Verhalten auch ohne Modellwechsel deutlich verbessern lässt – und zwar im Harness. Statt vage auf „das nächste Modell“ zu warten, gibt es konkrete Bereiche, die sich sofort überarbeiten lassen.
• Struktur für kumulierendes Know-how Durch den Ratchet-Ansatz, bei dem Fehler in Regeln umgewandelt werden, bleiben einmal gelernte Lektionen als Teamvermögen erhalten. Selbst wenn sich Personen im Team ändern, schützen Regeldokumente und Hooks weiterhin die Nächsten.
• Vorgefertigte Harnesses (HaaS) Der Trend, den Viv „Harness-as-a-Service“ nennt, etabliert sich schnell. Produkte wie Claude Agent SDK, Codex SDK und OpenAI Agents SDK bündeln Task-Loops, Tools, Kontextmanagement, Hooks und Sandboxes im Voraus, sodass man nicht alles von Grund auf neu bauen muss und sich stärker auf eigenes Domänenwissen konzentrieren kann.

Es gibt aber auch belastende Aspekte.

• Breites Verantwortungsspektrum Prompts, Tools, sichere Ausführungsumgebungen, automatische Prüfungen bis hin zur Log-Beobachtung müssen alle selbst verantwortet werden. Entscheidend ist: Das ist kein Bereich, den der Modellanbieter automatisch für einen übernimmt.
• Risiko der Kopplung von Modell und Harness Heutige Modelle werden innerhalb bestimmter Harnesses mit nachgelagerter Optimierung trainiert. Wechselt man in ein anderes Harness, kann die Leistung plötzlich abfallen. Schon ein anderer Tool-Name oder ein anderes Argumentformat kann die Ergebnisse ins Wanken bringen. Ein wirklich allgemeines Modell sollte sich nicht am Tool-Namen stören, doch durch die gemeinsame Trainingsstruktur entsteht eine Art Overfitting.
• Sicherheitsrisiko externer Tools Bei MCP-Servern werden Tool-Beschreibungen direkt von der AI gelesen. In dem Moment, in dem ein nicht verifiziertes Tool eingebunden wird, beginnt externer Text die AI zu beeinflussen – noch bevor der Nutzer überhaupt ein einziges Zeichen eingegeben hat.

Das sind die Perspektiven, die den Ansatz besonders machen.

• Abgrenzung vom modellzentrierten Diskurs Statt auf ein noch intelligenteres GPT zu warten, wird ein Engineering-Ansatz vorgeschlagen, mit dem sich die Grenzen des vorhandenen Modells hier und heute verschieben lassen. Die Diagnose lautet, dass die Lücke zwischen den sichtbaren Grenzen heutiger AI und den tatsächlichen Fähigkeiten des Modells meist eine Harness-Lücke ist.
• Das Harness verschwindet nicht, sondern verlagert sich Wenn Modelle besser werden, werden manche Harness-Bausteine überflüssig. Opus 4.6 hat zum Beispiel die in Claude Sonnet 4.5 häufige Ungeduld nach dem Muster „Der Kontext ist fast voll, ich muss schnell fertig werden“ nahezu beseitigt. Dadurch wurden manche bis dahin eingesetzten Sicherheits-Hilfskonstruktionen komplett zu totem Code. Doch in den neuen Bereichen, die das Modell dadurch erreichen kann, entstehen neue Schwächen – und damit erneut der Bedarf nach neuen Harnesses. Dazu passt die Formulierung von Anthropic: „Jeder Baustein eines Harnesses enthält eine Annahme darüber, was das Modell allein nicht kann.“
• Lernkreislauf zwischen Modell und Harness Ein weiterer Punkt, den Viv hervorhebt, ist der Rückkopplungskreis zwischen Harness-Design und Modelltraining. Wenn im Harness nützliche Muster entdeckt werden, werden sie standardisiert; Modelle der nächsten Generation werden anhand dieser Muster trainiert; auf dieser Basis entstehen dann wiederum neue Harness-Muster. Daher lautet das Fazit: Ein „gutes Harness“ ist nicht das Harness, mit dem das Modell trainiert wurde, sondern das Harness, das für die eigene Arbeit erneut angepasst wurde.
• Konvergenz der Branche auf ähnliche Formen Coding-AIs wie Claude Code, Cursor, Codex, Aider und Cline verwenden unterschiedliche Modelle, aber die Form ihrer Harnesses ähnelt sich zunehmend. Dass die Modelle verschieden sind, die Harnesses jedoch immer ähnlicher werden, kann als Signal dafür gelesen werden, wo sich dieses Feld gerade stabilisiert.

Osmanis Text vertritt die Perspektive, dass die Wettbewerbsfähigkeit von Coding-AI stärker von der Gestaltung des umgebenden Harnesses als von der Wahl des Modells abhängt und dass ein Harness keine einmal eingerichtete Konfigurationsdatei ist, sondern ein lebendiges System, das anhand der Fehlerhistorie kontinuierlich aktualisiert wird. Wenn Modelle besser werden, verschwindet das Harness nicht, sondern die Ebene der Probleme verschiebt sich nach oben, und ein neues Harness füllt diese Lücke wieder. In Vivs von ihm zitiertem Satz – „Gute Agenten zu bauen ist die Kunst der Iteration, und ohne eine erste Version gibt es keine Iteration“ – steckt die Aussage, dass sich dieses Feld letztlich darum dreht, wer früher beginnt und häufiger verfeinert. Die Schlussfolgerung lautet also: Engineers sollten ihre Zeit nicht darauf verwenden, ständig das jeweils gehypte Modell auszutauschen, sondern das eigene Harness immer weiter an die eigene Arbeit anzupassen und damit die Obergrenze dessen, was das Modell leisten kann, Schritt für Schritt anzuheben.

[kimjoin2]

Es fühlt sich an, als würden immer mehr bloße Marketingbegriffe entstehen.

[jimmy2056]

Wenn das Modell gut ist, wird auch die Belastung bei der Harness-Konstruktion geringer.

[akapwhd]

Selbst wenn man so etwas anwendet, scheint es beim eigentlichen Coden nicht wirklich viel zu helfen ... Wahrscheinlich liegt es daran, dass es sich nur um Entwicklung mit einem Schwierigkeitsgrad handelt, bei dem man einen Agenten mit einem Codex-Plan laufen lässt, haha

[dongho42]

Aber wenn man im Prompt sagt „Mach A, mach B nicht“ und das Modell das wirklich gut versteht, dann scheint so ein Ansatz sinnvoll zu sein. Aber ist so ein Ansatz auch dann sinnvoll, wenn die Anweisungen im Prompt je nach Zustand des AI-Servers nur probabilistisch befolgt werden?

[dongho42]

Früher habe ich klar in den Prompt geschrieben „Mach A“, aber trotzdem wurde das mit einer gewissen Wahrscheinlichkeit immer wieder nicht eingehalten. Also habe ich alles Mögliche ausprobiert: in mrkdwn fett hervorheben, es zweimal schreiben, auf Englisch schreiben, mit einer ringförmigen Struktur formulieren, in XML schreiben — doch mit einer gewissen Wahrscheinlichkeit wurde der Prompt immer wieder ignoriert...

[kurthong]

Ich habe auch alles Mögliche reingeworfen, ähnlich wie bei Osmanis Aussagen,
und als ich gerade eine App gebaut habe, kam dieses Thema auf, deshalb habe ich es etwas überstürzt geschrieben.
Aber statt nur darüber zu reden, wäre es nicht besser gewesen, wenn Osmani das, was er gesagt hat, auch selbst bei Google Antigravity eingebaut hätte?
Bei Kapasi ist es genauso – inzwischen hat man offenbar gar nicht mehr vor, einfach etwas zu bauen, sondern wirft nur noch mal eben einen Text hin; na ja, was soll man dazu sagen!

https://github.com/hang-in/tunaFlow

[blackfabric]

3-Zeilen-Zusammenfassung

• Nicht das Modell, sondern das System (Harness) entscheidet über Erfolg oder Misserfolg: Die Leistung von KI wird weniger vom Modell selbst wie GPT oder Claude bestimmt als von der Gestaltung der Arbeitsumgebung darum herum, also Prompts, Tools, Sandbox, Feedback-Loops und weiteren Elementen, die als „Harness“ bezeichnet werden.
• Das „Ratchet“-Prinzip, das Fehler in Regeln überführt: Fehler der KI sollten nicht als bloße Ausrutscher abgetan, sondern umgehend in Regeldokumente (wie AGENTS.md) oder Hooks übernommen werden, damit das System mit der Zeit robuster wird.
• Nicht die Schuld des Modells, sondern ein Problem der Konfiguration (Skill): Wenn KI ihre Arbeit nicht gut erledigt, liegt das oft weniger an mangelnder Intelligenz des Modells als an einem schlecht konstruierten Harness; ein technischer Ansatz, der vom gewünschten Ergebnis rückwärts die nötigen Bausteine und Randbedingungen entwirft, ist essenziell.

[yungoun]

Aber Harnes wurde bis letzte Woche noch massiv vermarktet, und seit dieser Woche ist es auffallend ruhig … Vielleicht liegt es an den Fehltritten von Anthropic und daran, dass Codex 5.5 so stark ist ………

[click]

So etwas wie SDD hat seinen Hype längst hinter sich, jetzt scheint also Harness dran zu sein.
Der etwas erstaunliche Teil bei Harness ist, dass das Modell das Konzept „harness“ ziemlich schnell versteht, obwohl es in den Trainingsdaten eindeutig nicht vorkam.
Vielleicht liegt es daran, dass einfach die Bedeutung eines bereits existierenden Wortes übernommen wird; ich habe es nicht einmal erwähnt, und trotzdem kamen schon Aussagen wie, man solle zuerst das Harness aktualisieren.

[kurthong]

Das ist ein Text, der das Gerede eines erfahrenen Entwicklers analysiert, der inhaltsleere Aussagen plausibel klingen lässt (persönlich mag ich Google nicht, entschuldigen Sie bitte). Natürlich halte ich den Ansatz, das Phänomen über ein besseres Verständnis zu erfassen, für einen guten Versuch.