Modelle sind keine Barriere, und Harness auch nicht.

Zunächst einmal sei angemerkt, dass dieser Artikel etwas anspruchsvoll ist.

Er eignet sich für Personen, die an AI-Trends interessiert sind und verstehen möchten, worüber die Entwicklerbranche im Jahr 2026 streitet. Man muss sich ein wenig anstrengen.

Wir beginnen mit einem Gefühl, das jeder kennt: Die meisten Menschen, die schon einmal AI zum Schreiben von Code verwendet haben, haben dieselbe Emotionskurve durchlaufen: Am ersten Tag denken sie, dass diese Technologie eine Revolution bringen wird, am dritten Tag beginnen sie zu meckern.

Die AI kann abweichen, immer wieder denselben Fehler machen, die Anforderungen, die man ihr vor drei Minuten gegeben hat, vergessen und sogar mitten im Projekt plötzlich sagen: „Fertig!“

Die erste Reaktion der meisten Menschen ist: Dieser Modell ist nicht gut, ich nehme ein stärkeres. Aber Anfang 2026 kamen die ausländischen Entwicklerplattformen plötzlich zu der Ansicht, dass das Problem vielleicht in der Umgebung um das Modell herum liegt.

Sie haben dieser Umgebung einen Namen gegeben: Harness.

01

Der Begriff „Harness“ bedeutet wörtlich „Reitausrüstung“, also die Zügel, das Sattelzeug, die Zaummaße, die Hufeisen und so weiter, also die Ausrüstung, mit der man ein Pferd lenkt. In Bezug auf die AI hat es eine ähnliche Bedeutung. Beispielsweise die Verwaltung der Laufzeitumgebung des großen Modells, der Schnittstellen der Tools, des Validierungsmechanismus, der Rückkopplungsschleifen, der Einschränkungsregeln usw.

Die Popularität dieses Begriffs hat eine sehr klare Zeitlinie:

Am 5. Februar 2026 veröffentlichte Mitchell Hashimoto, Mitbegründer von HashiCorp, einen Blogbeitrag. Dieser Mann ist sehr berühmt. Er hat Terraform entwickelt, ein Infrastrukturtool, das von Entwicklern weltweit verwendet wird. In der Infrastrukturbranche ist er wie ein Patriarch.

Er teilte in seinem Blogbeitrag seine Erfahrungen mit der Programmierung mit AI. Beim fünften Schritt schrieb er einen Satz, der ungefähr so lautet: Wenn der Agent einen Fehler macht, hilft es nicht, im Prompt „Bitte achten Sie beim nächsten Mal“ hinzuzufügen.

Es ist besser, die Umgebung zu ändern, eine Regel zu schreiben, ein Skript hinzuzufügen, damit er strukturell nicht wieder denselben Fehler machen kann. Er nennt dies „Engineer the Harness“ (die Reitausrüstung entwerfen).

Sechs Tage später folgte OpenAI. Am 11. Februar veröffentlichten sie einen Experimentbericht, dessen Titel direkt „Harness Engineering“ lautete.

Im Bericht heißt es, dass drei Ingenieure von einem leeren Repository aus fünf Monate lang keinen manuellen Code geschrieben haben, sondern alles von OpenAIs Programmieragenten (Codex Agent) generiert haben. Am Ende waren im Repository ungefähr eine Million Codezeilen zusammengekommen, 1500 Code-Merge-Anfragen wurden zusammengeführt, und das Produkt hatte echte tägliche aktive Benutzer.

Die drei Personen haben in diesen fünf Monaten nichts anderes getan, als die Umgebung zu entwerfen, in der der Agent Code schreibt.

Danach trat Martin Fowler in die Breche, und LangChain (ein Unternehmen, das AI-Anwendungsentwicklungssysteme entwickelt) folgte. Innerhalb eines Monats war dieser Begriff von einem persönlichen Blogbeitrag zu einer Jargon in der Entwicklerbranche geworden.

Was kann Harness konkret tun? Die einfachste Vorstellung ist: Der Agent soll keine Schlechtigkeiten begehen können, Dinge merken können, seine Arbeit überprüfen lassen können und im Falle eines Fehlers zurücksetzen können.

Beispielsweise die Einschränkung: In OpenAIs Experiment forderten die Ingenieure, dass der Code eine Schichtenarchitektur einhalten muss, und dass jedes Modul nur auf die benachbarten Schichten verweisen darf. Beachten Sie, dass es nicht hilft, im Prompt „Bitte halten Sie sich an die Schichtenarchitektur“ zu schreiben, der Agent vergisst es sofort.

Sie haben diese Regel in einen automatisierten Code-Check in der CI-Pipeline geschrieben. Wenn der Agent diese Regel verletzt, kann die Code-Merge-Anfrage nicht akzeptiert werden. Eine programmierte Regel ist viel effektiver als tausend Warnungen im Prompt.

Ein weiteres Beispiel ist das Gedächtnis: Große Modelle haben von Natur aus nur ein Gedächtnis, nämlich das Kontextfenster. Wenn es voll ist, werden die vorherigen Inhalte herausgedrängt. OpenAIs Vorgehensweise besteht darin, in der Repository eine strukturierte Dokumentation zu pflegen, in der Designrichtlinien, Architekturentscheidungen, Ausführungspläne usw. enthalten sind. Der Agent kann jederzeit darauf zugreifen.

Einfach gesagt, man kann nicht erwarten, dass eine Goldfisch Dinge merkt. Man muss auf der Außenseite des Aquariums Notizzettel kleben.

Das interessanteste ist die Validierung: Wenn man den Agenten fragt, wie seine Arbeit ist, sagt er fast immer: „Ich habe es gut gemacht.“ Dies ist keine Scherz von Anthropic, sondern eine Tatsache.

Der Agent beurteilt seine eigene Leistung immer zu optimistisch, auch wenn die Qualität für Menschen eher mäßig ist. Was soll man tun?

Anthropics Lösung ähnelt einem generativen adversariellen Netzwerk (eine Technologie, bei der zwei KIs miteinander konkurrieren): Der Agent, der die Arbeit macht, und der Agent, der die Arbeit beurteilt, sind getrennt. Ein Agent schreibt den Code, der andere sucht gezielt Fehler. Der Spieler und der Schiedsrichter dürfen nicht dieselbe Person sein.

Es gibt auch die Fehlerkorrektur: Anthropic hat festgestellt, dass es bei langlaufenden Agenten häufig vorkommt, dass der Agent in eine Sackgasse gerät. Wenn man weiter macht, wird der Fehler immer größer. Ihre Lösung ist einfach und effektiv:

Jede Änderung wird mit Git durchgeführt. Wenn es Probleme gibt, wird mit Git auf den letzten sauberen Zustand zurückgesetzt, und dann wird ein neuer Agent eingesetzt. Man gibt ihm nur eine Übergabeaufzeichnung, in der steht, was vorher gemacht wurde und was als nächstes zu tun ist.

Man kann nicht erwarten, dass eine Goldfisch sich selbst repariert. Man setzt einfach eine neue Goldfisch ein und gibt ihr einen Zettel. All das zusammen ist Harness.

Das klingt vielleicht nicht so beeindruckend. Es sind nur Regeln, Dokumentation, Tests und Rücksetzungen, Dinge, die es in der Softwareentwicklung schon seit langem gibt.

Aber wenn man eine Zahl sieht, versteht man: LangChain hat dasselbe Modell verwendet, den Prompt nicht geändert, sondern nur die Umgebung um das Modell herum angepasst, die Tool-Definition geändert, die Kontextverwaltung verbessert und eine Fehlerwiederherstellungsschleife hinzugefügt.

Das Ergebnis: In der gängigen Programmierfähigkeits-Benchmark TerminalBench 2.0 ist die Punktzahl von 52,8 % auf 66,5 % gestiegen, und die Platzierung ist von außerhalb der Top 30 auf die Top 5 gestiegen. Das Pferd ist nicht gewechselt, nur die Reitausrüstung. Diese Zahl spricht für sich.

02

Nachdem der Begriff populär geworden ist, hat sich die Entwicklerbranche schnell in zwei Lager aufgeteilt, und es gibt heftige Debatten.

Eine Gruppe glaubt, dass Harness überbewertet wird. Interessanterweise kommt der härteste Vertreter dieser Gruppe aus Anthropic selbst.

Boris Cherny, der Schöpfer von Claude Code, dem derzeit beliebtesten AI-Programmiertool, hat in einer Diskussion in einer Podcast-Community, die in der AI-Engineering-Branche sehr einflussreich ist, einen Satz gesagt, der die andere Seite sehr stört. Der Sinn ist ungefähr: Alle Geheimnisse von Claude Code liegen im Modell selbst. Es ist die dünnste Schicht um das Modell herum. Wir können es nicht einfacher machen.

Denken Sie mal darüber nach: Eine Gruppe ruft: „Harness ist alles!“ Dann sagt Ihnen der Mann, der eines der erfolgreichsten Agentenprodukte entwickelt hat, dass sein Produkt praktisch kein Harness hat. Das ist schon ein Schlag ins Gesicht.

Noam Brown von OpenAI ist noch direkter. Er sagt, dass es oft stört, wenn man ein Gerüst um das Inferenzmodell baut. Die Inferenzfähigkeit der Modelle verbessert sich ständig. Das, was man heute mit viel Mühe an Logik aufbaut, wird in einigen Monaten, wenn ein neues Modell kommt, zu einem Hindernis.

Unabhängige Tests unterstützen diese Gruppe:

Das Institut METR, das sich speziell mit der Bewertung von AI-Fähigkeiten befasst, hat einen strengen Vergleich durchgeführt. Das Ergebnis ist, dass Claude Code und Codex nicht signifikant besser als ein einfaches Gerüst performen.

Das Ergebnis des SWE-Atlas-Tests von Scale AI ist noch ärger. Egal welches Harness-Framework man verwendet, der Unterschied liegt im Bereich der Messungenauigkeit. Das heißt, man hat sich umsonst bemüht.

Nach diesen Informationen denken Sie vielleicht: Na ja, Harness ist nur ein Marketingkonzept?

Warten Sie mal. Es gibt noch ein noch verrückteres Experiment. Der Sicherheitsforscher Can Boluk hat ein Experiment namens Hashline durchgeführt. Er hat das Modell nicht verändert, den Prompt nicht geändert, sondern nur eine Sache geändert: das Format, in dem der Agent Code bearbeitet.

Wie hat er es geändert? Er hat jeder Codezeile einen Hash-Kennzeichen von 2 bis 3 Zeichen hinzugefügt. Wenn der Agent den Code ändert, muss er nicht die ganze Zeile wiederholen, sondern nur sagen: „Ersetze die Zeile 2:f1 durch das.“

Durch diese kleine Änderung ist die Programmierpunktzahl eines Modells von 6,7 % auf 68,3 % gestiegen, ohne dass die Modellgewichte um ein Byte verändert wurden. Was sagen Sie, ist Harness nützlich?

Der Gründer von LlamaIndex, einem anderen Unternehmen, das AI-Anwendungsentwicklungssysteme entwickelt, ruft direkt: Das Reitsystem des Modells ist alles. Er sagt, dass er in einem Nachmittag das Harness optimiert hat und die Codierungsfähigkeit von 15 großen Modellen verbessert hat.

Diese Gruppe hat noch eine starke kommerzielle Karte: Cursor.

Dieses Unternehmen hat kein eigenes Basis-Modell. Es nutzt die Fähigkeiten von Anthropic und OpenAI, also sozusagen fremde Pferde. Aber dank der Harness-Schicht über dem Modell hat es Ende 2025 einen Marktwert von 29,3 Milliarden US-Dollar erreicht. Im März 2026 wird über 50 Milliarden US-Dollar verhandelt. Das Jahresumsatz hat 2 Milliarden US-Dollar überschritten, und mehr als die Hälfte der Fortune 500-Unternehmen nutzen es.

Wo liegt seine Schutzmauer? In der Reitausrüstung.

Also, wer hat recht? Ich denke, sie sprechen über verschiedene Ebenen. Wenn man die Argumente beider Seiten betrachtet, wird man etwas Interessantes feststellen.

Boris Cherny sagt, dass Claude Code „die dünnste Schicht“ ist. Das stimmt tatsächlich. Die Produktarchitektur von Claude Code ist einfach, ohne aufwendige mehrstufige Logik.

Aber wenn man sieht, wie Boris Cherny selbst Claude Code verwendet, ist es anders: Er hat täglich 10 bis 15 Claude Code-Sitzungen offen, 5 in der Kommandozeile, 5 bis 10 im Browser und einige auf dem Handy.

Er verwendet automatisierte Hooks, um den Code automatisch zu formatieren, nachdem er gespeichert wurde. Er verwendet den Planungsmodus, um den Agenten zu zwingen, zuerst einen Plan zu erstellen, bevor er beginnt. Ohne Genehmigung des Plans darf er keinen Code schreiben. Er verwendet sogar Sub-Agenten für die Codeüberprüfung, um den Agenten die Arbeit des anderen Agenten überprüfen zu lassen. Er verbindet den Agenten mit einem Browser-Automatisierungstool, damit er selbst den Browser öffnet und Tests durchführt, um zu sehen, ob der geschriebene Code funktioniert.

Selbst er sagt: Wenn man dem Modell eine Möglichkeit gibt, seine eigene Arbeit zu validieren, kann die Qualität um das Zwei- bis Dreifache verbessert werden. Was sagen Sie, ist das kein Harness?

Einfach gesagt, wenn Boris Cherny von „dünn“ spricht, meint er die Produktarchitektur. Wenn die andere Seite von „dick“ spricht, meint sie die praktische Anwendung in der Softwareentwicklung.

Das Produkt kann einfach sein, aber in der Praxis muss man Regeln, Validierung und Rückkopplungsschleifen um das Modell herum aufbauen, damit es in echten Projekten nicht scheitert. Diese beiden Dinge widersprechen sich nicht.

Es ist wie wenn ein Rennfahrer sagt: „Mein Wagen hat eine einfache Fahrwerkstruktur.“ Aber bevor er jedes Mal auf die Rennstrecke geht, verbringt er drei Stunden damit, die Federung, den Reifendruck und die Bremsbalance einzustellen.

Eigentlich ist es etwas langweilig, darüber zu streiten, ob das Modell oder das Harness wichtiger ist. Es ist wie wenn man streitet, ob der Motor oder das Fahrwerk wichtiger ist. Jeder, der schon einmal gefahren ist, würde diese Frage nicht stellen.

03

Aber warten Sie mal. Wenn Harness wirklich so wichtig ist, gibt es eine Sache, die nicht logisch ist: Warum entfernen die besten Teams immer wieder das Harness, das sie gebaut haben?

Sie sollten von Manus gehört haben.

Sie haben ihr Harness fünf Mal in einem halben Jahr neu geschrieben. Jedes Mal haben sie Funktionen gestrichen, die komplexen Tool-Definitionen durch eine allgemeine Shell-Ausführung ersetzt und die Verwaltungsagenten durch strukturierte Übergabeunterlagen ersetzt. Je mehr sie tun, desto einfacher wird es.

Das Unternehmen hinter Next.js hat in seinem v0-Produkt 80 % der Agent-Tools entfernt, und das Ergebnis ist sogar besser. Auch Anthropic macht dies. Boris Cherny sagt, dass der Code von Claude Code alle drei bis vier Wochen neu geschrieben wird.

Warum wird es neu geschrieben?

Nachdem ein neues Modell herauskommt, ist viel von der Logik im vorherigen Harness vom Modell internalisiert worden. Diese Codezeilen werden überflüssig und stören eher.

Dies widerspricht der vorherigen Aussage: „Harness ist alles.“ Wenn es eine Schutzmauer ist, warum entfernen alle diese Schutzmauer? Weil Harness selbst keine Schutzmauer ist.

Der Forscher Nicholas Carlini von Anthropic hat mit dem Vorgänger-Modell von Claude, Opus 4.5, einen funktionierenden Compiler entwickelt. Später hat er auf Opus 4.6 umgestellt, und bei derselben Aufgabe konnte er den Linux-Kernel kompilieren.

Das Wichtigste ist, dass er jedes Mal, wenn er das Modell aktualisiert, das Harness neu entwerfen muss.

Weil das Modell stärker geworden ist, werden die „schützenden“ Logiken im alten Harness zu Einschränkungen, die die Dinge beschränken, die das neue Modell selbstständig tun kann. Er betont immer wieder: Beim Entwurf des Harness muss man von Claudes Perspektive aus denken.

Dies offenbart eine unangenehme Wahrheit:

Das heute sorgfältig entworfene Harness wird wahrscheinlich vom nächsten Modell „verschlungen“ werden. Heute braucht man Regeln, um zu verhindern, dass der Agent die Architektur durcheinander bringt. Morgen weiß das neue Modell vielleicht von Natur aus, dass es dies nicht tun sollte. Heute muss man einen speziellen Prüfungsagenten einsetzen, um die Qualität zu überprüfen. Übermorgen ist die Selbstbewertung des Modells vielleicht schon zuverlässig.

Das Gegenteil ist ebenfalls wahr.

Während der Anpassung des Harness hat LangChain eine große Menge an Ausführungsverfolgungsdaten gesammelt: Welche Pfade erfolgreich