Wie die Systemumgebung die Leistung von Coding Agenten beeinflusst

Warum die Systemumgebung von Coding-Agenten stärker in den Fokus rückt

Autonome Coding-Agenten werden zunehmend eingesetzt, um Softwarefehler zu analysieren, Änderungen an Codebasen vorzubereiten, Tests auszuführen und Pull Requests zu erstellen. In der öffentlichen Wahrnehmung steht dabei häufig das zugrunde liegende Sprachmodell im Mittelpunkt. Ob ein Agent zuverlässig arbeitet, hängt jedoch nicht allein von dessen Modellfähigkeiten ab. Eine ebenso wichtige Rolle spielt die technische Umgebung, in der das Modell Aufgaben bearbeitet.

Diese Umgebung wird häufig als Harness bezeichnet. Gemeint ist eine Steuerungs- und Ausführungsschicht, die das Modell mit Werkzeugen, Arbeitsabläufen, Kontext, Zwischenzielen und Regeln für die Interaktion mit einer Codebasis verbindet. Sie entscheidet unter anderem, welche Informationen das Modell sieht, welche Aktionen es ausführen darf, wann es einen Plan erstellt und wie es mit einer langen Folge von Terminalbefehlen, Testergebnissen und Fehlermeldungen umgeht.

Eine neue empirische Untersuchung mit dem Titel „An Empirical Study of Harness Design for Coding Agents“ untersucht diese Komponenten isoliert. Die Forschenden variierten Planung, Aktionsraum und Kontextmanagement innerhalb eines möglichst einheitlichen Ausführungsrahmens. Auf diese Weise sollte sichtbar werden, welche Bestandteile die Leistung autonomer Coding-Agenten tatsächlich beeinflussen und unter welchen Bedingungen einzelne Designentscheidungen besonders relevant sind.

Der Ansatz ist für die Praxis bedeutsam, weil viele frühere Vergleiche komplette Agentensysteme als unteilbare Einheiten betrachteten. Wenn ein System besser abschneidet als ein anderes, bleibt bei einer solchen Betrachtung offen, ob der Vorteil aus dem Modell, aus besseren Werkzeugen, aus einer effizienteren Kontextverwaltung oder aus einer ausgefeilteren Planung stammt. Die neue Untersuchung versucht, diese Ebenen systematischer voneinander zu trennen.

Was ein Coding-Agent-Harness konkret leistet

Vom Sprachmodell zum handelnden Softwaresystem

Ein Sprachmodell erzeugt zunächst Text beziehungsweise strukturierte Ausgaben. Ein Coding-Agent benötigt dagegen eine Umgebung, in der diese Ausgaben in Aktionen übersetzt werden können. Dazu zählen beispielsweise das Lesen von Dateien, die Suche nach Symbolen, das Ausführen von Tests, das Ändern von Quellcode oder die Analyse von Fehlermeldungen.

Der Harness bildet die Verbindung zwischen der Modellantwort und der tatsächlichen Softwareumgebung. Er kann prüfen, ob eine Aktion zulässig ist, die Ausgabe eines Werkzeugs zurückführen und den nächsten Arbeitsschritt anstoßen. Im einfachsten Fall besteht dieser Ablauf aus einer wiederholten Schleife:

• Das Modell erhält eine Aufgabenbeschreibung und relevanten Kontext.
• Es entscheidet sich für eine Antwort oder eine Werkzeugaktion.
• Der Harness führt die Aktion aus und sammelt das Ergebnis.
• Die neue Information wird dem Modell zur weiteren Bearbeitung bereitgestellt.
• Der Prozess wird fortgesetzt, bis die Aufgabe abgeschlossen ist oder ein Abbruchkriterium erreicht wird.

Bei kurzen Aufgaben kann eine solche Schleife ausreichen. Bei anspruchsvolleren Softwareprojekten entstehen jedoch schnell lange Interaktionsketten. Jede zusätzliche Aktion kann neue Dateien, Logs, Testergebnisse und Fehlermeldungen in den Kontext einbringen. Dadurch wächst die Gefahr, dass wichtige Informationen übersehen werden, frühere Entscheidungen in Vergessenheit geraten oder das ursprüngliche Ziel aus dem Blick gerät.

Die drei untersuchten Stellschrauben

Die Studie konzentriert sich auf drei zentrale Bestandteile des Harness-Designs:

• Planung: Der Agent formuliert vor oder während der Bearbeitung eine Strategie, zerlegt die Aufgabe in Teilziele und aktualisiert diese gegebenenfalls.
• Aktionsraum: Der Agent erhält eine bestimmte Auswahl an Werkzeugen und möglichen Interaktionen. Dazu können etwa Dateisuche, Codebearbeitung, Terminalzugriff oder Testausführung gehören.
• Kontextmanagement: Der Harness entscheidet, welche Informationen im aktuellen Kontext verbleiben, welche verdichtet oder entfernt werden und wie Zwischenstände über längere Aufgaben hinweg erhalten bleiben.

Die Beschränkung auf diese Komponenten ermöglicht eine gezieltere Analyse. Zugleich ist zu berücksichtigen, dass ein produktives Agentensystem weitere Faktoren umfasst. Dazu gehören die Qualität der Aufgabenbeschreibung, Sicherheitsmechanismen, Berechtigungen, die technische Integration in Entwicklungsumgebungen, die verwendeten Modelle und die Ausgestaltung der Evaluierung.

Versuchsaufbau: 176 vergleichbare Konfigurationen

Nach den vorliegenden Angaben wurden 176 aufeinander abgestimmte Einstellungen untersucht. Die Auswertung umfasste vier Modelle, fünf Strategien für das Kontextmanagement und vier unterschiedliche Kontextfenster-Budgets. Ergänzend wurden gezielte Ablationen für Planung und Aktionsraum durchgeführt. Bei einer Ablation wird ein Bestandteil gezielt verändert, reduziert oder entfernt, um seinen Beitrag zur Gesamtleistung sichtbar zu machen.

Die Tests erfolgten auf SWE-Bench Verified und Terminal-Bench 2.1. Beide Benchmarks prüfen unterschiedliche Aspekte agentischer Softwarearbeit. SWE-Bench Verified konzentriert sich auf reale Softwareentwicklungsaufgaben, bei denen ein Agent Änderungen an bestehenden Projekten vornehmen und die Korrektheit seiner Lösung nachweisen muss. Terminal-Bench bewertet stärker die Fähigkeit, Aufgaben über eine Kommandozeilenumgebung und eine Abfolge von Werkzeuginteraktionen zu bearbeiten.

Die Wahl mehrerer Modelle und Benchmarks ist für die Aussagekraft wichtig. Ein Harness, das mit einem bestimmten Modell gut funktioniert, muss nicht automatisch für ein anderes Modell geeignet sein. Ebenso kann eine Strategie bei Aufgaben mit klaren Tests anders wirken als bei Aufgaben, die eine längere Untersuchung einer unbekannten Codebasis erfordern.

Der Untersuchungsansatz zielt daher nicht auf eine einzelne Rangliste der besten Agenten. Im Mittelpunkt steht vielmehr die Frage, wie sich bestimmte technische Entscheidungen unter unterschiedlichen Bedingungen auswirken. Das ist ein wesentlicher Unterschied zu Produktvergleichen, bei denen häufig nur die Endleistung eines vollständigen Systems betrachtet wird.

Kontextmanagement als entscheidender Faktor bei knappen Budgets

Warum mehr Kontext nicht automatisch besser ist

Ein Kontextfenster kann als begrenzte Arbeitsfläche eines Sprachmodells verstanden werden. Es enthält Systemanweisungen, Aufgabenbeschreibung, Werkzeugdefinitionen, relevante Dateien, frühere Aktionen, Testergebnisse und gegebenenfalls Zusammenfassungen. Mit jeder Interaktion steigt die Menge der potenziell verfügbaren Informationen.

Eine größere Informationsmenge führt jedoch nicht zwangsläufig zu besseren Entscheidungen. Wenn der Kontext mit irrelevanten oder veralteten Details gefüllt ist, kann die Aufmerksamkeit des Modells auf die falschen Inhalte gelenkt werden. Wichtige Hinweise gehen dann nicht unbedingt verloren, weil sie technisch entfernt wurden, sondern weil sie in einer langen Folge weniger relevanter Informationen untergehen.

Dieses Problem wird bei lang laufenden Aufgaben besonders deutlich. Ein Agent kann zu Beginn eine korrekte Hypothese bilden, später jedoch durch widersprüchliche Testergebnisse, umfangreiche Terminalausgaben oder wiederholte Suchvorgänge den Überblick verlieren. Ohne geeignete Zustandsverwaltung muss das Modell seine eigene Historie immer wieder neu interpretieren.

Kontextmanagement bei begrenzten Ressourcen

Die Untersuchung kommt zu dem Ergebnis, dass Kontextmanagement insbesondere bei kleineren Kontextbudgets an Bedeutung gewinnt. Das lässt sich technisch nachvollziehen: Je knapper der verfügbare Platz ist, desto stärker muss der Harness priorisieren, welche Informationen erhalten bleiben. Ohne Verdichtung, Auswahl und Aktualisierung kann der Agent wichtige Hinweise frühzeitig verdrängen.

Zu den typischen Verfahren des Kontextmanagements gehören:

• Das Zusammenfassen älterer Interaktionen, sobald der Kontext eine bestimmte Größe erreicht.
• Das Herausfiltern redundanter Terminalausgaben oder bereits gelöster Zwischenschritte.
• Das dauerhafte Speichern wichtiger Ziele, Annahmen, offenen Fragen und Testergebnisse außerhalb des unmittelbaren Dialogverlaufs.
• Die gezielte erneute Abfrage relevanter Dateien, anstatt die gesamte bisherige Historie dauerhaft mitzuschleppen.
• Die Trennung zwischen aktuellem Arbeitskontext, langfristigem Aufgabenstatus und unveränderlichen Systemanweisungen.
• Die Reservierung eines Puffers, damit das Modell auch am Ende einer langen Interaktion noch handlungsfähig bleibt.

Ein solches Vorgehen wird häufig unter dem Begriff Context Engineering zusammengefasst. Im Kern geht es nicht lediglich darum, möglichst viele Informationen in ein Modell zu laden. Entscheidend ist, zur richtigen Zeit die richtigen Informationen in einer geeigneten Form bereitzustellen.

Zusammenfassen mit Risiken

Kontextkomprimierung ist allerdings nicht risikofrei. Eine Zusammenfassung kann wichtige Details auslassen, Unsicherheiten glätten oder eine frühere Fehlannahme als Tatsache darstellen. Wird ein solcher verdichteter Zustand später als Grundlage für weitere Entscheidungen verwendet, kann sich ein kleiner Informationsverlust über mehrere Schritte hinweg auswirken.

Für produktive Systeme sind deshalb nachvollziehbare Zustandsformate erforderlich. Ein Agent sollte nicht nur eine freie Zusammenfassung erzeugen, sondern möglichst strukturiert festhalten:

• Welches Ziel verfolgt wird.
• Welche Dateien oder Module bereits untersucht wurden.
• Welche Hypothesen bestätigt oder widerlegt sind.
• Welche Tests erfolgreich oder fehlgeschlagen sind.
• Welche Änderungen vorgenommen wurden.
• Welche Fragen noch offen sind.
• Welche Informationen mit hoher Sicherheit gelten und welche nur vorläufige Annahmen darstellen.

Diese Struktur erleichtert die Überprüfung durch Menschen und kann verhindern, dass der Agent bei einer späteren Kontextkürzung den gesamten Arbeitsstand neu rekonstruieren muss.

Planung verändert ihren Nutzen mit steigender Modellleistung

Planen, handeln und erneut planen

Planung gilt als ein zentrales Element agentischer Systeme. Ein Agent kann eine komplexe Aufgabe in Teilprobleme zerlegen, eine Reihenfolge festlegen und nach jedem Arbeitsschritt prüfen, ob sich die ursprüngliche Strategie bewährt. Bei Softwareaufgaben kann dies beispielsweise bedeuten, zunächst die betroffenen Module zu identifizieren, anschließend die bestehende Logik zu analysieren, danach eine Änderung vorzunehmen und abschließend gezielte Tests auszuführen.

Ein starrer Plan kann jedoch problematisch sein. Softwareumgebungen enthalten häufig unvollständige Dokumentation, unerwartete Abhängigkeiten oder Tests, die andere Fehler offenlegen als zunächst angenommen. Ein Agent muss daher nicht nur planen, sondern auch in der Lage sein, seine Strategie zu korrigieren.

Die Untersuchung deutet darauf hin, dass die Funktion der Planung nicht für alle Modelle gleich bleibt. Bei weniger leistungsfähigen Modellen kann explizite Planung helfen, die Aufgabe zu strukturieren und dadurch die Genauigkeit zu erhöhen. Bei leistungsfähigeren Modellen verschiebt sich der Vorteil offenbar stärker in Richtung Effizienz: Planung kann helfen, unnötige Aktionen zu vermeiden und verfügbare Rechenzeit gezielter einzusetzen.

Warum mehr Planung auch schaden kann

Jeder zusätzliche Planungsschritt verursacht Kosten. Das Modell benötigt weitere Tokens, und die Ausführung der Aufgabe kann sich verlängern. Bei einfachen oder gut abgegrenzten Aufgaben kann eine ausführliche Vorplanung mehr Aufwand erzeugen, als sie an Fehlern verhindert.

Außerdem kann ein Agent an einem Plan festhalten, der durch neue Informationen bereits überholt ist. Eine lange, vorab erzeugte Strategie vermittelt dann zwar den Eindruck von Systematik, führt aber nicht zwingend zu besseren Ergebnissen. Für dynamische Aufgaben ist eine abgestufte Planung häufig geeigneter als ein vollständig festgelegter Ablauf.

In der Praxis lassen sich verschiedene Planungsmodi unterscheiden:

• Keine explizite Planung: Der Agent reagiert unmittelbar auf die aktuelle Situation. Dieser Modus kann bei kurzen, klaren Aufgaben effizient sein.
• Planung vor dem ersten Schritt: Der Agent erstellt zunächst eine Gesamtstrategie und arbeitet sie anschließend ab.
• Schrittweise Planung: Vor jeder Aktion wird der nächste Schritt bestimmt. Das erlaubt eine enge Anpassung an neue Informationen, kann aber hohe Kosten verursachen.
• Hierarchische Planung: Ein übergeordnetes Ziel wird in Teilziele zerlegt, die jeweils separat bearbeitet und bewertet werden.
• Adaptive Planung: Der Agent plant nur dann ausführlicher, wenn Unsicherheit, Komplexität oder ein Fehlerereignis dies erforderlich machen.

Die zentrale Frage lautet damit nicht, ob ein Agent planen sollte. Entscheidend ist, wann, wie ausführlich und mit welcher Möglichkeit zur Korrektur er planen sollte.

Der Aktionsraum: Zwischen Flexibilität und Kontrolle

Werkzeuge als Erweiterung des Modells

Der Aktionsraum beschreibt die Werkzeuge und Handlungsmöglichkeiten, die einem Coding-Agenten zur Verfügung stehen. Ein breiter Aktionsraum kann die Problemlösung erleichtern, weil der Agent Dateien suchen, Inhalte analysieren, Tests ausführen und Änderungen direkt vornehmen kann. Er eröffnet jedoch auch mehr Möglichkeiten für Fehlentscheidungen.

Ein Agent mit uneingeschränktem Terminalzugriff kann theoretisch sehr flexibel arbeiten. Gleichzeitig steigt das Risiko, dass er unnötige Befehle ausführt, große Datenmengen in den Kontext lädt oder Änderungen vornimmt, die nicht ausreichend geprüft wurden. Ein stärker begrenzter Aktionsraum kann dagegen die Entscheidungsfindung vereinfachen und Sicherheitsrisiken reduzieren.

Die Gestaltung des Aktionsraums betrifft daher mehrere Ziele gleichzeitig:

• Erreichbarkeit der für die Aufgabe notwendigen Informationen.
• Reduzierung unnötiger oder redundanter Werkzeugaufrufe.
• Nachvollziehbarkeit der durchgeführten Aktionen.
• Begrenzung potenziell schädlicher Eingriffe.
• Kompatibilität mit den Fähigkeiten des verwendeten Modells.
• Effiziente Rückgabe von Ergebnissen an den Agenten.

Mehr Werkzeuge sind nicht automatisch besser

Ein häufiges Missverständnis besteht darin, den Funktionsumfang eines Agenten primär über die Zahl seiner Werkzeuge zu bewerten. Ein umfangreicher Aktionsraum kann zu längeren Entscheidungsprozessen führen. Wenn mehrere Werkzeuge ähnliche Aufgaben erfüllen, muss das Modell zunächst zwischen ihnen auswählen. Uneinheitliche Schnittstellen oder schwer verständliche Parameter erhöhen zusätzlich die Wahrscheinlichkeit fehlerhafter Aufrufe.

Für Unternehmen ist deshalb eine aufgabenbezogene Werkzeugauswahl relevant. Ein Agent für Code-Review benötigt andere Funktionen als ein Agent für die Fehlersuche in einer Produktionsumgebung. Werkzeuge sollten möglichst klar beschrieben, in ihrer Wirkung begrenzt und mit maschinenlesbaren Rückgabewerten ausgestattet sein.

Besonders wichtig ist die Qualität der Werkzeugausgaben. Lange, unstrukturierte Logs können den Kontext schneller füllen als kompakte Statusinformationen. Ein Harness sollte daher, soweit möglich, relevante Ergebnisse extrahieren und den Agenten auf Fehler, Änderungen und Entscheidungspunkte hinweisen.

Was die Ergebnisse für die Bewertung von Coding-Agenten bedeuten

Modellqualität und Systemqualität getrennt betrachten

Die Studie unterstützt eine Sichtweise, nach der die Leistung eines Coding-Agenten aus mehreren Schichten entsteht. Das Sprachmodell stellt allgemeine Fähigkeiten für Verständnis, Schlussfolgerung und Codegenerierung bereit. Der Harness bestimmt jedoch, wie diese Fähigkeiten in einer längeren Aufgabenfolge genutzt werden.

Ein leistungsfähiges Modell kann durch schlechtes Kontextmanagement unter seinen Möglichkeiten bleiben. Umgekehrt kann ein gut strukturierter Harness bestimmte Schwächen eines weniger leistungsfähigen Modells abmildern, ohne sie vollständig zu beseitigen. Daraus folgt, dass Modelltests und Harness-Tests nicht vollständig voneinander getrennt werden können, aber unterschiedliche Fragen beantworten.

Für eine belastbare Bewertung sollten Unternehmen mindestens folgende Dimensionen ausweisen:

• Erfolgsquote bei der vollständigen Bearbeitung einer Aufgabe.
• Anzahl und Art der erforderlichen Werkzeugaufrufe.
• Tokenverbrauch für Planung, Kontextaufnahme und Codeausgabe.
• Durchschnittliche Bearbeitungszeit.
• Häufigkeit von Wiederholungen und Sackgassen.
• Qualität und Umfang der vorgenommenen Codeänderungen.
• Robustheit gegenüber langen Aufgabenverläufen.
• Notwendigkeit menschlicher Eingriffe.
• Fehler- und Sicherheitsrisiken.

Benchmark-Ergebnisse mit Vorsicht interpretieren

SWE-Bench Verified und Terminal-Bench 2.1 liefern wertvolle Vergleichspunkte. Sie bilden jedoch nicht die gesamte Realität professioneller Softwareentwicklung ab. Unternehmensinterne Codebasen unterscheiden sich hinsichtlich Architektur, Dokumentation, Testabdeckung, Berechtigungen und Geschäftslogik deutlich von öffentlich verfügbaren Aufgaben.

Ein Agent kann auf einem Benchmark erfolgreich sein, aber in einer realen Umgebung Schwierigkeiten mit proprietären Frameworks, veralteten Abhängigkeiten oder unvollständigen Tests haben. Umgekehrt kann ein System, das bei standardisierten Aufgaben nicht die höchste Punktzahl erreicht, in einem klar begrenzten Unternehmensprozess dennoch einen messbaren Nutzen liefern.

Benchmark-Ergebnisse sollten daher als Teil eines mehrstufigen Evaluierungsprogramms verstanden werden. Neben standardisierten Tests sind realistische, anonymisierte Unternehmensaufgaben erforderlich. Diese sollten nicht nur den Endzustand bewerten, sondern auch den Weg dorthin: Welche Aktionen wurden ausgeführt? Welche Dateien wurden gelesen? Wurden unnötige Änderungen vorgenommen? Konnte ein Mensch den Entscheidungsprozess nachvollziehen?

Die ökonomische Perspektive: Kosten entstehen nicht nur beim Schreiben von Code

Bei Coding-Agenten wird häufig der Umfang der erzeugten Codeausgabe als wichtigste Kostenquelle betrachtet. In längeren Agentensitzungen können jedoch Planung, Kontextaufnahme, Werkzeuginteraktionen und die Verarbeitung von Testergebnissen einen erheblichen Anteil des Tokenverbrauchs ausmachen. Das gilt insbesondere dann, wenn der Agent wiederholt dieselben Dateien analysiert oder große Ausgaben in jede weitere Modellanfrage übernimmt.

Ein effizienter Harness kann daher die Betriebskosten senken, ohne das zugrunde liegende Modell zu wechseln. Dazu gehören die gezielte Auswahl relevanter Informationen, kompakte Werkzeugausgaben, bedarfsabhängige Planung und eine frühzeitige Erkennung von Sackgassen.

Für die Kostenanalyse sollten Unternehmen nicht nur den durchschnittlichen Preis pro Anfrage messen. Aussagekräftiger ist eine Betrachtung pro erfolgreich gelöster Aufgabe. Ein System mit niedrigen Einzelkosten, aber hoher Fehlerquote kann teurer sein als ein System mit höherem Tokenverbrauch und weniger menschlicher Nacharbeit.

Relevante Kennzahlen sind unter anderem:

• Kosten pro abgeschlossenem Vorgang.
• Kosten pro erfolgreich akzeptiertem Pull Request.
• Tokenverbrauch nach Kontext, Planung, Werkzeugen und Ausgabe.
• Zahl der fehlgeschlagenen oder abgebrochenen Sitzungen.
• Aufwand für menschliche Überprüfung und Korrektur.
• Durchschnittliche Dauer bis zur reproduzierbaren Lösung.
• Zusätzliche Infrastrukturkosten für Sandboxes, Logs und Zustandsablage.

Eine solche Aufschlüsselung macht sichtbar, ob ein Problem tatsächlich beim Modell liegt oder ob ineffiziente Abläufe im Harness die Kosten treiben.

Kontext als Betriebsressource behandeln

Budgetierung statt ungefilterter Speicherung

Ein Kontextfenster sollte nicht als unbegrenzter Speicher betrachtet werden. Es ist eine knappe Ressource, die über mehrere Informationsarten verteilt werden muss. Dazu gehören Systemregeln, Werkzeugbeschreibungen, Aufgabeninformationen, abgerufene Dokumente, Codeausschnitte, Gesprächshistorie und ein Sicherheits- beziehungsweise Reservebereich.

Die optimale Verteilung hängt von der Aufgabe ab. Ein Agent zur Analyse eines einzelnen Fehlers benötigt möglicherweise nur wenig Historie, aber präzise Logs und relevante Codeabschnitte. Ein Agent für eine umfangreiche Refaktorierung braucht dagegen einen dauerhaft verfügbaren Projektstatus, sollte aber nicht jede frühere Terminalausgabe unverändert behalten.

Eine einheitliche Budgetregel für alle Aufgaben ist daher nicht zu erwarten. Unternehmen sollten unterschiedliche Profile definieren und anhand realer Aufgaben überprüfen. Entscheidend ist, dass die Verteilung messbar und veränderbar bleibt.

Die Qualität des Kontexts evaluieren

Die bloße Größe eines Kontextfensters sagt wenig über seine Qualität aus. Für die Evaluierung sind Fragen relevant wie:

• Findet der Agent die für die aktuelle Entscheidung relevanten Dateien?
• Werden veraltete Annahmen zuverlässig gekennzeichnet?
• Bleiben offene Teilziele über viele Interaktionen hinweg erhalten?
• Kann der Agent nach einem Fehler sinnvoll neu planen?
• Werden wichtige Testergebnisse in späteren Schritten berücksichtigt?
• Vermeidet der Agent wiederholte Recherche bereits bekannter Informationen?

Diese Fragen können durch instrumentierte Testläufe beantwortet werden. Ein Harness sollte Protokolle darüber führen, welche Inhalte in welchem Schritt bereitgestellt wurden und welche Informationen der Agent tatsächlich verwendet hat. Datenschutz und Schutz proprietärer Codeinhalte müssen bei dieser Instrumentierung berücksichtigt werden.

Konsequenzen für die Entwicklung von Unternehmenslösungen

Komponenten zunächst einzeln testen

Die wichtigste praktische Schlussfolgerung aus der Untersuchung ist die Notwendigkeit kontrollierter Experimente. Wenn ein Team gleichzeitig das Modell, die Werkzeuge, die Prompt-Struktur und die Kontextstrategie verändert, lässt sich ein Leistungsunterschied kaum eindeutig erklären.

Ein schrittweises Vorgehen kann wie folgt aussehen:

• Eine feste Gruppe repräsentativer Aufgaben definieren.
• Ein Basissystem mit unverändertem Ausführungsablauf einrichten.
• Nur eine Harness-Komponente pro Testserie verändern.
• Erfolgsquote, Kosten, Zeit und Werkzeugnutzung protokollieren.
• Ergebnisse nach Aufgabentyp und Schwierigkeitsgrad aufschlüsseln.
• Verbesserungen in einer separaten Validierungsserie überprüfen.

Diese Vorgehensweise verhindert, dass einzelne erfolgreiche Beispiele zu weitreichenden Schlussfolgerungen führen. Sie hilft außerdem, Investitionen auf die Komponenten zu konzentrieren, die im konkreten Anwendungsfall den größten Effekt erzielen.

Adaptive Strategien statt starrer Standardabläufe

Die Ergebnisse zur Planung und zum Kontextmanagement sprechen für adaptive Agentenarchitekturen. Nicht jede Aufgabe benötigt dieselbe Planungstiefe oder dieselbe Menge an Kontext. Ein Agent sollte anhand von Signalen wie Aufgabenkomplexität, Fehlerrate, Anzahl der betroffenen Dateien oder Unsicherheit über den nächsten Schritt entscheiden können, ob eine ausführlichere Planung oder eine Kontextbereinigung erforderlich ist.

Eine solche Anpassung kann beispielsweise durch Regeln ausgelöst werden:

• Nach mehreren erfolglosen Werkzeugaufrufen wird eine Neubewertung des Plans erzwungen.
• Bei wachsendem Kontext wird eine strukturierte Zusammenfassung erstellt.
• Bei Änderungen an mehreren voneinander abhängigen Modulen wird ein zusätzlicher Testschritt eingefügt.
• Bei hoher Unsicherheit wird der Agent aufgefordert, zunächst weitere Evidenz zu sammeln.
• Bei potenziell riskanten Änderungen wird eine menschliche Freigabe verlangt.

Regelbasierte Mechanismen können durch modellbasierte Entscheidungen ergänzt werden. Für den produktiven Betrieb ist jedoch eine klare Begrenzung der Autonomie erforderlich. Ein Agent sollte nicht allein deshalb mehr Aktionen ausführen dürfen, weil er seine eigene Unsicherheit niedrig einschätzt.

Sicherheit und Governance bleiben zentrale Anforderungen

Ein besseres Harness-Design erhöht nicht automatisch die Sicherheit. Ein Agent, der mehr Kontext erhält und mehr Werkzeuge verwenden darf, kann auch größere Schäden verursachen, wenn Berechtigungen, Sandboxing und Freigabepunkte fehlen.

Unternehmen sollten die technische Umgebung deshalb so gestalten, dass Aktionen nachvollziehbar, begrenzt und reversibel sind. Dazu gehören getrennte Ausführungsumgebungen, eingeschränkte Zugriffsrechte, die Protokollierung von Änderungen und eine klare Trennung zwischen Analyse und produktiver Ausführung.

Besondere Aufmerksamkeit verdienen:

• Zugriffe auf Geheimnisse, Zugangsdaten und interne Schnittstellen.
• Automatische Änderungen an produktionsnahen Systemen.
• Ausführung von Code aus nicht vertrauenswürdigen Quellen.
• Manipulation von Test- oder Validierungsmechanismen.
• Weitergabe sensibler Inhalte an externe Modellanbieter.
• Unklare Verantwortlichkeiten bei fehlerhaften Agentenentscheidungen.

Ein Agent sollte zudem nicht ausschließlich anhand eines erfolgreichen Tests als korrekt gelten. Tests können unvollständig sein oder die falsche Funktion prüfen. Für kritische Systeme sind zusätzliche Prüfungen, Code-Reviews und nachvollziehbare Freigabeprozesse erforderlich.

Einordnung in die aktuelle Forschung zu lang laufenden Agenten

Die Ergebnisse stehen im Zusammenhang mit einer breiteren Forschungslinie zu lang laufenden Aufgaben von Sprachmodellen. Mehrere Arbeiten beschreiben, dass Agenten bei langen Aktionsfolgen unter Kontextüberlastung, Zielverlust und einer zunehmenden Fehlerfortpflanzung leiden können. Wenn jede Aktion auf den Ergebnissen der vorherigen Schritte aufbaut, kann ein früher Irrtum die nachfolgenden Entscheidungen beeinflussen.

Ansätze wie hierarchische Planung, fortlaufende Kontextorganisation, externe Zustandsablage und gezielte Reflexionsschritte versuchen, diese Probleme zu reduzieren. Sie unterscheiden sich jedoch in ihrer Komplexität und in den entstehenden Kosten. Die Untersuchung zum Harness-Design ist deshalb vor allem als Beitrag zur Differenzierung zu verstehen: Nicht jede zusätzliche Schicht verbessert jedes System, und der Nutzen hängt von Modell, Budget und Aufgabe ab.

Auch Arbeiten zur dynamischen Planung weisen darauf hin, dass ein permanenter Planungsschritt ineffizient sein kann. Ein Agent sollte Planung nicht mechanisch vor jeder Aktion durchführen, sondern den zusätzlichen Rechenaufwand gegen den erwarteten Nutzen abwägen. Diese Perspektive ergänzt die Befunde zur steigenden Bedeutung von Effizienz bei leistungsfähigeren Modellen.

Grenzen der Untersuchung

Die 176 getesteten Einstellungen bieten eine vergleichsweise breite Grundlage für Komponentenvergleiche. Dennoch sind mehrere Einschränkungen zu beachten.

Erstens untersuchen Benchmarks nur einen Ausschnitt realer Softwareentwicklung. Reale Teams arbeiten mit langfristigen Wartungsprozessen, organisatorischen Abhängigkeiten, Sicherheitsvorgaben und teilweise widersprüchlichen Anforderungen. Diese Faktoren lassen sich in standardisierten Aufgaben nur begrenzt abbilden.

Zweitens kann die Auswahl von vier Modellen nicht alle Modellfamilien, Größenklassen und spezialisierten Coding-Modelle repräsentieren. Die Wirkung eines Harness-Bestandteils kann sich verändern, wenn sich Kontextlänge, Werkzeugverständnis oder Schlussfolgerungsfähigkeit des Modells unterscheiden.

Drittens ist die Ausführungsschleife zwar für kontrollierte Vergleiche nützlich, aber nicht zwangsläufig mit kommerziellen Produktionssystemen identisch. Produktive Agenten nutzen möglicherweise zusätzliche Speicher, parallele Prozesse, spezialisierte Suchsysteme oder menschliche Freigaben.

Viertens ist die Bewertung von Agentenleistungen nicht vollständig unabhängig von der Gestaltung der Aufgaben und Tests. Eine Verbesserung auf einem Benchmark bedeutet daher nicht automatisch eine entsprechende Verbesserung bei jedem Unternehmensprozess.

Die Resultate sollten folglich als belastbare Hinweise auf wichtige Designfaktoren verstanden werden, nicht als universelle Rangfolge einzelner Architekturen.

Was Unternehmen jetzt prüfen sollten

Für Organisationen, die Coding-Agenten einsetzen oder evaluieren, ergeben sich mehrere konkrete Prüffragen:

• Welche Aufgaben sollen vollständig automatisiert werden und bei welchen bleibt eine menschliche Freigabe erforderlich?
• Wie hoch ist der Anteil der Kosten, der auf Planung, Kontextaufnahme und Werkzeuginteraktionen entfällt?
• Welche Informationen muss der Agent über lange Sitzungen hinweg behalten?
• Wie werden veraltete oder widersprüchliche Informationen erkannt?
• Welche Werkzeuge sind für den jeweiligen Prozess tatsächlich notwendig?
• Wie wird verhindert, dass ein Agent unnötige oder riskante Aktionen ausführt?
• Kann die Erfolgsquote nach Modell, Harness-Konfiguration und Aufgabentyp getrennt ausgewertet werden?
• Wie werden Fehler reproduziert und von menschlichen Prüfern nachvollzogen?
• Welche Daten dürfen in externe Modellkontexte gelangen?

Ein sinnvoller Einstieg ist ein begrenzter Pilot mit anonymisierten oder nicht kritischen Aufgaben. Dabei sollte nicht nur die Zeitersparnis erfasst werden. Ebenso wichtig sind Nacharbeit, Fehlerrisiken, Akzeptanz durch Entwicklerinnen und Entwickler, Wartungsaufwand und die Stabilität bei wechselnden Projekten.

Relevanz für Plattformen und KI-Partner

Für Plattformen, die Unternehmen bei der Nutzung generativer KI unterstützen, verschiebt sich der Schwerpunkt damit von der reinen Modellauswahl hin zur Orchestrierung. Ein KI-Partner muss nicht nur Texte oder Code erzeugen, sondern auch Informationen strukturieren, Arbeitsabläufe koordinieren, Quellen verwalten und Ergebnisse nachvollziehbar machen.

Für eine All-in-one-Plattform wie Mindverse ist diese Entwicklung insbesondere deshalb relevant, weil Unternehmen selten nur eine isolierte Codegenerierung benötigen. In vielen Szenarien geht es um die Kombination aus Recherche, Inhaltsaufbereitung, Bild- und Textproduktion, Wissensmanagement und Prozessunterstützung. Die Qualität des Ergebnisses hängt dann davon ab, wie zuverlässig der Kontext über mehrere Arbeitsschritte hinweg organisiert wird.

Die Befunde zur Harness-Gestaltung lassen sich dabei nicht eins zu eins auf jede KI-Anwendung übertragen. Sie liefern jedoch ein allgemeines Prinzip: Die technische Umgebung rund um ein Modell ist ein eigenständiger Qualitätsfaktor. Gute Ergebnisse entstehen nicht allein durch ein leistungsfähiges Modell, sondern durch eine kontrollierte Verbindung von Kontext, Werkzeugen, Aufgabenlogik und Überprüfung.

Fazit: Der Wettbewerb verlagert sich auf die Ausführungsschicht

Die Untersuchung von 176 Harness-Konfigurationen macht sichtbar, dass Coding-Agenten nicht unabhängig von ihrer technischen Umgebung bewertet werden können. Planung, Aktionsraum und Kontextmanagement beeinflussen die Bearbeitung komplexer Softwareaufgaben auf unterschiedliche Weise. Ihre Wirkung hängt vom verwendeten Modell, vom verfügbaren Kontextbudget und von der Art der Aufgabe ab.

Besonders deutlich ist die Rolle des Kontextmanagements bei knappen Ressourcen. Ein Agent benötigt nicht einfach möglichst viele Informationen, sondern einen relevanten, aktuellen und strukturierten Arbeitskontext. Die Planung wiederum ist kein universeller Leistungshebel. Sie kann Genauigkeit erhöhen, aber auch zusätzliche Kosten und unnötige Schritte verursachen. Bei leistungsfähigeren Modellen scheint sich ihr Wert stärker in Richtung effizienter Rechenzeitnutzung zu verschieben.

Für Unternehmen folgt daraus eine klare methodische Konsequenz: Agentensysteme sollten nicht nur als fertige Produkte getestet werden. Die einzelnen Bestandteile des Harnesses müssen kontrolliert verändert, gemessen und an realistischen Aufgaben überprüft werden. Wer Kosten, Qualität, Sicherheit und menschliche Nacharbeit gemeinsam betrachtet, erhält ein zuverlässigeres Bild vom tatsächlichen Nutzen.

Der entscheidende Fortschritt bei Coding-Agenten könnte damit weniger in einer einzelnen neuen Funktion liegen als in der präziseren Steuerung ihrer Arbeitsumgebung. Die Frage lautet nicht mehr ausschließlich, welches Modell die beste Antwort erzeugt. Ebenso wichtig ist, welches System das Modell zum richtigen Zeitpunkt mit den richtigen Informationen, Werkzeugen und Begrenzungen versorgt.

Bibliografie Run-Ze Fan, Zihao Zhang, Simin Ma, Yebowen Hu, Shouju Wang, Kaiqiang Song, Fei Liu, Hamed Zamani und Xiaoyang Wang: An Empirical Study of Harness Design for Coding Agents. arXiv:2609.20804, veröffentlicht am 17. September 2026. https://arxiv.org/abs/2609.20804 LavX News: Study tests 176 configurations to find what makes coding agents work better. 18. September 2026. https://news.lavx.hu/article/study-tests-176-configurations-to-find-what-makes-coding-agents-work-better Cool Papers: An Empirical Study of Harness Design for Coding Agents. https://papers.cool/arxiv/2609.20804 DailyPapers beziehungsweise HuggingPapers: Beitrag zur Studie über Coding-Agent-Harnesses auf X, 18. September 2026. https://x.com/HuggingPapers/status/2100800263644705178 Davide Paglieri, Bartłomiej Cupiał, Jonathan Cook, Ulyana Piterbarg, Jens Tuyls, Edward Grefenstette, Jakob Nicolaus Foerster und Jack Parker-Holder: Learning When to Plan: Efficiently Allocating Test-Time Compute for LLM Agents. alphaXiv, 2026. https://www.alphaxiv.org/abs/2509.03581 Guangya Wan, Mingyang Ling, Xiaoqi Ren, Rujun Han, Sheng Li und Zizhao Zhang: COMPASS: Enhancing Agent Long-Horizon Reasoning with Evolving Context. Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics, 2026, Seiten 3360–3380. https://aclanthology.org/2026.acl-long.152.pdf Dosu: Your coding agent budget pays for context, not code. 25. August 2026. https://dosu.dev/blog/agent-budgets-pay-for-context Wire: Context budgets: how to allocate tokens for AI agents. 13. April 2026. https://usewire.io/blog/context-budgets-how-to-allocate-tokens-for-ai-agents Andrei Nita: Context Engineering: The Operating Discipline for Reliable AI Systems. Juni 2026. https://andreinita.co/blog/context-engineering-discipline/ Meta AI Labs: Context Engineering Inside the Harness: 4 Mechanisms That Beat Context Overflow and Goal Loss on Long-Horizon Tasks. 13. September 2026. https://metaailabs.com/context-engineering-inside-the-harness-4-mechanisms-that-beat-context-overflow-and-goal-loss-on-long-horizon-tasks/