Loop Engineering, Harness Engineering, Context Engineering: was bedeutet was?

Boris Cherny, Head of Claude Code bei Anthropic, sagte Anfang Juni 2026: „Ich prompte Claude nicht mehr. Ich schreibe Loops, die Claude prompten." Nur wenige Tage später, am 7. Juni 2026, hat Addy Osmani, Engineering Lead bei Google Chrome, daraus den Begriff Loop Engineering gemacht. Seitdem taucht das Wort überall auf: in Slack-Kanälen, in Kundengesprächen, in Tech-Podcasts. Nur sagt kaum jemand das Gleiche damit. Diese Folge der Blogreihe sortiert die drei Begriffe, die gerade durcheinandergeraten (Loop Engineering, Harness Engineering, Context Engineering) und zeigt, wie sie zusammenhängen.

Drei Begriffe, eine Verwirrung: warum die Sortierung jetzt zählt

Seit Cherny sein Statement absetzte und Osmani am 7. Juni 2026 den Begriff Loop Engineering prägte, ist eine Begriffs-Welle losgerollt. Innerhalb weniger Wochen war das Wort überall, nur meinte es an jeder Stelle etwas anderes. Am deutlichsten sieht man das dort, wo man es am wenigsten erwartet: In unseren eigenen internen Kanälen diskutierten erfahrene codecentric-Consultants tagelang, ob „Loop Engineering" nun das Bauen der Leitplanken meint, das Automatisieren der Wiederholung oder einfach das ganze Feld autonomer Agenten.

Das ist kein Randproblem. Wenn Leute, die täglich mit diesen Systemen arbeiten, den Begriff unterschiedlich füllen, dann reden Kunde und Berater im Zweifel komplett aneinander vorbei. Jemand fragt: „Braucht mein Team Loop Engineering?", und je nachdem, wen er fragt, bekommt er eine Antwort über Prompts, über MCP-Server oder über Cron-Jobs. Innerhalb von Teams entstehen dieselben Missverständnisse.

Genau deshalb sortieren wir hier. Nicht, um einen Begriff für uns zu reklamieren, sondern um Ordnung in ein Feld zu bringen, das gerade ohne klare Kanten wächst. Wer die drei Ebenen sauber trennt, kann präziser fragen, präziser bauen und präziser einkaufen. Wie wir bei codecentric über KI-Systeme denken, steckt in genau dieser Trennschärfe. Mehr dazu auf unserer Seite zu Künstlicher Intelligenz.

Was ist Context Engineering? Die unterste Schicht

Context Engineering bezeichnet die Disziplin, einem KI-Modell die richtigen Informationen für die nächste Aufgabe bereitzustellen. Es bestimmt, was in einem einzelnen Prompt steht: Code-Ausschnitte, Architektur-Hinweise, Beispiele, Constraints. Sauberes Context Engineering ist die Grundlage für alles, was darauf aufbaut.

Was gehört rein? Sauberes Context Engineering heißt, dem Modell genau die Bausteine zu geben, die es für die nächste Aufgabe braucht: relevante Code-Ausschnitte im richtigen Umfang, Architektur-Hinweise im richtigen Detail, konkrete Constraints, gute Beispiele. „Im richtigen Umfang" ist dabei die eigentliche Kunst. Man kippt nicht das ganze Repository ungefiltert hinein, betrachtet aber auch nicht eine einzelne Funktion völlig isoliert. Es geht um Kuratierung, also die richtige Auswahl aus vielen möglichen Quellen: Dokumenten, Memory-Files, Tool-Definitionen, Domänenwissen und der bisherigen Nachrichten-Historie.

Genau dieser Unterschied vom einzelnen Prompt zum kuratierten Kontext für einen Agenten lässt sich schwer in einem knappen Code-Schnipsel zeigen, weil er über viele Files, Skills und Quellen hinweg passiert. Das folgende Schaubild macht ihn greifbar.

Diese Darstellung stammt aus Anthropics Blogpost „Effective context engineering for AI agents". Sie bringt den Unterschied zwischen einzelnem Prompt und kuratiertem Kontext-Fenster für einen Agenten so klar auf den Punkt, dass wir sie hier unverändert übernommen haben.

Was bleibt draußen? Alles, was nicht zur konkreten Aufgabe gehört: irrelevante Code-Teile („Hintergrundrauschen"), Negativ-Beispiele ohne Lern-Mehrwert, redundante Doku und abgelaufene Spec-Stände. Wie das Schaubild zeigt, ist der Schritt von „Possible context" zu „Context window" ein bewusstes Kürzen, im Bild sinnbildlich die Schere. Der Unterschied zwischen gutem und schlechtem Kontext liegt selten im Hinzufügen, sondern meistens im gezielten Weglassen.

Warum ist das die Grundlage für alles Weitere? Weil jede Ebene darüber auf dem Kontext aufsetzt. Wackelt das Fundament, wackelt der Rest. Loop Engineering ohne sauberes Context Engineering wird zu Iterations-Theater, denn der Loop wiederholt dann nur schneller, was auf schlechtem Kontext beruht.

Was ist Harness Engineering? Die Leitplanken um den Coding Agent

Harness Engineering bezeichnet die Leitplanken um einen Coding Agent: Tools, Skills, MCP-Server, System-Prompts, Hooks, Sandboxes und Observability. Das Modell wird damit erst handlungsfähig in einem konkreten technischen Kontext.

Warum gibt der Harness den Ausschlag? Ein Agent ist immer Modell plus Harness, und der Harness gibt oft den Ausschlag. Nicht das stärkste Modell gewinnt, sondern das am besten ausgestattete. Ein solides Modell mit einer durchdachten Umgebung schlägt in der Praxis regelmäßig ein Spitzenmodell in einer schlechten Umgebung. (Osmani-Beitrag)

Wir bei codecentric fassen das in einer Gleichung zusammen: Agent = Model + Tool Harness + User Harness. Das Modell ist der Kern. Der Tool Harness bringt Werkzeuge und Orchestrierung mit, etwa in Claude Code oder Cursor. Der User Harness ist das projektspezifische System aus Regeln, Tests und Kontextdokumenten, das wir als Entwickler selbst gestalten. Wie sich diesen User Harness systematisch aufbaut, beschreiben wir ausführlich in unserem Softwerker-Artikel „Leitplanken für Coding Agents".

Was gehört in so einen Harness? Konkret die Tools, mit denen der Agent handelt, die Skills und MCP-Server, die ihm Fähigkeiten und Datenzugang geben, die System-Prompts, die sein Verhalten rahmen, die Hooks, die an den richtigen Stellen eingreifen, die Sandboxes, in denen er gefahrlos ausführen darf, und die Observability, die sichtbar macht, was er tut. Erst dieses Bündel macht aus einem Sprachmodell einen Agenten, der in einem echten Repository etwas bewegt.

Wie ordnet man diese Bausteine? Eine bewährte Struktur unterscheidet zwei Wirkungsrichtungen: Guides und Sensors. Guides wirken vor der Codegenerierung (Feedforward). Sie geben dem Agenten Kontext, Regeln und Vorgaben, bevor er eine Zeile schreibt. Sensors wirken nach der Generierung (Feedback). Sie prüfen das Ergebnis und liefern dem Agenten Rückmeldung zur Selbstkorrektur. Dieses Begriffspaar beschreiben wir ausführlich in unserem Softwerker-Artikel „Leitplanken für Coding Agents".

Statt Code zeigt sich ein Harness am besten als Kombination aus Tools und Techniken. So könnte ein konkreter Harness für einen Coding Agent aussehen, der einen REST-Endpunkt in einer Schichtenarchitektur baut:

• Guides: eine CLAUDE.md mit den Namens- und Architekturkonventionen des Projekts, eine OpenAPI- oder Feature-Spec als Vertrag, ein Bootstrap-Template für die Modulstruktur und ein MCP-Server (etwa Context7) für aktuelle Framework-Doku.
• Sensors: ArchUnit-Tests, die die Schichttrennung erzwingen, ein Linter wie ESLint als Self-Correction-Trigger, ein Coverage-Schwellenwert und ein Review-Agent (LLM as a Judge), der die vorgeschlagenen Code-Änderungen daraufhin prüft, ob sie die fachliche Anforderung erfüllen.

Kein einzelnes Tool trägt die Qualität, sondern die Kombination. Erst dieses Zusammenspiel aus Guides und Sensors macht aus einem generischen Modell einen Agenten, der die Standards eines konkreten Projekts trifft.

Wie sehr der Harness den Ausschlag gibt, zeigt ein Beispiel von Anthropic. Ein Initializer-Agent legt eine Progress-Datei an, ein zweiter Coding-Agent arbeitet sie Schritt für Schritt ab und schreibt seinen Fortschritt zurück in dieselbe Datei. Nötig ist dafür kein exotisches Modell, sondern durchdachte Leitplanken, die einen langen Lauf überhaupt erst tragfähig machen. (Anthropic Engineering)

Ein Harness beschreibt damit die Werkbank für einen einzelnen Agenten: welche Werkzeuge er hat, welche Regeln er kennt, wie sein Ergebnis geprüft wird. Sobald dieser Agent aber nicht mehr Aufgabe für Aufgabe von einem Menschen angestoßen werden soll, sondern eigenständig weiterlaufen, wird aus dem Harness eine Loop.

Was ist Loop Engineering? Die nächste Ebene darüber

Loop Engineering bezeichnet das System, das einen KI-Agenten wiederholt anstößt, Helfer-Agenten startet, Ergebnisse verifiziert und sich selbst speist, ohne dass ein Mensch turn-by-turn promptet. Loop Engineering setzt auf Harness Engineering auf und automatisiert die Wiederholung.

Was ist der Perspektivwechsel dahinter? Der emotionale Kern dieser Ebene steckt in Chernys Satz: „Ich prompte Claude nicht mehr. Ich schreibe Loops, die Claude prompten." Das ist der Perspektivwechsel weg vom Menschen, der Zug um Zug promptet, hin zum System, das den Agenten selbst antreibt.

Woraus besteht ein Loop? Osmani nennt fünf Bausteine, aus denen sich so ein Loop zusammensetzt: Automations (was den Lauf anstößt und taktet), Worktrees (isolierte Arbeitsbereiche für parallele Läufe), Skills (persistente Fähigkeits-Doku), Plugins & Connectors (Werkzeug- und Datenanbindung, unter anderem via MCP) und Sub-Agents (Helfer, die Teilaufgaben abarbeiten und prüfen). Dazu kommt die Memory als externer Zustand, „eine Markdown-Datei, ein Linear-Board, irgendetwas, das außerhalb lebt". (Osmani-Beitrag) Fehlt dieser Zustand, verliert der Loop zwischen den Iterationen den Faden.

In der Praxis sieht das ganz unterschiedlich aus: zeitgesteuerte Triage-Loops, die morgens offene Issues sichten, parallele Arbeit in mehreren Git-Worktrees, Sub-Agents, die Teilaufgaben abarbeiten und ihre Ergebnisse zurückmelden. Ein konkretes Beispiel aus unserer eigenen Praxis ist der Ralph-Wiggum-Loop, eine autonome Code-Generierung, die jede Iteration mit frischem Kontext startet.

Wo hört Loop Engineering auf? Bei einem einzelnen Coding-Vorgang. Es orchestriert das wiederholte Bauen und Prüfen von Code nicht mehr. Alles darüber, also die Black-Box-Verifikation ganzer Systeme, das Lernen aus der Produktion und der Anschluss an die Geschäftslogik, gehört in andere Modelle und ist Thema späterer Folgen dieser Reihe.

Loop Engineering vs. Harness Engineering: wo ist der Unterschied?

Aspekt	Harness Engineering	Loop Engineering
Was es ist	Leitplanken (Guides und Sensors) um einen Coding Agent	System, das einen Agenten wiederholt anstößt
Wer steuert	Mensch promptet, Agent arbeitet	Loop promptet, Mensch beobachtet
Disziplin	Software-Architektur, Tooling, DevX	Workflow-Automatisierung, Verification, DevOps
Typische Frage	„Welche Guides und Sensors braucht mein Agent?"	„Was braucht die Loop, um möglichst lange ohne mich auszukommen?"
Beispiel	CLAUDE.md, OpenAPI-Spec, ArchUnit-Tests, Linter, Review-Agent	Ralph-Wiggum-Loop, Cron-Trigger, test-gated Loops, Sub-Agents

Beide Ebenen greifen ineinander, spielen aber unterschiedliche Rollen. Der Harness ist das Konstrukt aus Werkzeugen: die Guides und Sensors, die einen Agenten führen und prüfen. Die Loop ist das Produktionslaufband, das diesen Agenten immer wieder anstößt, seine Ergebnisse verifiziert und ihn ohne dein Zutun weiterlaufen lässt.

Deshalb ist die Reihenfolge keine Geschmacksfrage: erst Context, dann Harness, dann Loop. Jede Ebene erbt die Schwächen der darunterliegenden. Ein Loop, der einen lückenhaften Harness immer wieder aufruft, macht den Fehler nicht kleiner, sondern wiederholt ihn nur schneller. Wer am Anfang spart, baut wackelig nach oben.

Bleibt die praktische Frage, die sich in Projekten wirklich stellt: Woran erkenne ich, welche Ebene ich gerade brauche?

Wann brauche ich was? Eine Orientierung

1. Wenn dein Agent in einer einzelnen Aufgabe nicht zuverlässig liefert, verbessere das Context Engineering (Prompts, System-Prompts, Eingabe-Strukturierung, Files).
2. Wenn dein Agent liefert, aber die Qualitäts- und Domänen-Standards deines Projekts verfehlt oder seine Fehler nicht selbst bemerkt, baue das Harness Engineering aus. Guides führen ihn (CLAUDE.md, Specs, Templates), Sensors prüfen sein Ergebnis und lassen ihn selbst korrigieren (Linter, Architektur-Tests, Review-Agents).
3. Wenn dein Agent autonom über Stunden oder Tage laufen soll, ohne dass du ihn Schritt für Schritt anstößt, führe Loop Engineering ein (Trigger, Verification, Correction, Memory, Sub-Agents).

Die drei Ebenen lösen sich nicht ab, sie bauen aufeinander auf. Ohne sauberen Context bringt der beste Harness nichts. Ohne Harness läuft kein Loop. Wer am Loop spart, baut auf wackeligem Fundament.

Was Loops gerade gefährlich macht: die drei offenen Risiken

So überzeugend die drei Ebenen klingen, Osmani selbst warnt in seinem Original-Blogpost vor drei Risiken, die genau dann auftreten, wenn Loops unbeaufsichtigt laufen. Wer Loop Engineering ernst nimmt, muss sie mitdenken statt wegdenken.

1. Mangelnde Verifikation unbeaufsichtigter Loops. Sie laufen weiter, auch wenn der Output längst falsch ist. Osmani bringt es auf den Punkt: „A loop running unattended is also a loop making mistakes unattended."
2. Verständnisverlust durch schnelle Automatisierung. Wer den Loop schreibt, versteht das darunterliegende Problem oft nicht mehr im Detail. Osmani: „Your understanding still rots if you allow it."
3. Kognitive Kapitulation, also das unkritische Akzeptieren von Loop-Outputs statt eigener Urteilsfähigkeit. Osmani beschreibt die Versuchung, „to stop having an opinion and just take whatever it gives back."

Alle drei haben denselben Kern: Ein Loop verstärkt, was man ihm gibt, gute Arbeit wie schlechte. Verifikation ist der einzige Punkt, an dem dieser Verstärker gebremst wird.

Wer Loops baut, ohne diese drei Risiken zu adressieren, baut einen teuren Linter, der halluziniert. Wie man Verification ernst nimmt, ist Thema der nächsten Folge.

FAQ: die häufigsten Fragen

Ist Loop Engineering dasselbe wie Agentic Engineering? Nein. Agentic Engineering beschreibt einzelne autonome Agenten, Loop Engineering beschreibt das System, das Agenten wiederholt anstößt, verifiziert und speist.

Brauche ich erst Harness Engineering, bevor ich Loop Engineering machen kann? Ja. Ein Loop ohne ordentlichen Harness erbt deren Schwächen. Die Loop-Wiederholung verstärkt Context- oder Tool-Fehler, statt sie zu mildern.

Wer hat den Begriff Loop Engineering geprägt? Addy Osmani (Engineering Lead, Google Chrome) am 7. Juni 2026, ausgelöst durch ein virales Statement von Boris Cherny (Head of Claude Code, Anthropic) wenige Tage zuvor.

Ist Context Engineering noch relevant, wenn Loop Engineering das nächste Level ist? Ja, mehr denn je. Loops verstärken Context-Fehler, statt sie zu mildern. Schlechter Kontext im Loop multipliziert seine Auswirkungen über die Iterationen.

Was unterscheidet Loop Engineering von klassischer Workflow-Automatisierung? Loops sind nicht-deterministisch. Das Modell entscheidet selbst über den Pfad innerhalb der Iteration. Klassische Workflows folgen festen, vorab definierten Pfaden.

Weiterführende Lektüre

Wer tiefer einsteigen will, findet in diesen Quellen thematisch wertvolles Material, das oben nicht zitiert ist:

• codecentric: „Leitplanken für Coding Agents: Wie Harness Engineering die Softwarequalität sichert" (unser Softwerker-Artikel zu Guides, Sensors und dem Framework aus deterministischen und inferentiellen Prüfungen)
• Cobus Greyling: „Loop Engineering" (Substack-Synthese mit der Hierarchie Context, Harness, Loop)
• GitHub: „Awesome Harness Engineering" (kuratierte Liste mit Tools, Patterns, Evals, Memory, MCP, Permissions)
• The New Stack: „The Anthropic leader who built Claude Code says he ditched prompting" (Hintergrundartikel zum Cherny-Statement)
• Anthropic Engineering: „Harness Design for Long-Running Applications" (vertiefter zweiter Anthropic-Beitrag)

Schluss

In der nächsten Folge schauen wir uns das erste der drei Risiken genauer an und klären, warum ein Loop ohne Verification ein teurer Linter ist.