Harness Engineering vs. Loop Engineering: was sie unterscheidet

Was ist ein Harness?

Für sich allein nimmt ein Sprachmodell eine Eingabe entgegen und erzeugt Text. Es kann keinen Code ausführen, sich nichts von einem Gespräch ins nächste merken und nicht auf Wissen zugreifen, das nach seinem Training entstanden ist. Damit es das kann, baut man ein Gerüst um das Modell: eine Schleife, die es immer wieder aufruft, Werkzeuge, die es nutzen kann, Dateien, die es in jeder Sitzung vorgelegt bekommt, und Prüfungen für seine Ausgabe. Dieses Gerüst heißt Harness.

Die weiteste Definition unter den Quellen, die wir gelesen haben, steht im Beitrag von LangChain: “A harness is every piece of code, configuration, and execution logic that isn’t the model itself.” Also aller Code, jede Konfiguration und jede Ausführungslogik außer dem Modell selbst. Auch Coding-Agenten haben eine solche Schicht. OpenAI nennt die Schicht, die Agentenschleife und Ausführungslogik liefert, “Codex harness”. Bei Anthropic heißt die Schicht, auf der Claude Code läuft, “agent harness”.

Harness Engineering heißt, dieses Gerüst zu entwerfen. Wir bauen selbst eines: diffox ist ein KI-Code-Review-Tool, das Pull Requests prüft. Die Beispiele unten stammen aus seiner Review-Pipeline und aus der Schleife, die es während eines Pull Requests durchläuft (wie es funktioniert, erklärt ein eigener Beitrag).

Wie die Quellen Harness Engineering definieren

Der Begriff ist neu, und die Quellen, die wir gelesen haben, definieren ihn unterschiedlich. Die Tabelle zeigt jede Quelle mit ihren eigenen Worten und ihrem Datum.

Quelle: die Seite des jeweiligen Beitrags, 15. Oktober 2026. Zitate in der Originalsprache.

Hashimoto beschreibt eine Gewohnheit und schreibt im selben Absatz, dass er nicht weiß, ob es dafür schon einen etablierten Begriff gibt. LangChain dagegen zieht eine Grenze: Alles außerhalb des Modells ist Harness. Der eine sagt Ihnen, was Sie tun sollen, der andere, wo Sie hinschauen müssen.

Zwei Details zeigt die Tabelle nicht. Die Formel “Agent = Model + Harness” steht im Beitrag von LangChain, nicht in dem von Hashimoto. Und das Wort „Harness“ ist älter als der Begriff: Anthropic nannte das Claude Agent SDK am 26. November 2025 einen “general-purpose agent harness”. In den fünf Anthropic-Beiträgen, die wir gelesen haben, kommt der Ausdruck “harness engineering” nicht vor.

Was Sie in jeder Schicht ändern

Die vier Begriffe sind nicht austauschbar, sondern vier ineinanderliegende Schichten. Nach Anthropics Definition geht es beim Prompt Engineering darum, Anweisungen für das Modell zu schreiben und zu ordnen. Beim Context Engineering geht es darum, auszuwählen und zu pflegen, welche Tokens dem Modell bei der Inferenz vorliegen. Dazu gehört auch alles, was außer dem Prompt dort landet. Kontext ist alles, was das Modell bei diesem Aufruf sieht.

Eine Primärquelle, die Context Engineering einer einzelnen Person zuschreibt, haben wir nicht gefunden. Die beiden Verwendungen, die wir gelesen haben, stammen aus dem Juni 2025: Tobi Lütke schrieb am 19. Juni, dass er diesen Namen “prompt engineering” vorzieht (“the art of providing all the context for the task to be plausibly solvable by the LLM”), Andrej Karpathy schloss sich am 25. Juni an. Anthropics Definition stammt vom 29. September 2025.

Harness Engineering liegt eine Schicht weiter außen. Es kümmert sich nicht nur darum, was das Modell sieht, sondern auch darum, was nach seiner Antwort passiert: welche Prüfungen die Ausgabe durchläuft, wie die Arbeit aufgeteilt wird und was sich ändert, wenn ein Fehler wiederkehrt. Die Schichten schließen einander ein: Laut LangChain dienen die heutigen Harnesses vor allem dazu, gutes Context Engineering umzusetzen. Loop Engineering liegt noch eine Schicht weiter außen: Es entwirft nicht einen einzelnen Lauf, sondern viele Läufe über die Zeit. Dazu weiter unten ein eigener Abschnitt.

Woraus ein Harness besteht

Die Beiträge, die wir gelesen haben, geben den Teilen unterschiedliche Namen. Jede der sechs Gruppen unten kommt in mindestens zwei Quellen vor.

Die Schleife ist der Kern. Anthropic beschreibt Agenten als Modelle, die in einer Schleife Werkzeuge nutzen und dabei auf Feedback aus ihrer Umgebung reagieren. Im Beitrag zum Agent SDK hat die Schleife diese Schritte: Kontext sammeln, handeln, die Arbeit prüfen, wiederholen. Werkzeuge und Beobachtbarkeit zeigen dem Modell, was seine Arbeit ergeben hat: In dem Repository, das OpenAI beschreibt, kann der Agent Logs, Metriken und Traces lesen. Subagenten teilen die Arbeit auf; laut Anthropic übernimmt jeder eine klar umrissene Aufgabe und startet mit einem sauberen Kontextfenster.

Prüfungen sind ein eigener Teil, denn die schreiben Sie, nicht das Modell. Laut dem Beitrag zum Agent SDK ist das beste Feedback eine Reihe klar definierter Regeln für die Ausgabe, dazu die Erklärung, welche davon verletzt wurde und warum. OpenAI setzt seine Architekturregeln maschinell durch, mit eigenen Lintern und Strukturtests.

Was ist Loop Engineering?

Der Harness kümmert sich um einen einzelnen Lauf. Loop Engineering stellt eine weitere Frage: Wer startet den Agenten, wann, und wer entscheidet, ob die Arbeit fertig ist? Den Namen prägte Addy Osmani in seinem Beitrag vom 7. Juni 2026: “Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.” Sie prompten den Agenten also nicht mehr Runde für Runde selbst, sondern entwerfen das System, das das übernimmt.

Am Anfang standen zwei Sätze. Peter Steinberger schlug am selben Tag vor, Agenten nicht mehr selbst zu prompten, sondern Schleifen zu bauen, die das tun. Nach Osmanis Darstellung hatte auch Boris Cherny, der Leiter von Claude Code, gesagt: “My job is to write loops”. Keiner der beiden verwendet den Ausdruck “loop engineering”; den Namen prägte erst Osmanis Beitrag.

Quelle: die Seite des jeweiligen Beitrags, 15. Oktober 2026. Zitate in der Originalsprache.

Über sechs Teile sind sich die Quellen einig. Die Übersichtsarbeit zählt sie so auf: ausgelöste Läufe, maschinell prüfbare Abbruchbedingungen, dauerhafte Zustandsdateien, Prüfer-Subagenten, Token-Budgets und Stellen, an denen ein Mensch übernimmt.

• Auslöser. Was einen Lauf startet: ein Timer oder ein Ereignis.
• Abbruchbedingung. Ein Kriterium, an dem eine Maschine erkennt, dass die Arbeit fertig ist: Die Tests sind grün, die Liste ist leer.
• Zustand. Was von einem Lauf zum nächsten erhalten bleibt; es liegt außerhalb des Kontextfensters.
• Prüfer. Eine Kontrolle, getrennt von dem Agenten, der die Arbeit macht.
• Budget. Eine Grenze für Runden oder Tokens; ist sie erreicht, hält die Schleife an.
• Übergabe an einen Menschen. Hier landet, was die Schleife nicht lösen kann, bei einem Menschen.

Anthropics Beitrag zeigt drei dieser Teile im Zusammenspiel. Jedes Mal, wenn Claude Code aufhören will, prüft ein separates Bewertungsmodell die Bedingung. Es schickt Claude Code zurück an die Arbeit, bis das Ziel erreicht ist oder die von Ihnen festgelegte Rundenzahl. Mit Osmanis Worten: So benotet der Agent, der den Code schreibt, nicht seine eigene Arbeit.

An einer Stelle gehen die Quellen auseinander: Welche Schleife ist mit „Loop“ gemeint? Die Übersichtsarbeit unterscheidet zwei. In der Agentenschleife ruft das Modell innerhalb eines einzelnen Laufs Werkzeuge auf und reagiert auf deren Ergebnis; sie gehört zum Harness. Loop Engineering dagegen kümmert sich um die Strukturen, die solche Läufe über die Zeit starten, prüfen und neu starten. Manche Anbieterbeiträge verwenden das Wort im ersten Sinn; auch Anthropics Engineering-Blog definiert den Harness als „die Schleife, die Claude aufruft“. In diesem Beitrag ist Loop im zweiten Sinn gemeint.

Auch der Begriff selbst hat sich noch nicht gefestigt. Laut derselben Übersichtsarbeit ist noch offen, ob Loop Engineering eine neue Disziplin, eine Übergangstechnik oder ein Marketing-Etikett ist. Im Juli 2026 wurde unter dem Namen “graph engineering” sogar schon ein Nachfolger vorgeschlagen.

Wie ein Harness in einem Code-Review-Tool aussieht

Wie die Teile zusammenspielen, zeigt die Review-Pipeline von diffox. Ein Pull Request durchläuft vier Phasen, bis daraus Kommentare werden; in jeder Phase wird eine Idee des Harness sichtbar.

Kontext & Zuordnung ist das, was der Harness dem Modell mitgibt, bevor es zu arbeiten beginnt. Die spezialisierten Agenten bekommen vier Dinge: den Diff, die Dateien vorher und nachher, die Beschreibung des Pull Requests und, falls vorhanden, die Regeldatei in Ihrem Repository (AGENTS.md oder CLAUDE.md). Die Regeldatei wird nicht aus dem Branch des Pull Requests gelesen, sondern aus dem Branch, in den er gemergt wird; so kann ein Pull Request die Regeln seines eigenen Reviews nicht ändern. Das garantiert kein Satz in der Anweisung, sondern der Ort, von dem die Datei gelesen wird.

Spezialistenprüfung heißt, die Arbeit aufzuteilen. Die Frage „Ist hier ein Fehler drin?“ ist weit gefasst. diffox lässt dieselbe Änderung deshalb von spezialisierten Agenten lesen. Im Team sind es 17; jeder hat seine eigene Anweisung und sucht nach genau einer Sache: einer nach Logikfehlern, einer nach Nebenläufigkeitsproblemen, einer nach Tests, die nichts prüfen.

Auch die Form der Ausgabe legt der Harness fest. Damit eine Feststellung zählt, muss sie drei Dinge enthalten: was sie behauptet, was in welcher Situation schiefgeht, und den Code, auf den sie sich stützt, wörtlich zitiert. Agenten nennen keine Zeilennummern; diffox findet die Zeile selbst, indem es das Zitat in der Datei sucht.

Auswahl & Ausgabe ist ein eigener Schritt. Jede Feststellung hat eine Klasse: Kritisch, Warnung oder Vorschlag. Im Pull Request erscheint, was Sie beheben sollten, also kritische Feststellungen und Warnungen. Vorschläge warten eine Weile auf der Seite Feststellungen in der Konsole, und Sie können davon veröffentlichen, was Sie möchten. Ein Review blockiert nie einen Merge.

Eine Prüfung, die sich nicht überreden lässt

In der dritten Phase, der Belegprüfung, zeigt sich die Idee des Harness in diesem Beispiel am deutlichsten. Ein Sprachmodell kann etwas Überzeugendes und doch Falsches schreiben: Es zitiert eine Zeile, die nicht in der Datei steht, beanstandet Code, den der Pull Request nicht berührt, oder nennt dasselbe Problem dreimal in drei verschiedenen Sätzen. Diese Phase bindet jede Feststellung nicht an das Wort des Modells, sondern an die Datei selbst.

Die Prüfungen sind kein Modellaufruf, sondern einfacher Code: Dieselbe Eingabe erhält jedes Mal dieselbe Antwort.

• Das Zitat der Feststellung wird in der Datei gesucht. Ein Zitat, das nicht gefunden wird, hat keine Zeile, auf die es zeigen könnte. Steht es in einer Zeile, die der Pull Request nicht geändert hat, liegt die Feststellung außerhalb des geprüften Bereichs.
• Feststellungen, die an derselben Stelle denselben Einwand erheben, werden zu einer zusammengeführt.
• Sagt eine Feststellung, der Code widerspreche einem Text, wird auch ihr zweites Zitat Wort für Wort gesucht.

Das Modell kann die Zitatprüfung nicht überreden, denn sie wägt keine Argumente ab; sie sucht nur das Zitat in der Datei.

Man kann ein Modell auch von einem anderen Modell prüfen lassen, aber das Ergebnis bleibt das Urteil eines Modells. Anthropic schreibt, dass sein Bewertungsmodell in den ersten Läufen echte Probleme fand, sich dann einredete, sie seien nicht wichtig, und die Arbeit trotzdem freigab. Deshalb ist es ein eigener Teil, mit Code zu prüfen, was sich mit Code prüfen lässt; Fragen, die ein Urteil verlangen, bleiben beim Modell.

In einem kleinen Projekt ist dieselbe Idee ein paar Zeilen lang. Das Beispiel unten ist nicht der Code von diffox; es zeigt das Muster.

# BEISPIEL: sucht das Zitat des Modells in der Datei
def quote_exists(finding: dict, files: dict[str, str]) -> bool:
    quote = finding.get("quote", "").strip()
    source = files.get(finding.get("file", ""), "")
    return bool(quote) and quote in source

Die Schleife über einen Pull Request

Ein einzelnes Review durchläuft einen Harness; ein Pull Request dagegen viele Reviews. Code entsteht, diffox prüft ihn, der Code ändert sich und wird erneut gepusht. Ob ein Mensch den Code schreibt oder ein Coding-Agent: Das ist eine Schleife, und jeder ihrer sechs Teile hat bei diffox eine Entsprechung im Code.

Die eigentliche Lehre dieser Schleife steckt in zwei Entscheidungen. Erstens: Der Prüfer wertet eine Änderung nicht als Erfolg. Ändern sich die Zeilen einer Feststellung, vermerkt der Kommentar am Ende nur, in welchem Commit das geschah. „Behoben“ steht dort nicht, denn auch umgeschriebener Code kann den Fehler noch enthalten. Ein Paper vom Juni 2026 stellt an die Abbruchregel dieselbe Bedingung: einen Fehler niemals für einen Erfolg halten.

Zweitens: Die Abbruchbedingung wählen Sie. Automatische Reviews stoppen pro Pull Request an einer Grenze, die Sie im Tab Einstellungen der Konsole ändern können. Danach fordern Sie ein neues Review an, indem Sie diffox in einem Kommentar erwähnen. Auch die Entscheidung über den Merge liegt bei Ihnen: Ein Review blockiert nie einen Merge. Hier gibt die Schleife an einen Menschen ab.

Wie ein Harness an Fehlern wächst

Einen Harness baut man nicht einmal und überlässt ihn dann sich selbst. Hashimoto beschreibt zwei Wege: für einfache Fehler eine Zeile in der Regeldatei, für den Rest ein eigens programmiertes Werkzeug. Er schreibt, dass jede Zeile in der Regeldatei seines Projekts auf ein Fehlverhalten eines Agenten zurückgeht.

OpenAIs Beitrag beschreibt dieselbe Schleife in einem Team: Den gesamten Code des Produkts schreibt Codex, die Entwickler bauen die Umgebung. Hat der Agent Schwierigkeiten, werten sie das als Signal: Sie suchen, was fehlt, ob Werkzeug, Schutzmechanismus oder Dokumentation, und nehmen es ins Repository auf. Reicht die Dokumentation nicht, wandert die Regel in den Code. Die Regeldatei bleibt kurz: eine AGENTS.md von etwa 100 Zeilen, ein Inhaltsverzeichnis statt einer Enzyklopädie.

Es gibt auch die Gegenrichtung. Laut Anthropic steht jeder Teil eines Harness für eine Annahme darüber, was das Modell allein nicht kann, und diese Annahmen können veralten, wenn die Modelle besser werden. Kommt ein neues Modell, wird der Harness neu durchgesehen, und Teile, die nichts mehr tragen, werden entfernt.

Während wir dieses Tool entwickelt haben, sind in unserem eigenen Repository aus dieser Schleife drei Gewohnheiten entstanden:

• Neben jeder Regel steht der Fehler, der sie nötig gemacht hat. Eine Regel ohne aufgeschriebenen Grund löscht der Erste, den sie stört.
• Einem Test vertrauen wir erst, wenn er ohne die Korrektur rot wird. Auch ein Test, der nichts prüft, ist grün.
• Ändern wir eine Prüfung im Code, lassen wir die alte und die neue Fassung über gespeicherte Ergebnisse laufen. Dafür braucht es keinen neuen, bezahlten Lauf, und wir sehen einzeln jeden Fall, in dem die beiden Fassungen voneinander abweichen.

Wo Sie im eigenen Projekt anfangen

Um anzufangen, müssen Sie weder ein Framework wählen noch das Modell wechseln. In dem Coding-Agenten, den Sie nutzen, läuft bereits ein Harness; Sie ergänzen ihn um die Teile Ihres eigenen Projekts.

Erkennen Sie zuerst den Fehler, und wählen Sie dann das günstigste Mittel. Bei einfachen Fehlern ist das erste Mittel eine Zeile in der Regeldatei. Wiederholt sich der Fehler trotz der Regel, bringen Sie die Regel in den Code: eine Linter-Regel, einen Test, ein Skript. Anthropics allgemeine Empfehlung gilt auch hier: Suchen Sie die einfachste Lösung, und erhöhen Sie die Komplexität nur, wenn es nötig ist.

Beim ersten eigenen Loop ist die Reihenfolge dieselbe: Vergewissern Sie sich zuerst, dass ein einzelner Lauf zuverlässig ist, und schreiben Sie dann die Abbruchbedingung und die Grenze. Anthropics Empfehlung ist eindeutig: Anhalten, wenn das Ziel oder die Höchstzahl an Runden erreicht ist. Damit der Token-Verbrauch im Rahmen bleibt, braucht die Schleife klare Grenzen.