Warum GPT vs. Claude die falsche Frage ist: Entscheidend ist der Agent-Harness

TL;DR: Nicht GPT gegen Claude entscheidet über gute Coding-Agenten, sondern der Agent-Harness – die Laufzeitumgebung aus Tools, File-Editing, Logs, Retry-Logik, Rollback, Evals und Modell-Routing. GitHubs Copilot-Benchmark zeigt bei gleichem Modell deutlich weniger Tokenverbrauch je nach Harness. Armin Ronachers Analyse dokumentiert den Gegenbeweis zur „stärkeres Modell gewinnt"-Logik: Claude Opus 4.8 und Sonnet 5 scheitern in einem fremden Tool-Schema in bis zu 20 Prozent der Fälle. Die entscheidende Frage 2026 lautet nicht „welches Modell?", sondern „welcher Harness?".

Was ist ein Agent-Harness?

Ein Agent-Harness ist die Laufzeitumgebung rund um ein Sprachmodell. Ohne Harness ist ein Modell nur ein Textgenerator. Erst der Harness verbindet das Modell mit Tools, Speicher, Dateisystem, Shell, Logs, Berechtigungen und Kontrolllogik, damit es als Agent selbstständig Dateien ändern, Tests ausführen und Fehler reparieren kann. Der Harness entscheidet über die Dinge, die im Chatfenster gar nicht sichtbar sind: welche Tools der Agent bekommt, wie Edits ausgeführt werden, was bei fehlgeschlagenen Tool-Calls passiert, ob ein Lauf abgebrochen oder zurückgerollt werden kann, welches Modell auf welche Aufgabe geroutet wird. Eine ausführliche Definition der Bausteine liefert der Guide Was ist ein AI Harness?.

Modell vs. Laufzeitumgebung

Der Unterschied lässt sich auf einen Merksatz verdichten: Das Modell denkt. Der Harness handelt. Klassische Modellvergleiche schauen auf Benchmarks, Reasoning und Output-Qualität. Coding-Agenten müssen aber Dateien ändern, Tests ausführen, Fehlermeldungen interpretieren und Rollbacks beherrschen. Diese Fähigkeiten liegen nur zum Teil im Modell. Der Rest ist Engineering am Harness.

Warum der Begriff gerade jetzt wichtig wird

Claude Code, Codex CLI und GitHub Copilot sind keine Chatfenster mit angehängtem Modell. Es sind Agent-Laufzeitumgebungen mit CLI-, IDE- oder App-Oberflächen, Tool-Zugriff, Dateioperationen, Berechtigungen, Modellwahl und Automatisierung. Je nach Produkt kommen MCP, Hooks, Sub-Agents, Skills oder SDKs hinzu. Genau das erklärt, warum sich Claude Code anders anfühlt als ein reiner API-Call auf dasselbe Claude-Modell. Der Wettbewerb verschiebt sich von „OpenAI vs. Anthropic" zu „welcher Harness orchestriert welche Modelle am zuverlässigsten?".

Warum greift GPT vs. Claude zu kurz?

Die Frage „GPT oder Claude?" unterstellt, dass die Modellintelligenz das Ergebnis bestimmt. Bei Coding-Agenten stimmt das nur bedingt. Die Argumentationslinie ist kurz: - Ein Modell liefert Rohintelligenz, gemessen an Reasoning und Code-Qualität. - Ein Coding-Agent muss diese Intelligenz in echte Dateiänderungen, Shell-Kommandos, Git-Operationen und Fehlerbehandlung übersetzen. - Diese Übersetzung passiert im Harness, nicht im Modell. - Zwei Agenten mit demselben Modell können damit unterschiedlich zuverlässig und unterschiedlich teuer arbeiten. Das ist keine Theorie. GitHub liefert dafür kontrollierte Zahlen, und Ronachers Analyse liefert den passenden Gegenbeweis zur naiven „stärkeres Modell gewinnt"-Annahme.

Woraus besteht ein guter Coding-Agent-Harness?

Ein produktiver Harness ist mehr als ein Tool-Aufruf im Loop. Diese sieben Bausteine entscheiden über Zuverlässigkeit: | Baustein | Warum er zählt | Beispiel | |---|---|---| | Tool-Schema | Bestimmt, ob das Modell Tools zuverlässig aufruft | Flaches Claude-Code-Schema vs. Pis verschachtelte Edits | | File Editing | Fehlerhafte Edits können Codebasen direkt beschädigen | HIC Mouse mit koordinatenbasiertem Editing und Rollback | | Retry / Repair | Repariert fehlerhafte Tool-Calls, kann Fehler aber verstecken | Ronachers rekonstruierte Claude-Code-Slop-Reparatur | | Logs / Replay | Macht Läufe auditierbar und reproduzierbar | „The Log is the Agent" | | Evals | Misst, ob Agenten Aufgaben wirklich lösen | GitHub-Benchmarks, AgentX | | Routing | Wählt Modell nach Task, Kosten oder Qualität | Copilot Auto Model Selection | | Orchestrierung | Verteilt Aufgaben auf Sub-Agenten oder andere Modelle | Claude Code Sub-Agents, Cross-Harness-Delegation | Jeder dieser Bausteine ist ein eigenes Produktproblem. Und jeder kann einen an sich starken Agenten unzuverlässig machen, wenn er schlecht umgesetzt ist.

Was beweist GitHubs Copilot-Benchmark?

Der stärkste Beleg für die These kommt ausgerechnet von einem Hersteller. Im Copilot-Harness-Benchmark hat GitHub den eigenen Agentic Harness gegen die nativen Umgebungen der Modellanbieter getestet und dabei so viele Variablen wie möglich konstant gehalten: gleiches Modell, gleiche Aufgabe, normalisiertes Kontextfenster, gleicher Reasoning Effort sowie vergleichbare Tool- und MCP-Konfigurationen. In den allgemeinen Benchmark-Läufen waren Web-Tools und MCP-Server deaktiviert; TerminalBench 2.0 wurde zusätzlich mit Default-Settings analysiert. Verglichen wurde die Copilot CLI gegen Claude Code (mit Sonnet 4.6 und Opus 4.7) und die Codex CLI (mit GPT-5.4 und GPT-5.5). Die Messung lief über etablierte Benchmarks: SWE-bench Verified, SWE-bench Pro, SkillsBench, TerminalBench und Win-Hill. Das Ergebnis laut GitHub: eine vergleichbare Task-Resolution-Rate, aber über die meisten Konfigurationen hinweg oft ein geringerer Tokenverbrauch. Anders gesagt: derselbe Modellkern, anderer Harness, andere Effizienz. Genau das ist der Punkt. Ein zweiter Befund passt dazu: Der Copilot-Harness unterstützt über 20 Frontier-Modelle aus den GPT-, Claude-, Gemini- und MAI-Familien plus automatische Modellwahl. Harness-Qualität wird damit messbar und vermarktbar. Wichtig: Das bleibt Herstellerkommunikation. Der Benchmark ist ein starkes Signal für den Trend, aber kein unabhängiger Beweis, dass Copilot generell besser ist. Mehr dazu im Abschnitt zu den Grenzen.

Warum machen bessere Modelle manchmal schlechtere Agenten?

Den überzeugendsten Gegenbeweis zur „stärkeres Modell gewinnt"-Logik liefert Armin Ronacher in seiner Analyse „Better Models: Worse Tools". Er hat neuere Anthropic-Modelle im minimalistischen Coding-Agenten Pi getestet, der Datei-Edits über ein verschachteltes JSON-Schema (edits[]) abbildet. Das Ergebnis ist paradox: Claude Opus 4.8 und Sonnet 5 scheitern bei diesen verschachtelten Tool-Aufrufen in bestimmten Sessions in bis zu 20 Prozent der Fälle. Der Clou dabei: Die eigentlichen oldText- und newText-Nutzdaten waren byte-genau korrekt. Das Modell hatte die richtige Änderung produziert und dann am Ende des Objekts halluzinierte Parameter angehängt, etwa type, id, infile, oldText2 oder requireUnique.

Die Ursache: ein zu nachsichtiger Harness

Ronachers Verdacht: Anthropics eigener Claude-Code-Harness nutzt ein sehr flaches Edit-Schema, näher an filepath, oldstring, newstring und einem optionalen replaceall-Flag. Der Client dahinter ist auffällig fehlerverzeihend. Er enthält Retry-Pfade für fehlerhafte Tool-Calls, Parameter-Aliase, Typ-Coercion, Unicode-Reparaturen und filtert unbekannte Keys still heraus. Ronacher nennt das den „Slop Harness". Wird ein Modell im Post-Training überwiegend in einer solchen Umgebung trainiert, lernt es, dass leicht fehlerhafte Tool-Calls trotzdem belohnt werden. In einem fremden, strengeren Schema fällt genau diese Nachlässigkeit dann auf. Die technische Lösung ist bekannt: „Strict Tool Invocation" per grammatikgesteuertem Decoding eliminierte die Fehler in Ronachers Tests vollständig, also auf null Prozent. Aber auch das ist kein Freifahrtschein. Entwickler weisen darauf hin, dass starkes Grammar-Constraining beim Sampling die allgemeine Denk- und Output-Qualität eines Modells beeinträchtigen kann. Die Kernaussage bleibt: Ein Modell kann intelligenter werden und trotzdem in deinem Harness schlechter funktionieren.

Warum entscheiden File-Editing, Logs und Evals über die Produktion?

Drei weitere Bausteine zeigen, wie sehr sich der Harness zur eigenen Produktkategorie entwickelt.

File-Editing ist kein Detail

Viele Agenten ändern Code über simples String Replacement: fragil, ohne saubere Vorschau, ohne verlässliches Rollback. Das Tool HIC Mouse positioniert sich genau gegen diese Schwäche. Es setzt auf koordinatenbasiertes Editing mit deklarativen Operationen wie INSERT, DELETE und ADJUST, auf „Staged Changes with Atomic Rollback" (Änderungen werden erst als Vorschau bereitgestellt und lassen sich atomar zurückrollen) sowie auf „Embedded Guidance", also kontextuelle Hinweise und Risikobewertungen direkt in den Tool-Antworten. Fehlerhafte Edits sind einer der direktesten Wege, auf dem ein Agent eine Codebasis beschädigen kann. Für Coding-Agenten ist präzises File-Editing deshalb so grundlegend wie Autocomplete früher für die IDE.

Logs und Replay werden zur Produktionsanforderung

Ohne Logs ist kaum nachvollziehbar, warum ein Agent eine bestimmte Änderung gemacht hat. Das Paper „The Log is the Agent" schlägt vor, nicht den LLM-Loop, sondern einen append-only Event-Log zur primären Wahrheitsquelle zu machen. Der Arbeitsgraph ist dann eine deterministische Projektion dieses Logs. Der Nutzen: deterministische Replays, günstiges Forking von Läufen an jedem beliebigen Event und eine lückenlose Rückverfolgbarkeit von der High-Level-Aufgabe bis zum einzelnen Modellaufruf. Wer die Auditierbarkeit von KI-Code ernst nimmt, kennt das Problem aus der Praxis: Genau darum geht es auch bei Dark Code.

Evals werden zur Pflicht

Wer Agenten ernsthaft einsetzt, braucht messbare Läufe statt Bauchgefühl. Dass daraus eine eigene Produktkategorie wird, zeigt AgentX: Das Framework verspricht, „Multi-Agenten mit jedem LLM zu bauen und evaluieren", Probleme punktgenau zu lokalisieren und mit einem Klick zu beheben. Beim ProductHunt-Launch am 22. Juni 2026 erreichte es Platz 1 des Tages und Platz 4 der Woche. Die Positionierung liegt bewusst auf Evaluation, Observability und Zuverlässigkeit vor dem Deployment.

Wie bewertest du einen Coding-Agenten?

Statt „GPT oder Claude?" solltest du den Harness prüfen. Diese Checkliste hilft bei der Bewertung, egal ob du Claude Code, Codex CLI, Copilot oder einen lokalen Agenten einsetzt: | Frage | Warum sie wichtig ist | |---|---| | Kann ich sehen, welche Dateien geändert werden, bevor gespeichert wird? | Verhindert stille Schäden | | Gibt es Rollback oder nur Git als Notbremse? | Rollback muss workflow-nah sein | | Sind Tool-Calls strikt validiert? | Reduziert Schema-Slop | | Werden unbekannte Tool-Parameter sichtbar oder still gefiltert? | Stille Reparatur kann Fehler verdecken | | Gibt es Logs, Replay oder eine saubere Run-Historie? | Nötig für Debugging und Audit | | Kann ich Modelle gezielt routen oder wechseln? | Kosten und Qualität hängen vom Task ab | | Gibt es Evals oder nur subjektives Gefühl? | Ohne Evals keine belastbare Verbesserung | | Arbeitet der Agent mit MCP, Tickets, CI und Review-Tools? | Produktivität entsteht durch Integration | Wer ohne feste Regeln arbeitet, verschiebt das Problem nur. Ein disziplinierter Workflow wie Spec-Driven Development mit Claude Code gibt dem Harness erst die Leitplanken, in denen er zuverlässig bleibt.

Welche Grenzen hat der Harness-Vergleich?

So klar das Signal ist, so wichtig sind die Einschränkungen. Vier Punkte gehören zu einer ehrlichen Einordnung: - Hersteller-Bias: GitHubs Copilot-Benchmark ist trotz kontrollierter Bedingungen Herstellerkommunikation. Er deutet einen Trend an, ist aber kein unabhängiger Beweis. - Run-to-run-Varianz: Agenten sind stochastisch. GitHub zeigt selbst die Streuung (±1σ) zwischen mehreren Läufen auf TerminalBench 2.0. Ein einzelner lokaler Test sagt wenig aus, du brauchst mehrere Läufe bei gleichem Modell, Kontext und gleichen Tool-Freigaben. - Stille Reparatur: Ein Harness, der Modellfehler automatisch korrigiert, fühlt sich stabiler an, verschleiert aber Halluzinationen und erschwert das Debugging tiefer Fehler. Dieses Risiko verstärkt die Cognitive Debt, die durch KI-Coding ohnehin entsteht. - Evals sind kein Freibrief: Automatisierte Evaluationen messen nur bekannte Testfälle. In Produktion scheitern Agenten oft an Kontext, Berechtigungen, Datenzustand oder unerwarteten Tool-Seiteneffekten. Und ganz grundsätzlich: Mehr Harness-Automatik bedeutet nicht automatisch mehr Kontrolle. Auto-Routing und Fallbacks können Reproduzierbarkeit kosten, wenn morgen ein anderes Modell denselben Prompt bearbeitet.

FAQ: Häufig gestellte Fragen zum Agent-Harness

Was ist ein Agent-Harness? Ein Agent-Harness ist die Laufzeitumgebung, die ein Sprachmodell mit Tools, Kontext, Speicher, Logs, Berechtigungen und Kontrolllogik verbindet. Ohne Harness ist ein Modell nur ein Textgenerator. Mit Harness kann es Dateien ändern, Tests ausführen und Aufgaben abschließen. Ist Claude Code ein Modell oder ein Harness? Claude Code nutzt Claude-Modelle, ist aber selbst ein Harness. Es bringt CLI, Editor-Integration, MCP, Skills, Hooks, Sub-Agents, Sessions und Automatisierung mit. Das gilt in ähnlicher Weise für die Codex CLI, die als terminal-nativer Harness Tool-Zugriff, Repo-Kontext, MCP, Hooks und Subagents für GPT-Modelle steuert. Warum reicht ein besseres Modell nicht? Weil Coding-Agenten nicht nur Antworten schreiben. Sie müssen korrekt mit Dateien, Shell, Git, Tests, APIs und Fehlern umgehen. Diese Fähigkeiten hängen stark vom Harness ab. Ein stärkeres Modell kann in einem fremden Tool-Schema sogar schlechter arbeiten, wie Ronachers Analyse zu Opus 4.8 und Sonnet 5 zeigt. Warum sind Logs und Replay wichtig? Ohne Logs ist schwer nachvollziehbar, warum ein Agent eine Änderung gemacht hat. Replay und Forking erlauben, Läufe zu debuggen, Alternativen zu testen und Fehlerquellen sichtbar zu machen. Für Produktion, Compliance und Audit ist das oft wichtiger als ein Prozentpunkt mehr Benchmark-Score. Sollte ich automatisch das beste Modell routen lassen? Für reine Produktivität kann Auto-Routing sinnvoll sein. Für Debugging, Compliance und Reproduzierbarkeit ist es riskant, wenn nicht klar dokumentiert ist, welches Modell wann genutzt wurde. Ein gleicher Prompt kann sonst morgen auf einem anderen Modell laufen. Was bedeutet „Strict Tool Invocation"? Strict Tool Invocation erzwingt per grammatikgesteuertem Decoding, dass das Modell nur Tool-Argumente erzeugt, die exakt zum Schema passen. Das eliminiert Schema-Fehler, kann aber laut Entwicklern die allgemeine Antwortqualität beeinträchtigen und die Komplexität der Tool-Definitionen begrenzen.

Fazit

Die nächste Phase bei Coding-Agenten wird nicht allein durch stärkere Modelle entschieden, sondern durch bessere Harnesses: präzisere Tools, strengere Tool-Schemas, sauberere Logs, reproduzierbare Evals, verlässliches Rollback und durchdachtes Modell-Routing. Wer 2026 einen Coding-Agenten bewertet, sollte deshalb nicht fragen, ob GPT oder Claude besser ist. Die wichtigere Frage lautet: Welcher Harness macht aus dem Modell zuverlässig produktive Arbeit? Den konzeptionellen Unterbau liefert der Guide Was ist ein AI Harness?. Wie sich das Tool-Schema konkret auswirkt, zeigt der Pi Coding-Agent. Warum Struktur den Unterschied macht, erklärt Spec-Driven Development mit Claude Code, und die Schattenseite unverstandener KI-Ausgaben beleuchtet Dark Code. Verifizierte Quellen: GitHub Blog – Evaluating Performance and Efficiency of the GitHub Copilot Agentic Harness; Armin Ronacher – „Better Models: Worse Tools" (lucumr.pocoo.org, 04.07.2026); arXiv:2605.21997 – „The Log is the Agent"; HIC Mouse Produktdokumentation; AgentX (ProductHunt-Launch, 22.06.2026); Anthropic Claude Code Docs.