Harness Engineering: Das Zeitalter des Designs der Arbeitsumgebung, wichtiger als das Modell

Dies ist eine Analyse zum Thema „Harness Engineering“, zusammengefasst von Addy Osmani. Er diagnostiziert, dass sich die Aufmerksamkeit der Branche in den vergangenen zwei Jahren ausschließlich auf die Frage konzentriert habe, „welches AI-Modell klüger ist“. Endlos wurde verglichen, ob GPT saubereren Code schreibt oder Claude weniger Halluzinationen erzeugt – seine These lautet jedoch, 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 man der AI Arbeit gibt, die nutzbaren Tools und externen Server, Richtlinien zur Kontextverwaltung, automatisch eingreifende Prüfinstanzen während der Ausführung (Hooks), sichere Ausführungsumgebungen (Sandboxes), unterstützende AIs (Sub-Agents), Feedback-Loops bis hin zu Abläufen zur Wiederherstellung, wenn etwas festhängt. Viv Trivedy hat dieses Konzept mit dem Satz „AI Agent = Modell + Harness“ formalisiert, und Personen wie das Anthropic-Engineering-Team, HumanLayer und Simon Willison arbeiten daran, diesen Ansatz weiter zu verfeinern. Osmani sieht darin mittlerweile ein eigenes Ingenieursgebiet.

Die Kernaussagen lassen sich wie folgt aufschlüsseln.

• Was ist ein Harness? Ein Modell allein wird nicht zu einer AI, die Arbeit erledigen kann. Erst wenn Code und Konfigurationen hinzukommen, die Fortschritt speichern, Tools ausführen, Ergebnisse auswerten, neu entscheiden und unerwünschte Aktionen verhindern, entsteht eine „arbeitende AI“. Produkte wie Claude Code, Cursor, Codex, Aider und Cline sind alle Harnesses; selbst wenn darin dasselbe Modell steckt, wird das Verhalten, das wir wahrnehmen, vom Harness geprägt. Mit den Worten von Simon Willison sind AI Agents „Systeme, die wiederholt Tools ausführen, um ein Ziel zu erreichen“ – entscheidend ist also, wie diese Tools und diese Wiederholungsstruktur entworfen werden.

• Nicht das Modell ist schuld, sondern die Konfiguration Wenn eine AI Unsinn macht, 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. In 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, aber nach dem Umzug in ein eigens angepasstes Harness in die Spitzengruppe sprang. Vivs Team hat allein durch Änderungen am Harness dasselbe Modell von etwa Platz 30 in die Top 5 gebracht. Das bedeutet: Oft wird das Potenzial des Modells durch das Harness ausgebremst.

• Das „Ratchet“-Prinzip: Fehler als Regeln verfestigen Wenn die 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, ergänzt man eine Zeile im Regelwerk, fügt eine automatische Sperre hinzu oder setzt eine prüfende Hilfs-AI ein – Schritt für Schritt wird das System enger abgesichert. Wenn eine AI zum Beispiel Testcode auskommentiert hat, steht im Regelwerk der nächsten Version eine Zeile wie „Tests nicht auskommentieren, sondern löschen oder reparieren“, und vor dem Commit wird ein Prüfschritt ergänzt, der genau dieses Muster erkennt. Entscheidend ist, dass jede Zeile in einem guten Regelwerk mit einem konkreten früheren Fehlschlag verbunden sein sollte. Deshalb bedeutet Harness Engineering nicht, ein vorhandenes Framework einfach zu übernehmen, sondern ähnelt eher einer „Disziplin“, die entlang der Fehlerhistorie der eigenen Codebase heranwächst.

• Vom gewünschten Verhalten rückwärts entwerfen Die nützlichste Denkweise, die Viv vorschlägt, ist Reverse Engineering vom Zielverhalten aus: „Dieses Verhalten will ich → welche Harness-Bausteine ermöglichen dieses Verhalten?“ Wenn sich nicht in einem Satz erklären lässt, für welches Verhalten ein Baustein da ist, sollte man ihn besser entfernen. Konkret heißt das: Dateisystem und Git dienen dazu, Arbeitsstände langfristig zu speichern und wiederherzustellen; Bash und Codeausführung sind universelle Werkzeuge, mit denen sich alles Mögliche ausprobieren lässt; eine Sandbox ist eine sichere Ausführungsumgebung, in der Fehler keinen Einfluss auf das Hauptsystem haben; Memory-Files sowie Websuche- und MCP-Tools sind Kanäle zum Sammeln neuen Wissens; Zusammenfassungs-Kompression, getrennte Tool-Ausgaben und Skill-Funktionen erweitern die Gedächtnisgrenzen der AI; und der Ralph Loop sowie eine Trennung in Planer- und Evaluator-Struktur sind Wege, um sehr lange Aufgaben über Tage hinweg durchzuziehen.

• Das Problem der Context Rot AI kann nur eine begrenzte Textmenge auf einmal lesen, und je näher sie an dieses Limit kommt, desto spürbarer sinkt ihre Urteilsfähigkeit. Ein Harness ist daher auch ein Bündel von Mechanismen, um den knappen Platz gut zu nutzen. Erstens: Wenn sich das Limit füllt, werden ältere Inhalte intelligent zusammengefasst und komprimiert. Zweitens: Große Ausgaben wie ein 2.000 Zeilen langes Log werden auf Anfang und Ende reduziert, während der Hauptteil in eine Datei ausgelagert und nur bei Bedarf erneut eingelesen wird. Drittens: Tools und Anweisungen werden nicht von Anfang an vollständig offengelegt, sondern per „progressiver Offenlegung“ nur dann eingeblendet, wenn sie für die konkrete Aufgabe tatsächlich gebraucht werden. Bei wirklich langen Arbeiten beginnt man manchmal sogar in einem neuen Fenster komplett neu und nimmt nur ein Übergabedokument mit. Anthropic weist darauf hin, dass bei langen Aufgaben Zusammenfassungs-Kompression allein nicht reicht und man manchmal mit einem strukturierten Übergabedokument neu starten muss. Das ähnelt dem Vorgehen, einem neuen Teammitglied bei der Übergabe eine sauber aufbereitete Dokumentation zu geben.

• Muster, um lange Aufgaben durchzuhalten Eine der aktuellen Schwächen heutiger Modelle ist, dass sie Aufgaben zu früh beenden wollen, große Probleme nicht gut in kleinere Teile zerlegen können und beim Wechsel des Kontextfensters den Faden verlieren. Das Harness muss diese Schwächen ausgleichen. Der Ralph Loop ist eine einfache Technik: Immer wenn das Modell eine Aufgabe beenden will, greift ein Hook ein und injiziert das ursprüngliche Ziel erneut in ein frisches Kontextfenster, damit die Arbeit weitergeht. Jede Iteration startet in einem sauberen Zustand, doch die Ergebnisse der vorherigen Runde bleiben über das Dateisystem erhalten. Anthropic betont außerdem, dass „Generierung“ und „Evaluation“ auf unterschiedliche AIs verteilt werden sollten, weil eine AI ihre eigenen Ergebnisse tendenziell zu großzügig bewertet. Ergänzend hilft das Muster des „Sprint Contract“, bei dem man vor Beginn einer Aufgabe vorab definiert, was genau als „fertig“ gilt, um ein schleichendes Aufweichen des Ziels während der Arbeit zu verhindern.

• Die Rolle von Hooks „Der AI sagen, dass sie es so machen soll“ und „das System erzwingt, dass es so gemacht wird“ sind zwei verschiedene Dinge. Hooks schließen genau diese Lücke. Es sind automatische Mechanismen, die an bestimmten Zeitpunkten eingreifen – etwa vor der Tool-Nutzung, nach Dateiänderungen, vor dem Commit oder beim Sitzungsstart. Sie können etwa nach jeder Codeänderung automatisch Syntaxprüfung, Linting und Tests ausführen, gefährliche Befehle wie rm -rf oder git push --force blockieren oder vor dem Erstellen eines PR menschliche Freigabe verlangen. Das Prinzip lautet: „Erfolg bleibt leise, Scheitern wird laut.“ Besteht eine Prüfung, hört die AI nichts davon; schlägt sie fehl, wird die Fehlermeldung direkt in den Ablauf eingespeist, damit die AI sich selbst korrigieren kann. Das ist eine Struktur, die im Alltag fast nichts kostet und nur im Problemfall punktgenau hilft.

• Regeldokumente und Tool-Auswahl: kurz und eindeutig Die im Projekt-Root liegende Datei AGENTS.md ist die einflussreichste Konfigurationsdatei, weil sie in jedem Turn in den System Prompt eingeht. HumanLayer empfiehlt, dieses Dokument auf unter 60 Zeilen zu halten. Je länger es wird, desto geringer wird das Gewicht jeder einzelnen Zeile. Es soll also kein allgemeiner Stil-Leitfaden sein, sondern eher eine Checkliste wie im Cockpit, in der nur das Nötigste stehen bleibt. Für Tools gilt dasselbe: 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. Weil Tool-Beschreibungen Text sind, den die AI direkt liest, kann das Einbinden eines nicht verifizierten externen MCP-Servers zu einem Kanal werden, über den jemand der AI heimlich vorbereitete Anweisungen einschleust.

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

• Es wird klar, wo sich Aufwand lohnt Benchmark-Daten zeigen, dass sich Verhalten massiv verbessern lässt, ohne das Modell zu wechseln – und genau dieser Hebel ist das Harness. Statt der vagen Hoffnung „Warten wir einfach auf das nächste Modell“ entsteht ein konkreter Bereich, den man sofort optimieren kann.
• Know-how kann sich ansammeln Dank des Ratchet-Ansatzes, bei dem Fehler in Regeln übersetzt werden, bleibt eine einmal gelernte Lektion als Team-Asset erhalten. Auch wenn sich Personen ändern, bleiben Regeldokumente und Hooks bestehen und schützen die Nächsten.
• Das Aufkommen fertiger Harnesses (HaaS) Der Trend, den Viv „Harness-as-a-Service“ nennt, etabliert sich schnell. Mit Produkten wie Claude Agent SDK, Codex SDK und OpenAI Agents SDK, die Arbeits-Loop, Tools, Kontextverwaltung, Hooks und Sandboxes bereits bündeln, muss man nicht mehr alles von Grund auf selbst bauen und kann sich stärker auf das eigene Domain-Wissen konzentrieren.

Es gibt aber auch belastende Seiten.

• Der Verantwortungsbereich ist breit Anweisungen, Tools, sichere Ausführungsumgebungen, automatische Prüfungen bis hin zur Log-Beobachtung – all das muss man selbst im Blick behalten. Entscheidend ist, dass dies kein Bereich ist, den der Modellanbieter automatisch für einen erledigt.
• Risiken durch die Kopplung von Modell und Harness Heutige Modelle werden innerhalb bestimmter Harnesses mit Nachbearbeitung trainiert. Wechselt man in ein anderes Harness, kann die Leistung plötzlich einbrechen. Schon ein anderer Tool-Name oder ein anderes Argumentformat kann die Ergebnisse verschlechtern. Ein wirklich allgemeines Modell sollte eigentlich nicht von Tool-Namen beeinflusst werden, doch durch die gemeinsame Trainingsstruktur entsteht eine Art Overfitting.
• Sicherheitsrisiken externer Tools Bei MCP-Servern werden die Tool-Beschreibungen der AI direkt vorgelesen. In dem Moment, in dem ein nicht verifiziertes Tool angebunden wird, beginnt externer Text die AI zu beeinflussen – noch bevor der Nutzer überhaupt ein einziges Zeichen eingegeben hat.

Das ist der unterscheidende Blickwinkel.

• Abgrenzung vom modellzentrierten Diskurs Statt auf ein noch klügeres GPT zu warten, wird hier ein ingenieurmäßiger Weg vorgeschlagen, mit dem sich die Grenzen des aktuell verfügbaren Modells ausreizen lassen. Die Diagnose lautet: Die Lücke zwischen den sichtbaren AI-Grenzen von heute und den tatsächlichen Fähigkeiten des Modells ist meist eine Harness-Lücke.
• Das Harness verschwindet nicht, es verlagert sich nur Wenn Modelle besser werden, werden manche Harness-Bausteine überflüssig. So hat Opus 4.6 etwa die bei Claude Sonnet 4.5 häufige Ungeduld nach dem Muster „Der Kontext geht gleich zu Ende, ich muss schnell fertig werden“ fast vollständig beseitigt, wodurch bisher genutzte Sicherheits-Hilfskonstruktionen auf einen Schlag zu totem Code wurden. Aber in den neuen Bereichen, die das Modell nun erreicht, entstehen neue Schwächen – und wieder braucht es neue Harnesses, um sie auszugleichen. Dazu passt Anthropics Formulierung: „Jeder Baustein eines Harnesses enthält eine Annahme darüber, was das Modell allein nicht kann.“
• Der Lernkreislauf zwischen Modell und Harness Ein weiterer von Viv hervorgehobener Trend ist die Rückkopplung zwischen Harness-Design und Modelltraining. Wenn im Harness nützliche Muster entdeckt werden, werden sie standardisiert; die nächste Modellgeneration wird auf Basis dieser Muster trainiert; und auf diesen Modellen entstehen wiederum neue Harness-Muster. Deshalb lautet das Fazit: Ein „gutes Harness“ ist nicht das Harness, in dem das Modell trainiert wurde, sondern das Harness, das für die eigene Arbeit erneut angepasst wurde.
• Die Branche konvergiert auf ähnliche Formen Coding-AIs wie Claude Code, Cursor, Codex, Aider und Cline verwenden unterschiedliche Modelle, aber die Form ihrer Harnesses ähnelt sich immer stärker. Dass die Modelle unterschiedlich, die Harnesses aber ähnlich werden, kann als Signal gelesen werden, wo sich dieses Feld gerade stabilisiert.

Osmanis Text vertritt die Sicht, dass die Wettbewerbsfähigkeit von Coding-AI stärker von der Gestaltung des sie umgebenden Harnesses als von der Wahl des Modells abhängt – und dass ein Harness keine Konfigurationsdatei ist, die man einmal einrichtet und dann vergisst, sondern ein lebendiges System, das anhand der Fehlerhistorie fortlaufend aktualisiert wird. Wenn Modelle besser werden, verschwindet das Harness nicht, sondern die Ebene der zu bewältigenden Probleme verschiebt sich nach oben, und neue Harnesses füllen diese Lücke. Wie Viv in einem von Osmani zitierten Satz sagt: „Gute Agents zu bauen ist die Kunst der Iteration, und ohne eine erste Version gibt es auch keine Iteration.“ Das lässt sich so lesen, dass es in diesem Feld am Ende darum geht, wer früher anfängt und häufiger nachschärft. Die Schlussfolgerung lautet also: Engineers sollten ihre Zeit nicht darauf verwenden, jedes Mal das gerade gehypte Modell auszutauschen, sondern das zum eigenen Arbeitskontext passende Harness kontinuierlich weiterzuentwickeln und so Schritt für Schritt die Obergrenze dessen anzuheben, was das Modell leisten kann.

[kimjoin2]

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

[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

[tangokorea]

Statt die Frage so zu betrachten, was von beidem besser ist – Modell oder Harness –, wie wäre es, einen Schritt zurückzutreten und zu überlegen, welcher Harness zu welchem Modell besser passt?

[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

[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.