Harness Engineering: Was jeder KI-Ingenieur im Jahr 2026 wissen muss

Im Februar 2026 hat ein kleines OpenAI-Team 1 Million Zeilen Produktionscode ausgeliefert.

Keine einzige Zeile wurde von Hand geschrieben.

Die KI-Agenten haben es geschrieben.

Die Menschen haben das System entworfen, das die Agenten zuverlässig gemacht hat.

Dieses System hat jetzt einen Namen.

Harness Engineering.

Innerhalb weniger Wochen veröffentlichte Anthropic 3 Arbeiten dazu.

ThoughtWorks formalisierte ein Framework.

Philipp Schmid von Hugging Face nannte es „die wichtigste Disziplin des Jahres 2026."

Eine neue Ingenieurdisziplin materialisierte sich in 90 Tagen.

Und fast niemand außerhalb von KI-Infrastrukturteams versteht sie bisher.

Dieser Artikel erklärt alles.

Kein Blabla. Kein akademisches Fachchinesisch. Nur die Denkmodelle, die Sie brauchen, um das tatsächlich zu nutzen.

Speichern Sie sich das. Sie werden es zweimal lesen.

TEIL 1: WAS EIN HARNESS EIGENTLICH IST (Das Konzept, das Ihre Denkweise über KI verändert)

1. Die Harness-Definition

Die einfachste Definition stammt von ThoughtWorks:

→ Agent = Modell + Harness

Der Harness ist alles, was nicht das Modell ist.

Die Einschränkungen, die den Agenten auf Kurs halten. Die Feedbackschleifen, die Fehler abfangen. Die Dokumentation, die dem Agenten sagt, wo er ist. Die Werkzeuge, die er verwenden darf.

Ohne Harness → ein reines Sprachmodell, das sich durch Ihre Codebasis rät.

Mit dem richtigen Harness → ein System, das Produktionscode ausliefert.

Der Name kommt vom Pferdegeschirr.

Ein Kumt ist das Zaumzeug, der Sattel und das Gebiss, die ein kraftvolles, aber unberechenbares Tier in eine nützliche Richtung lenken.

Man macht das Pferd nicht klüger. Man entwirft die Ausrüstung, die seine Stärke nutzbar macht.

2. Die Betriebssystem-Analogie

Philipp Schmid lieferte die beste technische Einordnung:

Stellen Sie es sich wie einen Computer vor.

→ Modell = CPU (reine Rechenleistung)

→ Kontextfenster = RAM (begrenzter, flüchtiger Arbeitsspeicher)

→ Harness = Betriebssystem (verwaltet, was die CPU sieht und wann)

→ Agent = Die Anwendung die darauf läuft

Ihr Modell ist leistungsstark.

Aber ohne ein Betriebssystem, das den Speicher verwaltet, Aufgaben plant und Regeln durchsetzt – ist es nur Silizium.

Die meisten Leute betreiben Anwendungen ohne Betriebssystem.

Deshalb scheitern ihre Agenten in der Produktion.

3. Was sich 2026 geändert hat

LangChain ließ dasselbe Modell zweimal auf Terminal Bench 2.0 laufen.

Gleiches Modell. Anderer Harness.

→ Alter Harness: 52,8 % Punktzahl

→ Neuer Harness: 66,5 % Punktzahl

Vercel ging den umgekehrten Weg.

Sie entfernten 80 % der Werkzeuge ihres Agenten.

Ergebnis? Bessere Leistung.

Nicht schlechter.

Die unbequeme Wahrheit des Jahres 2026:

→ Der Agent war nie der schwierige Teil.

→ Der Harness ist es.

Wenn 2025 das Jahr war, in dem KI-Agenten bewiesen haben, dass sie Code schreiben können…

dann ist 2026 das Jahr, in dem wir entdeckt haben, dass die Umgebung wichtiger ist als das Modell.

TEIL 2: DIE 5 HARNESS-ARTEFAKTE (Wie ein Harness in der Praxis tatsächlich aussieht)

4. AGENT.md / CLAUDE.md Dateien

Das universellste Harness-Artefakt.

Markdown-Dateien, die über Ihre gesamte Codebasis verteilt sind.

Der Agent liest sie zu Beginn jeder Sitzung – wie Einführungsdokumente für einen neuen Ingenieur im Team.

Was kommt hinein:

→ Projektkontext

→ Programmierkonventionen

→ Architekturentscheidungen

→ Leitfaden „Wie wir die Dinge hier machen"

→ Was gerade in Arbeit ist

OpenAI nennt sie AGENT.md.

Anthropic nennt sie CLAUDE.md.

Cursor verwendet .cursorrules.

Verschiedene Namen. Gleiches Prinzip.

Eine Datei pro Hauptmodul. Aktualisiert, während das Projekt wächst.

Ohne sie: Der Agent beginnt jede Sitzung blind. Mit ihnen: Der Agent beginnt jede Sitzung informiert.

5. JSON-Funktionslisten (Der Fortschritts-Tracker)

Wenn ein Agent eine ganze App über mehrere Sitzungen hinweg erstellt, beginnt er jede Sitzung mit einem leeren Kontextfenster.

Woher weiß er, was schon erledigt ist?

Eine JSON-Datei.

Jeder Eintrag definiert:

→ Eine Funktion

→ Wie man überprüft, ob sie funktioniert

→ Status „Bestanden" / „Nicht bestanden"

Der Agent liest dies zu Sitzungsbeginn. Wählt die höchstpriorisierte, nicht bestandene Funktion aus. Implementiert sie. Markiert sie als bestanden. Macht einen Commit. Wiederholt.

Warum JSON und nicht Markdown?

Anthropic hat herausgefunden, dass Agenten JSON weniger wahrscheinlich versehentlich überschreiben als Markdown.

Kleines Detail. Macht bei 6-stündigen autonomen Läufen einen großen Unterschied.

6. Sitzungsinitialisierungsroutinen

Jede Sitzung beginnt auf die gleiche Weise.

Jedes. Einzelne. Mal.

Anthropics 7-stufige Startsequenz:

1. Arbeitsverzeichnis bestätigen
2. Git-Protokolle und Fortschrittsdateien lesen
3. Funktionsliste auf das höchstpriorisierte unvollständige Element prüfen
4. Dev-Server starten
5. Grundlegende End-to-End-Überprüfung durchführen
6. Eine Funktion implementieren
7. Commit mit beschreibender Nachricht + Fortschrittsaktualisierung

Ohne dies:

Verschwendet der Agent seine ersten 20 Minuten damit, herauszufinden, was bereits existiert.

Jede Sitzung erfindet das Rad neu.

Damit:

Startet der Agent sofort informiert und geht direkt zur Arbeit über.

7. Sprint-Verträge (Sprint Contracts)

Bevor der Agent auch nur eine einzige Zeile Code schreibt:

Verhandeln zwei Agenten.

Generator-Agent schlägt vor:

→ Was er bauen wird

→ Wie der Erfolg überprüft wird

Evaluator-Agent prüft:

→ Ist der Vorschlag vollständig?

→ Sind die Erfolgskriterien klar?

Erst wenn beide zustimmen, beginnt die Implementierung.

Es ist ein Design-Review.

Nur dass beide Teilnehmer KI sind.

Warum ist das wichtig?

Agenten, die im selben Durchgang planen und ausführen, produzieren unzuverlässige Ergebnisse.

Der Planungsschritt – selbst wenn von KI durchgeführt – verbessert die Ausgabequalität dramatisch.

8. Strukturierte Aufgabenbausteine (Structured Task Templates)

Vor jeglicher Codierung:

Analysiert der Harness die reale Codebasis.

Er erstellt eine fundierte Auswirkungskarte:

→ Echte Dateipfade (nicht halluzinierte)

→ Reale Symbolnamen, die tatsächlich existieren

→ Vorhandene Muster, denen man folgen kann

→ Konkrete Abnahmekriterien

Dann beginnt die Implementierung.

Das klingt offensichtlich.

Aber die meisten Teams überspringen es.

Der Agent rät bei Dateistrukturen. Erfindet API-Endpunkte, die nicht existieren. Baut etwas, das nicht in die Codebasis passt.

Fundierter Kontext vor der Ausführung → massiv bessere Ergebnisse.

TEIL 3: DIE DREI LAGER (Drei Teams trafen auf dieselbe Wand – und bauten drei verschiedene Leitern)

9. OpenAI: Umgebung zuerst

Das Codex-Team von OpenAI hatte ein absurdes Problem.

1 Million Zeilen Produktionscode. Keine einzige von Hand geschrieben.

In diesem Maßstab kann man nicht jede Zeile code-reviewen.

Also taten sie es nicht.

Stattdessen:

Gestalteten sie die Umgebung so gründlich, dass die Agenten überhaupt erst überprüfbare Ergebnisse produzierten.

Ihr Ansatz:

→ Strenge Abhängigkeitsflüsse (Typen → Konfiguration → Repository → Service → Laufzeit → UI)

→ AGENT.md-Dateien in der gesamten Codebasis

→ Agenten direkt in CI/CD-Pipelines integriert

Die Philosophie: Gestalte die Umgebung. Lass dann den Agenten los.

Der Beweis: Sora Android App. 4 Ingenieure. 28 Tage. Platz 1 im Play Store. 99,9 % absturzfrei.

Codex erledigte wöchentlich 70 % der internen Pull-Requests.

10. Anthropic: Trenne den Macher vom Richter

Anthropic hatte ein anderes Problem.

Als sie den Agenten baten, seine eigene Leistung zu bewerten:

Lobte er selbstbewusst die Arbeit.

Selbst wenn die Qualität für einen menschlichen Beobachter offensichtlich mittelmäßig war.

Selbstevaluation funktioniert nicht.

Der Agent war sowohl der Schüler als auch der Lehrer.

Und er gab sich selbst glatte Einsen.

Ihre Lösung: Drei spezialisierte Agenten.

→ Planer – verwandelt einen 2-Satz-Prompt in ein vollständiges Produktpflichtenheft

→ Generator – implementiert Funktionen einen Sprint nach dem anderen

→ Evaluator – testet die laufende App mittels Browserautomatisierung wie ein echter Benutzer

Die Erkenntnis: Es ist weitaus einfacher, einen eigenständigen Evaluator skeptisch zu machen, als einen Generator kritisch gegenüber der eigenen Arbeit.

Ergebnis: Solo-Agent (kein Harness): 9 $, 20 Min.

→ defekte App Vollständiger Harness: 200 $, 6 Std.

→ funktionierende Software mit polierter Benutzeroberfläche

11. ThoughtWorks: Das 2×2-Framework

ThoughtWorks kam aus einem anderen Blickwinkel.

Sie bauten kein Produkt.

Sie beobachteten, wie 50+ Engineering-Teams an denselben Dingen scheiterten.

Ihre Erkenntnis: Klassifiziere jede Harness-Steuerung entlang zweier Achsen.

Achse 1: Wann läuft sie?

→ Vorausschauend (Feedforward) = bevor der Agent handelt (Leitplanken)

→ Rückblickend (Feedback) = nachdem der Agent handelt (Sensoren)

Achse 2: Wie funktioniert sie?

→ Rechnerisch = deterministisch, Millisekunden (Linter, Typprüfer, Testsuiten)

→ Inferenziell = verwendet ein LLM, Sekunden (Code-Review-Agent, semantische Analyse)

Das 2×2:

→ Rechnerisch vorausschauend: Typsysteme, Linter, Architekturregeln

→ Rechnerisch rückblickend: Testsuiten, Codeabdeckungsanalyse, Mutationstests

→ Inferenziell vorausschauend: Spezifikationsdokumente, Einschränkungsbeschreibungen

→ Inferenziell rückblickend: LLM-Code-Reviewer, Verhaltensvalidierer

Weder Vorausschau noch Rückblick allein funktioniert.

Sie brauchen beides.

TEIL 4: DIE 5 PRINZIPIEN, AUF DIE SICH ALLE LAGER EINIGEN (Drei Teams haben nie koordiniert. Sie sind unabhängig voneinander hier angekommen.)

12. Prinzip 1: Kontext schlägt Anweisungen

OpenAI: „Gib eine Karte, kein 1000-seitiges Handbuch."

Anthropic: JSON-Funktionslisten und Fortschrittsdateien, damit Agenten immer wissen, wo sie sind.

Red Hat: Analysiere die reale Codebasis, bevor du Aufgaben generierst.

ThoughtWorks: „Vorausschauend (Feedforward)."

Verschiedene Worte. Dieselbe Entdeckung.

Dem Agenten den aktuellen Zustand der Welt zu zeigen, ist durchweg besser, als ihm abstrakt zu sagen, was er tun soll.

→ Fundiert in echten Dateipfaden Code, der zur Codebasis passt Ausgehend von einer vagen Beschreibung → halluzinierte Dateipfade und erfundene APIs

Die Lehre: Bevor der Agent irgendetwas tippt, stellen Sie sicher, dass er genau weiß, wo er ist.

13. Prinzip 2: Planung und Ausführung müssen getrennt werden

OpenAI: Menschen gestalten die Umgebung, Agenten führen aus.

Anthropic: Ein eigener Planer-Agent läuft, bevor der Generator auch nur Code anrührt.

ThoughtWorks: Ein obligatorischer menschlicher Prüfpunkt zwischen Planung und Implementierung.

Red Hat: Phase 1 (Auswirkungskarte) und Phase 2 (Implementierung) mit einer harten Trennung dazwischen.

Jedes Lager entdeckte dies unabhängig voneinander:

Einen Agenten im selben Durchgang planen und ausführen zu lassen, produziert unzuverlässige Ergebnisse.

Der Planungsschritt muss nicht von einem Menschen durchgeführt werden.

Aber es muss ein separater Schritt sein, dessen Ergebnis überprüft wird, bevor die Implementierung beginnt.

14. Prinzip 3: Feedbackschleifen sind nicht verhandelbar

OpenAI: Agenten in CI/CD- und Beobachtbarkeitssysteme eingebunden.

Anthropic: Eigener Evaluator-Agent, der Browserautomatisierung nutzt.

ThoughtWorks: Als „Sensoren" formalisiert. Warnte davor, dass rein vorausschauende Ansätze nie bestätigen, ob die Leitplanken tatsächlich funktionieren.

Drei Ansätze für dasselbe Prinzip:

→ OpenAI verwendet automatisierte Tests und CI

→ Anthropic verwendet ein anderes LLM

→ ThoughtWorks sagt, verwende beide, geschichtet

Sie sind sich uneinig, wer das Feedback liefert.

Sie sind sich nicht uneinig, ob man es braucht.

Ein Harness ohne Feedback ist nur ein Prompt mit zusätzlichen Schritten.

15. Prinzip 4: Eine Sache nach der anderen

OpenAI: Zerbricht Ziele in kleinere Bausteine, arbeitet tiefensuche.

Anthropic: Erzwingt eine Funktion pro Sprint mit einem Commit nach jedem.

ThoughtWorks: Abgestufter Lebenszyklus (Vor-Integration → Nach-Integration → kontinuierliche Überwachung).

Agenten, die gleichzeitig zu viel tun wollen:

→ Verlieren den Kontext

→ Verlieren an Kohärenz

→ Lassen Anforderungen stillschweigend fallen

Die Anthropic-Routine:

Fortschritt lesen → EINE Funktion auswählen → Implementieren → Commit → Wiederholen

Erzwungener Inkrementalismus ist universell in jedem erfolgreichen Harness.

16. Prinzip 5: Die Codebasis IST die Dokumentation

OpenAI: Bettet AGENT.md-Dateien im Repository ein.

Anthropic: Speichert Funktionslisten, Fortschrittsdateien und Git-Verlauf als Kontinuitätsmechanismus des Agenten.

ThoughtWorks: Misst die „Harness-Fähigkeit" – wie lesbar die Codebasis für Agenten ist.

Niemand unterhält eine separate Wissensbasis für den Agenten.

Das Repository ist die einzige Quelle der Wahrheit.

Wenn eine Konvention, Einschränkung oder Architekturentscheidung nicht in der Codebasis steht – wird der Agent nichts davon wissen.

Praktische Konsequenz:

→ Teams, die in Code-Organisation investieren, erhalten bessere Agentenleistung kostenlos dazu.

→ Unordentliche Repositorys + KI-Agenten = Chaos, aber im großen Stil.

TEIL 5: DAS PARADOXON — BAUEN, UM ZU LÖSCHEN (Die kontraintuitivste Wahrheit im Harness Engineering)

17. Harness-Verfall ist real

Als Anthropic von Opus 4.5 auf Opus 4.6 upgradete:

Die Sprint-Zerlegung – die zuvor essentiell war – wurde zum Ballast.

Die verbesserte Planungsfähigkeit des Modells machte sie überflüssig.

Eine Harness-Komponente, die im März tragend war, war im April nur noch Overhead.

Dann kam Opus 4.7.

Das Modell begann, seine eigenen Ausgaben zu verifizieren.

Die Stellenbeschreibung des Evaluator-Agenten begann zu schrumpfen.

Das ist Harness-Verfall.

Jede Komponente in einem Harness kodiert eine Annahme darüber, was das Modell nicht kann.

Verbessern sich die Modelle → verfallen diese Annahmen → die Komponente wird zum Overhead.

Opus 4.5: Sprint-Zerlegung + Sprint-für-Sprint-Evaluierung

Opus 4.6: Keine Sprint-Zerlegung + Single-Pass-Evaluierung (spart 38 % Kosten)

Opus 4.7: Modell beginnt mit Selbstverifizierung → Evaluator-Rolle schrumpft weiter

18. Bauen, um zu löschen

Philipp Schmids Rat:

„Baue, um zu löschen."

Gestalte jede Harness-Komponente so, dass sie entfernbar ist.

Teste jede Komponente regelmäßig, indem du sie ausschaltest und misst, ob sich die Ausgabequalität ändert.

Wenn sie sich nicht ändert: Lösche sie.

Manus hat seinen Harness in 6 Monaten 5 Mal umgebaut. LangChain hat ihn in 1 Jahr 3 Mal umstrukturiert. Vercel entfernte 80 % der Werkzeuge → erzielte bessere Leistung.

Das sind keine Zeichen schlechter Ingenieursarbeit.

Sie sind die natürliche Konsequenz des Bauens auf schnell besser werdenden Modellen.

Tote Harness-Komponenten mit sich herumzutragen, kostet bei jedem einzelnen Lauf Tokens. Null zusätzliche Qualität. Reine Verschwendung.

19. Die Kosteneffektivität

Die ehrlichen Zahlen aus Anthropics A/B-Test:

→ Solo-Agent (kein Harness): 9 $, 20 Minuten

→ funktionierende UI, defekte Kernfunktionalität

→ Vollständiger Harness (Opus 4.5): 200 $, 6 Stunden

→ funktionierende Software, polierte UI, korrekte Physik

Das ist eine Kostensteigerung um das 22-fache.

Ob das teuer oder günstig ist, hängt ganz davon ab, was ein fehlerhaftes Release Ihr Team kostet.

Aber hier ist, worüber niemand spricht:

Die Harness + Modell-Kombination entwickelt sich weiter.

Der 200 $-Harness wurde mit einem Modell-Upgrade zu 124 $.

Der Trend:

→ Besseres Modell = einfacherer Harness = günstigerer Lauf = schnellere Ausgabe

Die Ingenieure, die 2026 gewinnen, schreiben nicht den besten Code.

Sie entwerfen die besten Einschränkungen.

Und sind dann bereit, diese Einschränkungen wegzuwerfen, sobald sie ihren Wert nicht mehr verdienen.

ABSCHLUSS

Alles, was Sie gerade gelernt haben:

Was ein Harness ist:

→ 1. Agent = Modell + Harness

→ 2. Modell = CPU. Harness = Betriebssystem.

→ 3. Gleiches Modell, besserer Harness = +13 % Leistung

Die 5 Harness-Artefakte:

→ 4. CLAUDE.md / AGENT.md – Einführungsdokumente für Agenten

→ 5. JSON-Funktionslisten – Fortschritts-Tracker und Testsuite in einem

→ 6. Sitzungsinitialisierungsroutinen – jedes Mal der gleiche 7-stufige Start

→ 7. Sprint-Verträge – Agenten verhandeln vor dem Codieren

→ 8. Strukturierte Aufgabenbausteine – echte Dateipfade, echte Muster

Die drei Lager:

→ 9. OpenAI: Gestalte die Umgebung, lass den Agenten los

→ 10. Anthropic: Trenne den Macher vom Richter

→ 11. ThoughtWorks: 2×2 Vorausschau-/Rückblick-Framework

Die 5 universellen Prinzipien:

→ 12. Kontext schlägt Anweisungen

→ 13. Planung und Ausführung müssen getrennt werden

→ 14. Feedbackschleifen sind nicht verhandelbar

→ 15. Eine Sache nach der anderen

→ 16. Die Codebasis ist die Dokumentation

Das Paradoxon:

→ 17. Harness-Verfall – was letzten Monat funktioniert hat, schadet diesen Monat

→ 18. Bauen, um zu löschen – tote Komponenten testen und entfernen

→ 19. Die Kosteneffektivität – besseres Modell = einfacherer Harness = günstigerer Lauf

Die Ingenieure, die 2026 gewinnen, schreiben nicht den besten Code.

Sie entwerfen die besten Einschränkungen.

Und sind bereit, diese Einschränkungen wegzuwerfen, sobald sie ihren Wert nicht mehr verdienen.

Falls das nützlich war:

→ Teilen Sie den Beitrag, um Entwickler in Ihrem Netzwerk zu erreichen

→ Folgen Sie @sairahul1 für mehr davon jede Woche

→ Merken Sie sich das – Sie werden es nachschlagen, wenn Ihre Agenten anfangen, sich schlecht zu benehmen

Ich schreibe über KI, Produktentwicklung und was 2026 wirklich funktioniert.