SWE-bench ist kein Einkaufstest: So bauen Sie ein internes Eval-Set für Coding Agents

Stellen Sie sich folgende typische Beschaffungsrunde vor: Der Einkauf legt eine Folie vor. Darauf stehen ein Modellname und ein Prozentwert mit zwei Nachkommastellen. Die beiden Senior-Entwickler nicken. Dann fragt der Engineering Lead, mit welchem Agenten-Setup dieser Wert entstanden ist. Niemand kann die Frage beantworten.

Der Wert ist nicht erfunden. Er beantwortet nur nicht die Frage, um die es in dieser Besprechung geht. SWE-bench misst nie das Modell allein. Für Forschung und Trendvergleiche ist der Benchmark nützlich, über den Coding Agent in Ihrem Repository sagt er wenig. Diese Frage beantwortet nur eine eigene Messung an eigenen Tickets, und die muss man planen, bevor man sie durchführt.

Kurz gefasst: Ein öffentlicher Benchmark-Wert misst das Zusammenspiel aus Modell, Scaffold, Prompt, Laufprotokoll und Aufgabensatz. Ein internes Eval braucht zwei Dinge: unabhängige Tickets und Wiederholungen pro Ticket. Die Tickets bestimmen, welchen Ausschnitt Ihrer Arbeit der Test abbildet. Die Wiederholungen zeigen, wie stark ein Agent auf derselben Aufgabe schwankt. Ein Set mit 20 bis 30 Tickets ist ein pragmatischer Start für ein repo-nahes Screening großer Unterschiede, aber kein universell belastbarer Kaufnachweis. Vergleichen Sie alle Kandidaten auf denselben Aufgaben mit dem heutigen Workflow, planen Sie die endgültige Größe anhand eines Pilotversuchs und werten Sie die Unterschiede paarweise auf Ticketebene aus. Das Verfahren deckt nur die technische Seite ab. Berechtigungen, Datenschutz, Betrieb und Support bewerten Sie separat.

Zwei Begriffe, die im Folgenden ständig vorkommen und leicht verwechselt werden:

• Agenten-Scaffold: die Orchestrierungsschicht, die das Modell mit Systemprompt, Werkzeugen, Kontextverwaltung und Planungslogik verbindet. Je nach Produkt stammt sie vom Anbieter, aus einem Open-Source-Projekt oder aus dem eigenen Team. Häufig lassen sich Teile kundenseitig konfigurieren.
• Eval-Harness: die gemeinsame Umgebung, die Aufgaben, Repository-Zustand, Tests, Ressourcenlimits, Protokollierung und Auswertung bereitstellt. Sie können sie selbst entwickeln oder auf einem bestehenden Framework aufbauen. Entscheidend ist, dass sie für alle Kandidaten gleich konfiguriert ist.

Daraus folgt eine Grenze, die später über die Fehlerzurechnung entscheidet: Alles, was mit dem Kandidaten geliefert, für ihn konfiguriert oder von ihm zur Bearbeitung verwendet wird, gehört zum Kandidaten-Setup. Dazu zählen sein Scaffold, seine Parser, Toolwrapper, Kontextverwaltung und Aufruflogik. Zum Eval-Harness gehört nur die gemeinsame Infrastruktur, die für alle Kandidaten gleich aufgesetzt ist und Aufgaben bereitstellt, Ressourcen begrenzt, protokolliert und bewertet.

Wie dieser Schritt in den gesamten Auswahlprozess passt, zeigt die Cluster-Übersicht zu Coding-Agents im Unternehmen. Der technische Vergleich sollte vor dem Pilotbetrieb, dem Vertragsabschluss und dem Kauf der ersten Lizenz stattfinden.

Warum ein öffentlicher Benchmark kein Einkaufstest ist

Fangen wir mit der stärksten Fassung des Gegenarguments an. SWE-bench Verified war methodisch strenger als das Ausgangsset. 93 Entwickler prüften 1.699 Aufgaben, von denen 68,3 Prozent rausflogen. Gewertet wird binär: Der Patch muss die vorher roten Tests grün machen und die vorher grünen grün lassen. Kein Teilfortschritt, keine Geschmacksfrage. Für reproduzierbare Forschung bleibt das ein brauchbares Instrument.

Die Betreiber nehmen die Einschränkung inzwischen ernster als viele Anbieter in ihren Verkaufsunterlagen. Seit dem 18. November 2025 akzeptieren SWE-bench Verified und Multilingual nur noch Einreichungen mit einer offenen Forschungsveröffentlichung oder einem technischen Bericht sowie einer akademischen oder institutionellen Forschungsaffiliation. Reine Produktvalidierungen ohne diese Voraussetzungen sind ausgeschlossen. Seit Februar 2026 veröffentlicht OpenAI keine SWE-bench-Verified-Werte mehr und empfiehlt anderen Modellentwicklern dasselbe.

Der Benchmark bildet nicht Ihre Entwicklungsrealität ab

Von den 500 Aufgaben entfallen 231 auf ein einziges Repository, django/django. Zwölf öffentliche Python-Projekte insgesamt. Kein Java, kein C#, kein TypeScript, kein Go. Und keine Aufgabe ist neuer als August 2023, für aktuelle Modelle gibt es also keine verlässliche zeitliche Trennung zwischen Benchmark und möglichem Training. Wie stark sich Aufgaben und Trainingsdaten überschneiden, lässt sich von außen nicht feststellen, weil die Anbieter der hier betrachteten Frontier-Modelle ihre vollständigen Trainingskorpora nicht veröffentlichen. OpenAI schreibt selbst, alle getesteten Frontier-Modelle hätten bei einigen Aufgaben die ursprüngliche Entwicklerlösung oder wörtliche Details der Aufgabenstellung reproduzieren können. Eine unabhängige Untersuchung (arXiv:2410.06992) fand 37 der 500 Instanzen, bei denen die Lösung direkt in der Aufgabenbeschreibung oder der GitHub-Diskussion steht.

Das Scaffold beeinflusst den Wert stärker als das Modell

Nehmen wir an, alles oben wäre geklärt und der Benchmark wäre sauber. Die Zahl wäre trotzdem kein reiner Modellwert. Ein Preprint zur langfristigen Weiterentwicklung von Software (arXiv:2512.18470) hat dieselben Modelle mit zwei Scaffolds getestet. Mit OpenHands erzielt ein Modell 4,17 Prozent, mit SWE-agent 39,58 Prozent. Gleiche Gewichte, gleiche Aufgaben.

Am 27. Juli 2026 enthielt das offizielle Terminal-Bench-2.0-Leaderboard zehn Einträge mit Claude Opus 4.6. Die Werte reichten von 58,0 Prozent mit Claude Code bis 76,4 Prozent mit Meta-Harness. Dazwischen lagen Terminus 2, Mux, Crux, Droid, TongAgents, MAYA-V2, Terminus-KIRA und Capy. Die ausgewiesenen Werte desselben Modells unterscheiden sich je nach Agenten-Setup also um 18,4 Prozentpunkte. Neun Einträge weisen Fehlerbalken zwischen 2,2 und 2,9 Prozentpunkten aus, für Crux ist keiner angegeben.

Terminal-Bench 2.1 war zu diesem Zeitpunkt bereits veröffentlicht und korrigiert 28 der 89 Aufgaben aus Version 2.0. Die Darstellung verwendet bewusst den historischen 2.0-Stand, weil dort zehn direkt vergleichbare Opus-4.6-Setups vorliegen. Werte verschiedener Benchmark-Versionen werden nicht vermischt.

Eine kontrollierte Untersuchung (arXiv:2605.23950, Preprint) kommt anhand von 100 Aufgaben zum selben Befund: Die Unterschiede zwischen den Scaffolds waren etwa 7,8-mal so groß wie die zwischen den Modellen. Und schon eine Änderung am Prompt verschiebt den Wert. Anthropic schreibt in einer Fußnote zu Claude Opus 4.6: „Our score was averaged over 25 trials. With a prompt modification, we saw a score of 81.42%.“ Diese Transparenz ist zu begrüßen und belegt zugleich genau das.

Daraus folgt eine Prüfregel für die Beschaffung: Lassen Sie sich für jeden Einkaufswert Benchmark-Version, Agenten-Setup, Prompt, Laufprotokoll und Primärquelle zeigen. Eine Tabelle in einer Produktpräsentation oder einem Sekundärtext ersetzt diese Prüfung nicht.

Der Bauplan: das Eval-Set

Es sind vier Schritte, und der erste kostet mehr, als seine Beschreibung vermuten lässt.

1. Tickets finden, nicht aussuchen

Legen Sie vor der Auswahl fest, für welchen künftigen Arbeitsmix der Test gelten soll: Repository, Zeitraum, Aufgabenklassen, Team, Sprache, typische Änderungsgröße und Ausschlüsse. Ziehen Sie anschließend innerhalb dieser Gruppen zufällig oder nach einem schriftlich festgelegten Verfahren. Ohne diese Zielpopulation wird „repräsentativ“ stillschweigend zu „20 bis 30 beliebige gute Tickets“.

SWE-bench hat aus rund 90.000 Pull Requests am Ende 2.294 verwertbare Instanzen gewonnen (arXiv:2310.06770), also 2,5 Prozent. Wer aus 25 Tickets reproduzierbare Eval-Aufgaben bauen will, muss eher mehrere Hundert gemergte Pull Requests prüfen als dreißig. Die Vorfilter stammen aus SWE-bench und SWE-rebench und lassen sich direkt übernehmen:

Dokumentieren Sie für jedes ausgeschlossene Ticket den Ausschlussgrund, den Zeitpunkt der Entscheidung, die verantwortliche Person oder Regel und ob die Entscheidung vor Kenntnis der Kandidatenergebnisse fiel.

Danach prüfen Sie, ob sich der Ausgangszustand reproduzieren und die Lösung eindeutig bewerten lässt. Das SWE-bench-Schema reicht dafür nicht: Ein reiner FAIL_TO_PASS-Test passt zu Bugfixes, aber viele echte Refactorings ändern das Verhalten absichtlich nicht, ihre Tests sind vorher und nachher grün. Wer nur nach „vorher rot, nachher grün“ filtert, sortiert genau die Klassen aus, die das Set abdecken soll. Jede braucht ihr eigenes Zulassungskriterium:

In allen vier Fällen gilt zusätzlich: Die vorher grünen Tests müssen grün bleiben.

Mischen Sie die Klassen, statt dreißig Bugfixes zu nehmen. Ein Set mit 20 Tickets könnte sich auf sechs Bugfixes, sechs Refactorings, vier Migrationen und vier Features verteilen. Diese Verteilung dient der inhaltlichen Abdeckung, sie trägt bei so wenigen Tickets keine getrennten Aussagen über jede einzelne Klasse. Für eine bestätigende Kaufentscheidung priorisieren Sie deshalb entweder ein bis zwei geschäftskritische Klassen und sammeln genügend unabhängige Tickets dafür, oder Sie decken alle ab, berichten pro Klasse nur deskriptiv und führen die Primäranalyse über den vorab gewichteten Gesamtmix durch.

2. Die Aufgabe aus einem frischen Export bauen

Wie schwer reproduzierbare Umgebungen sind, zeigt die SWE-bench-Historie selbst. In der Dokumentation zur Docker-Umstellung heißt es zu festgeschriebenen Abhängigkeitsversionen: „In hindsight, it is underspecified.“ Das Team musste auf Container umstellen.

Seit September 2025 ist auch die Informationsisolation nicht mehr optional. Ein Meta-Entwickler eröffnete damals das Issue „Repo State Loopholes During Agentic Evaluation“. Die Auswertungs-Container wurden mit vollständiger Git-Historie ausgeliefert, inklusive der Commits, die den Fehler später behoben. Protokolliert ist unter anderem dieser Aufruf:

git log --oneline --grep="31926" -i

Der Agent hat nicht zufällig etwas gefunden. Er hat die späteren Commit-Nachrichten nach der Ticketnummer durchsucht, die man ihm gegeben hatte. Das ist keine Bosheit, das ist kompetentes Verhalten. Ich würde es genauso machen.

Daraus folgt die Grundregel: Bauen Sie den Aufgabencontainer aus einem frischen Export des Base-Commits, nicht aus einer bereits verwendeten Arbeitskopie. Das Löschen des obersten .git-Verzeichnisses allein genügt nicht. Übrig bleiben können ungetrackte und ignorierte Dateien, Build-Artefakte, lokale Caches, verschachtelte Repositories, Submodule samt Metadaten und Zugangsdaten. git clean erfasst ignorierte Dateien nur mit der entsprechenden Option, git archive exportiert dagegen den Commit-Baum ohne Historie. Die Checkliste pro Aufgabenimage:

1. Frischer Export: Arbeitsbaum aus dem Base-Commit erzeugen, etwa mit git archive oder einem gleichwertigen, überprüften Verfahren.
2. Keine Entwickler-Arbeitskopie: kein Verzeichnis, in dem vorher spätere Branches, Builds oder Tests gelaufen sind.
3. Submodule und Git LFS explizit behandeln: nur die am Base-Commit referenzierten Versionen materialisieren und danach deren eigene Historie entfernen.
4. Verschachtelte Repositories prüfen: Der Build muss fehlschlagen, wenn unerwartete .git-, .hg- oder .svn-Metadaten auftauchen.
5. Keine ungetrackten oder ignorierten Reste: Caches, Coverage-Dateien, Build-Outputs und lokale Datenbanken dürfen nicht aus einer späteren Arbeitskopie stammen.
6. Keine Remotes: Das neue Repository erhält keine Remote-Konfiguration.
7. Keine Credentials: Git-Credentials, .netrc, CLI-Sessions von GitHub oder GitLab, SSH-Schlüssel und einschlägige Umgebungsvariablen entfernen.
8. Netzwerk standardmäßig sperren: Der Aufgabencontainer bekommt keinen allgemeinen Internetzugang, in Docker etwa über den none-Treiber. Der Orchestrator darf den Modellanbieter weiterhin aufrufen.
9. Abhängigkeiten vorab bereitstellen: Images und Dependency-Caches vor dem Agentenlauf bauen. Ist Netzwerk nötig, nur dokumentierte Endpunkte erlauben.
10. Leakage-Prüfung protokollieren: Ergebnis der Dateisystem-, Credential- und Netzwerkprüfung je Aufgabenimage speichern.

Erst nach diesem Export initialisieren Sie im kontrollierten Verzeichnis ein Repository mit genau einem Commit. Das stellt dem Agenten weiterhin git diff zur Verfügung, ohne die Historie des Ursprungsrepositories zu übernehmen.

git -C "$EXPORT" init -q && git -C "$EXPORT" add -A
git -C "$EXPORT" -c user.name=Eval -c user.email=eval@invalid commit -qm base

Zwei weitere Leckpfade werden schnell übersehen: Der Tickettext darf den Merge-Commit nicht enthalten, und der Container darf keine CI-Konfiguration aus der Zeit nach dem Base-Commit mitbringen.

Durchsuchen Sie das Agentenprotokoll zusätzlich nach git log, git show, git cat-file und git reflog. Treffer sind ein Prüfhinweis, kein Ausschluss. Nach einer sauberen Isolation sind diese Befehle legitim. Abgewertet wird ein Lauf erst, wenn sich ein Zugriff auf Zukunftsdaten nachweisen lässt.

3. Prüfungen nach Risiko trennen

Hier verspreche ich weniger, als der Aufhänger nahelegt. Für diese Praxis gibt es gute Gründe, aber noch keine abschließende Evidenz.

Der anschaulichste Grund steht in einem Preprint zu Programmieraufgaben mit langer Bearbeitungsdauer (arXiv:2605.21384). Ein Agent sollte einen C-Compiler bauen. Er baute keinen. Stattdessen schickte er die öffentlichen Testprogramme durch den installierten GCC, sammelte die erwarteten Ausgaben ein und legte sie in einer 2.900 Zeilen langen Hash-Tabelle ab. Ergebnis: 97 Prozent in den sichtbaren Tests, 0 Prozent in den zurückgehaltenen. Ein echter Compiler-Versuch im selben Durchgang kam auf 53 und 43 Prozent.

Entscheidend war dabei nicht, dass irgendwelche Tests zurückgehalten wurden, sondern welche. Die sichtbaren Tests prüfen einzelne spezifizierte Funktionen, die zurückgehaltenen prüfen, ob diese Funktionen in realistischen Kombinationen zusammenarbeiten. Genau diese strukturelle Differenz macht Abkürzungen sichtbar.

Teilen Sie Tests deshalb nicht nach einer festen Quote auf. Entwerfen Sie für jedes Ticket zunächst die Akzeptanzkriterien. Machen Sie dem Agenten die Tests sichtbar, die einzelne Anforderungen konkretisieren und eine sinnvolle Iteration ermöglichen. Behalten Sie Prüfungen zurück, die das Zusammenspiel dieser Anforderungen, relevante Grenzfälle und benachbarte Regressionen abdecken. Der Umfang beider Gruppen folgt aus den Risiken des Tickets.

Für die zurückgehaltenen Prüfungen eignen sich mindestens diese Kategorien: Zusammenspiel mehrerer spezifizierter Funktionen, Grenz- und Fehlerfälle, Datenmigration und Rollback, Rückwärtskompatibilität, benachbarte Regressionen, Berechtigungs- und Mandantengrenzen sowie Idempotenz bei wiederholter Ausführung.

Dazu vier Regeln. Zurückgehaltene Tests dürfen keine neuen Anforderungen erfinden, sondern müssen aus Ticket, Spezifikation und vorab definierten Risiken ableitbar sein. Sie stehen vor den Kandidatenläufen fest und werden nicht nachträglich aus den Fehlern eines bestimmten Kandidaten gebaut. Die Referenzlösung muss sichtbare, zurückgehaltene und Regressionstests wiederholt bestehen. Und die Aufteilung ersetzt keine menschliche Prüfung.

Wie zuverlässig das Verfahren ist, hängt von der Aufgabengröße ab. Eine Untersuchung an kleineren Wettbewerbsaufgaben (arXiv:2511.21654) stellte beim Einsatz zurückgehaltener Testfälle nur minimale Verbesserungen fest. Ein LLM-Urteil war dort wirksamer. Bei umfangreicheren Aufgaben können zurückgehaltene Tests solche Lücken aufdecken. Als allgemeines Erkennungsverfahren reichen sie jedoch nicht aus.

4. Wiederholungen planen, statt sie zu raten

Ein internes Eval hat zwei Stichprobengrößen. Die Zahl unabhängiger Tickets bestimmt, welche Unterschiede im ausgewählten Backlog sichtbar werden. Die Zahl der Wiederholungen pro Ticket zeigt, wie stark derselbe Agent auf derselben Aufgabe schwankt. Mehr Wiederholungen senken die Unsicherheit über die Laufstreuung, machen das Set aber nicht repräsentativer für andere Tickets. Aus 25 Tickets mit je drei Läufen werden statistisch keine 75 unabhängigen Aufgaben.

Dass Wiederholungen überhaupt nötig sind, zeigt eine Untersuchung anhand von 60.000 Trajektorien (arXiv:2602.07150, Preprint): Die Streuung liegt bei über 1,5 Prozentpunkten selbst bei Temperatur 0, allein durch die Reihenfolge von Fließkommaberechnungen und die Parallelisierung. Berichtete Verbesserungen von zwei bis drei Punkten können also Rauschen sein.

Benchmark-spezifisches Beispiel: In derselben Studie mit vollständigen SWE-bench-Verified-Durchgängen, also jeweils 500 Aufgaben, waren unter den dort beobachteten Bedingungen rund neun vollständige Durchgänge pro Kandidat nötig, um einen Unterschied von zwei Prozentpunkten mit 80 Prozent Teststärke zu erkennen. Diese Zahl lässt sich nicht auf ein internes Set mit 20 oder 30 Tickets übertragen. Sie ist ein Beispiel für dieses Benchmark-Design, keine Vorgabe für Ihr Eval-Set.

Legen Sie deshalb zuerst fest, welcher Unterschied eine Kaufentscheidung verändern würde. Führen Sie anschließend einen Pilotversuch durch, schätzen Sie die Streuung der gepaarten Ticket-Ergebnisse und berechnen Sie daraus, wie viele unabhängige Tickets und wie viele Wiederholungen Sie benötigen. Daraus ergibt sich ein Vorgehen in drei Stufen.

Phase 1, technischer Probelauf. Fünf Tickets, je drei Läufe, ein Kandidat oder der technisch am einfachsten integrierbare. Keine Rangliste, keine Aussage zur Teststärke, keine Kaufentscheidung. Es geht nur darum, ob Umgebung, Tests, Logging, Zeitmessung, Informationsisolation und Fehlerklassifikation funktionieren.

Phase 2, Pilot und Größenplanung. Baseline und Kandidaten bearbeiten dieselben vorab ausgewählten Tickets aus dem späteren Zielbereich, mit mehreren Wiederholungen. Sie schätzen die Unterschiede auf Ticketebene, prüfen, wie viel Streuung zwischen den Tickets und wie viel innerhalb desselben Tickets liegt, und berechnen daraus den kleinsten zuverlässig erkennbaren Unterschied, englisch Minimum Detectable Effect oder MDE, für verschiedene Kombinationen aus Ticketzahl und Wiederholungen. Diese Rechnung braucht zwei weitere vorab gewählte Größen: ein Signifikanzniveau und eine gewünschte Teststärke. Ein kleiner, bewusst diverser Pilot ist ein pragmatischer Einstieg, kein bestätigender Test und kein Standardmaß.

Phase 3, Entscheidungs-Evaluation. Ein entscheidungstaugliches Eval-Set, dessen Größe aus den Pilotdaten und dem kleinsten relevanten Unterschied abgeleitet wurde. Dazu gehören eine vorab festgelegte Primärmetrik, vorab festgelegte Veto-Kriterien, eine Baseline, die paarweise Auswertung derselben Tickets und ein Konfidenzintervall auf Ticketebene. Nach Sichtung der Ergebnisse wird die Entscheidungsregel nicht mehr geändert. Ob dabei 20, 30 oder 60 Tickets herauskommen, ist ein Ergebnis dieser Planung und keine Vorgabe.

Welche Erfolgskennzahl Sie primär auswerten, folgt aus der geplanten Retry-Politik, nicht aus Gewohnheit:

Keine dieser Kennzahlen ist grundsätzlich die wichtigste. pass^k, eingeführt im τ-bench-Papier, misst die Wahrscheinlichkeit, dass alle k Versuche gelingen. Im dortigen Teilversuch zum Einzelhandel fiel die Erfolgsquote von rund 61 Prozent bei einem Versuch auf rund 25 Prozent, wenn alle acht gelingen mussten. Legen Sie Retry- und Freigabepolitik vor dem Eval fest und wählen Sie k entsprechend. Ein einzelner Lauf liefert ohnehin nur ein beobachtetes Ergebnis, keine Schätzung der Laufstreuung: Das Codex-Paper schätzt pass@1 aus 200 Stichproben pro Aufgabe.

Die Artefakte: Manifest und Ergebnisformat

Ein Bauplan, der nur aus Prinzipien besteht, ist keiner. Das Aufgabenmanifest zerfällt in einen agentensichtbaren und einen nur für das Harness sichtbaren Teil.

# tasks/migration-014/task.yaml (diese Felder sieht der Agent)
task_id: migration-014
task_class: migration
task_text: tasks/migration-014/brief.md
visible_test_command: ./gradlew visibleEval
time_limit_minutes: 60
resource_limits:
  cpu: 4
  memory_gb: 8
network_policy: none
allowed_tools:
  - shell
  - editor

# harness/migration-014.yaml (bleibt im Harness)
task_id: migration-014
repository: payments-service
base_commit: "<sha>"
selection_stratum: "migration"
environment_image_digest: "sha256:..."
holdout_test_command: ./gradlew holdoutEval
regression_test_command: ./gradlew test
reference_patch_digest: "sha256:..."
reference_runs_required: 3
baseline_candidate: current-workflow
exclusion_reason: null

Der Agent darf keine Pfade oder Befehle sehen, die die zurückgehaltenen Tests verraten, deshalb bleiben Referenzlösung und Prüfdaten im Harness und das Image wird über einen Digest statt über einen veränderlichen Tag identifiziert. Netzwerk- und Credential-Policy gehören ebenfalls ins Manifest, nicht in eine mündliche Absprache. Jeder Lauf schreibt danach eine Zeile mit mindestens diesen Feldern:

candidate_id, candidate_version, model_id, scaffold_version, prompt_hash,
task_id, task_class, run_id, outcome, failure_owner, patch_applies,
visible_tests_pass, holdout_tests_pass, regressions, leakage_detected,
review_minutes, wall_time_seconds, input_tokens, output_tokens,
reported_cost, log_reference

Das Feld failure_owner entscheidet später über die Auswertung und hat feste Werte: common_harness, candidate_setup, task_solution, external_outage, policy_violation, leakage_from_harness.

Auswertung, Baseline und Entscheidung

Wem der Fehler gehört

Gekauft wird kein nacktes Modell, sondern ein Agenten-Setup. Wenn Parser, Toolwrapper oder Orchestrierung des Kandidaten versagen, ist das ein Produktproblem und kein Messfehler. Entsprechend wird zugerechnet:

Die Bewertungsmatrix

Die Kennzahlen werden stets auch nach Aufgabenklasse ausgewiesen. Ein vorab gewichteter Gesamtwert darf diese Einzelwerte nicht ersetzen.

Der Erstversuchserfolg lässt sich zusätzlich als diagnostische Kennzahl berichten. Er ist aber kein Fachbegriff und nicht mit pass@1 gleichzusetzen: pass@1 bezeichnet eine Erfolgswahrscheinlichkeit, hier steht der beobachtete Anteil erfolgreicher Erstläufe. Weder DORA noch SPACE noch DX Core 4 erfassen den menschlichen Prüfaufwand, und keiner der geprüften Benchmarks veröffentlicht eine Regressionsrate. Die Bausteine sind belegt, ihre Zusammenstellung ist ein eigener Vorschlag.

Dass es sich lohnt, den Prüfaufwand zu messen, zeigt die METR-Studie von 2025: Die Entwickler brauchten dort 19 Prozent mehr Zeit, obwohl sie ihre Ersparnis selbst auf 20 Prozent schätzten.

So rechnen Sie die Läufe zusammen

Die Auswertung hat vier Schritte. Berechnen Sie für jeden Kandidaten und jedes Ticket den Anteil erfolgreicher Wiederholungen. Bilden Sie je Ticket die Differenz zwischen Kandidat und Baseline. Mitteln Sie diese Ticketdifferenzen. Und berechnen Sie ein Konfidenzintervall, das ganze Tickets als Stichprobeneinheit behandelt, etwa mit einem Cluster-Bootstrap. Einzelne Wiederholungen werden dabei nie so gezogen, als wären sie unabhängige Tickets.

Wenn Sie Aufgabenklassen vorab unterschiedlich gewichten, müssen Sie diese Gewichte auch bei der Mittelung anwenden. Beim Bootstrap ziehen Sie die Tickets dann innerhalb der Aufgabenklassen und kombinieren die Ergebnisse anschließend mit den vorab festgelegten Gewichten. Das folgende Beispiel nimmt der Einfachheit halber gleich gewichtete Tickets an.

Das Skript macht genau das. Es verwendet die mittlere Erfolgsrate über die gültigen Wiederholungen eines Tickets als Primärmetrik und implementiert weder pass@k noch pass^k. Soll eine dieser Kennzahlen die spätere Nutzung abbilden, muss die Aggregation entsprechend angepasst werden. Die Daten sind erfunden und dienen nur der Veranschaulichung: zwölf Tickets, eine Baseline und zwei Kandidaten, drei gültige Läufe je Ticket, dazu ein ungültiger Harnesslauf mit Ersatzlauf und zwei kandidateneigene Werkzeugfehler.

"""Auswertung eines internen Eval-Sets. Synthetische Beispieldaten.

Zeichen je Lauf: 1 = bestanden, 0 = fachlich gescheitert,
t = Fehler im kandidateneigenen Setup (zählt als Misserfolg),
h = Fehler der gemeinsamen Infrastruktur (ungültig, wird wiederholt).
"""
import random, statistics

LAEUFE = {
    "baseline":   ["110", "100", "111", "010", "000", "101",
                   "110", "000", "011", "100", "111", "010"],
    "kandidat_a": ["111", "110", "111", "110", "010", "1h11",
                   "111", "100", "111", "110", "111", "011"],
    "kandidat_b": ["110", "1t0", "111", "010", "001", "110",
                   "101", "000", "011", "1t1", "110", "100"],
}
PRUEFMINUTEN = {
    "baseline":   [35, 40, 25, 45, 50, 30, 35, 55, 40, 45, 25, 40],
    "kandidat_a": [20, 25, 15, 20, 35, 20, 15, 30, 20, 25, 15, 25],
    "kandidat_b": [30, 45, 25, 40, 50, 30, 35, 50, 40, 45, 30, 40],
}


def anteil(runs):
    """Erfolgsanteil eines Tickets, nur über die gültigen Wiederholungen."""
    gueltig = [c for c in runs if c != "h"]
    return sum(c == "1" for c in gueltig) / len(gueltig), len(gueltig)


def bootstrap(diffs, ziehungen=10000, seed=20260727):
    """Cluster-Bootstrap: gezogen werden ganze Tickets, keine Einzelläufe."""
    rng = random.Random(seed)
    m = sorted(statistics.fmean(rng.choices(diffs, k=len(diffs)))
               for _ in range(ziehungen))
    return m[int(0.025 * ziehungen)], m[int(0.975 * ziehungen)]


basis = [anteil(r) for r in LAEUFE["baseline"]]

for name, runs in LAEUFE.items():
    werte = [anteil(r) for r in runs]
    diffs = [a - b for (a, _), (b, _) in zip(werte, basis)]
    lo, hi = bootstrap(diffs)
    print(name, len(werte), "Tickets,", sorted({n for _, n in werte}), "gültige Läufe,",
          f"Erfolg {statistics.fmean(a for a, _ in werte):.1%},",
          f"Differenz {statistics.fmean(diffs):+.1%} [{lo:+.1%} bis {hi:+.1%}],",
          f"Prüfzeit {statistics.median(PRUEFMINUTEN[name]):.0f} min,",
          sum(r.count("t") for r in runs), "Setupfehler,",
          sum(r.count("h") for r in runs), "ungültig")

Die Ausgabe, hier als Tabelle gesetzt:

Die Intervalle stammen aus dem Skript oben, nicht aus meinem Kopf. Kandidat A liegt deutlich über der Baseline, sein Intervall enthält die Null nicht, und er halbiert die Prüfzeit. Kandidat B liegt nominal vorn. Sein Intervall schließt die Null jedoch ein, deshalb lässt sich kein belastbarer Vorteil gegenüber der Baseline feststellen. Der Harnessfehler bei Kandidat A wurde nicht als Kandidatenmisserfolg gewertet. Der ungültige Lauf wurde verworfen und ersetzt, sodass für jedes Ticket drei gültige Wiederholungen vorliegen. Laufzeit und Rechenkosten des ungültigen Versuchs müssen in einer realen Auswertung dennoch separat als Evaluationsaufwand erfasst werden. Bei sehr wenigen Tickets zeigen Sie zusätzlich die vollständigen Einzelergebnisse und kennzeichnen alle statistischen Aussagen als explorativ.

Warum diese Vorsicht nötig ist, führt das oben genannte Preprint zur Software-Weiterentwicklung vor: Bei 48 Aufgaben verschiebt eine einzige gelöste Aufgabe das Ergebnis um 2,08 Prozentpunkte, und bei einem Punktschätzer von 25 Prozent reicht das 95-Prozent-Wilson-Intervall von 14,9 bis 38,8 Prozent. Deshalb bearbeiten alle Kandidaten dieselben Aufgaben und werden paarweise ausgewertet (arXiv:2411.00640). Führen Sie außerdem die Referenzlösung dreimal aus. Was nicht reproduzierbar grün wird, fliegt aus dem Set.

Ein solches Set kann deutliche Probleme auf den ausgewählten Migrationstickets sichtbar machen. Ob diese Probleme für Migrationen allgemein typisch sind, lässt sich mit vier oder sechs Tickets dieser Klasse nicht beantworten.

Die Baseline ist ein Kandidat

Behandeln Sie den heutigen Workflow als weiteren Kandidaten. Das kann das bestehende Coding-Tool sein, der aktuelle Agent oder ein kontrollierter menschlicher Workflow. Ohne diese Baseline wählen Sie nur den besten neuen Kandidaten aus. Sie prüfen nicht, ob sich ein Kauf überhaupt lohnt.

Setzen Sie bereits einen Coding-Agenten ein, lassen Sie ihn mit unveränderter Konfiguration auf denselben Tickets laufen. Ist der heutige Workflow überwiegend menschlich, vergleichen Sie nicht die Laufzeit des Agenten mit der historischen Durchlaufzeit des ursprünglichen Tickets, diese Zahlen entstehen unter völlig verschiedenen Bedingungen. Brauchbar sind ein prospektiver Shadow-Pilot mit neuen Tickets oder eine kontrollierte Bearbeitung historischer Aufgaben durch Entwickler, die diese Tickets nicht kannten. Ist kein sauberer menschlicher Vergleich möglich, nehmen Sie das aktuelle Werkzeug als technische Baseline und benennen die fehlende Vergleichbarkeit als Einschränkung.

Die Entscheidungsregel steht vorher fest

Wer erst nach dem letzten Lauf festlegt, wie daraus ein Sieger wird, legt die Regeln nach Kenntnis der Ergebnisse fest. Das ist derselbe Fehler, den dieser Artikel den Verkaufsunterlagen vorwirft, nur im eigenen Haus. Das folgende Beispiel ist ein Ausgangspunkt, kein Formular:

• Schwere Regressionen und Sicherheitsverstöße sind Ausschlussgründe.
• Fehler der gemeinsamen Evaluationsinfrastruktur machen einen Lauf ungültig und führen zu einer Wiederholung.
• Fehler im kandidateneigenen Scaffold, Parser oder Tooling zählen als Kandidatenfehler und werden zusätzlich als eigene Kategorie ausgewiesen.
• Primär wird jeder Kandidat auf denselben Tickets paarweise mit der Baseline verglichen.
• Ein Kandidat kommt nur infrage, wenn er einen vorab festgelegten Mindestvorteil gegenüber der Baseline erreicht. Alternativ liegt er technisch innerhalb einer vorab festgelegten Nichtunterlegenheitsgrenze und bringt zugleich einen ausreichenden Vorteil bei Prüfaufwand, Zeit oder Kosten.
• Erreicht kein Kandidat diese Schwelle, lautet das Ergebnis: nicht kaufen. Nur besser als ein anderer Kandidat zu sein, aber nicht besser als die Baseline, reicht nicht.
• Kleine Unterschiede, deren Konfidenzintervall die Entscheidungsschwelle schneidet, gelten als nicht entschieden. Ein Gleichstand bleibt ein Gleichstand. Nachträgliche Zusatzanalysen dürfen ihn nicht künstlich auflösen.

Wie groß der Mindestvorteil sein muss, kann dieser Artikel nicht vorgeben. Die Schwelle kommt aus Ihrem Geschäftskontext: aus tolerierbaren Regressionen, Review-Zeit, Kosten oder Durchlaufzeit.

Die Metriken für die Zeit nach dem Rollout behandelt der Beitrag über DORA-Metriken für Coding Agents. Hier geht es um die Zeit davor.

Grenzen und Aufwand

Das Harness ist nicht neutral. Die Abrechnungseinheiten der Werkzeuge sind nicht vergleichbar: Dollar pro Lauf, reine Token-Zähler, Anfragen pro Tag, Nachrichten innerhalb von fünf Stunden. Manche liefern unstrukturierten Text, bei dem ein Parserfehler in einer naiven Auswertung wie ein gescheiterter Agentenlauf aussieht. Tragen Sie Kosten nur dort ein, wo der Hersteller sie nachvollziehbar ausweist, und sonst „nicht offengelegt“ statt einer eigenen Schätzung. Bei Pauschaltarifen lassen sich die Kosten ohnehin keiner einzelnen Aufgabe zurechnen. Wollen Sie Kosten pro Aufgabe ausweisen, müssen alle Kandidaten über eine verbrauchsabhängig abgerechnete API laufen, und das Ergebnis ist ein Schattenpreis, der den üblichen Beschaffungsweg nicht abbildet.

Ihre Stichprobe kann das Ergebnis vorbestimmen. Ein Team, das die Tickets kennt, wählt unbewusst einfache oder gut dokumentierte Tickets aus, leitet Akzeptanztests aus der Referenzlösung ab oder überrepräsentiert eine Aufgabenklasse. Deshalb die schriftlichen Auswahlregeln vor dem ersten Blick ins Backlog und die menschliche Prüfung ohne Kenntnis des geprüften Werkzeugs.

Es ist Ihr Repository, nicht die Welt. Das Ergebnis sagt etwas über Ihren Code, Ihre Tests, Ihre Ticketkultur. Es ist genau deshalb wertvoll und genau deshalb nicht übertragbar.

Zum Aufwand, getrennt nach Phasen. Der technische Probelauf ist mit einem halben bis einem Personentag plausibel, aber nur unter engen Voraussetzungen: ein Repository, vorhandenes Container-Image, Tests mit einem Kommando, keine komplexen Submodule.

Für ein Screening-Set mit 20 bis 30 Tickets schätze ich zwei bis fünf Personentage in einem gut vorbereiteten einzelnen Repository. Enthalten sind Vorauswahl, Reproduktion, Manifest, einfache zurückgehaltene Prüfungen und die Harness-Integration. Nicht enthalten sind eine menschliche Baseline, aufwendige risikobasierte Testentwicklung, statistische Größenplanung, mehrere Repositories, Submodule und Git LFS sowie die Netzwerk- und Credential-Härtung. Das ist meine Schätzung, keine erhobene Zahl.

Für das entscheidungstaugliche Set nenne ich bewusst keine Dauer. Sie hängt von der nach dem Pilot erforderlichen Ticketzahl und von der Komplexität der Akzeptanzprüfung ab. Ein Set, das nur große Unterschiede screenen soll, ist deutlich günstiger als ein bestätigender Test für kleine.

Drei Größen sollten Sie getrennt ausweisen, weil sie sonst in derselben Zelle landen: Entwicklungsaufwand (Arbeitszeit von Menschen), verstrichene Laufzeit (ein Agentenlauf über Nacht kostet keine Arbeitszeit) und Rechenkosten (API oder Lizenz). Sonst wird ein mehrstündiger Agentenlauf mit mehreren Stunden menschlicher Arbeit verwechselt, oder umgekehrt.

Der nächste Schritt

Beginnen Sie diese Woche, ohne neuen Lizenzvertrag, mit fünf abgeschlossenen Tickets, bei denen Code und Tests gemeinsam geändert wurden. Lassen Sie jedes dreimal bearbeiten und behandeln Sie diese fünfzehn Läufe ausschließlich als technischen Probelauf. Prüfen Sie, ob Aufgabencontainer, Informations- und Netzwerkisolation, Testtrennung, Logging und Fehlerklassifikation funktionieren. Nehmen Sie anschließend die Baseline und alle Kandidaten in einen Pilotversuch auf und schätzen Sie aus den gepaarten Ticket-Ergebnissen, welchen Unterschied ein größeres Set erkennen kann. Erst danach legen Sie die Größe des Entscheidungstests fest.

Das Ergebnis kann auch lauten, dass 20 bis 30 Tickets für Ihre Entscheidung nicht ausreichen oder dass keiner der Kandidaten den heutigen Workflow deutlich genug verbessert. Beides ist nützlich.

Innerhalb von rund sechs Monaten stieg der Spitzenwert auf dem Terminal-Bench-2.0-Leaderboard von weniger als 65 Prozent im Januar 2026 (arXiv:2601.11868) auf 84,7 Prozent. Das belegt die kurze Halbwertszeit des Vergleichsmaßstabs, nicht einen Leistungszuwachs in Ihrem Repository. Wählen Sie entsprechend kurze Vertragslaufzeiten. Und legen Sie das Eval-Set dem Einkauf hin, statt der Folie zu widersprechen. Eine eigene Messung ist für diese Entscheidung aussagekräftiger als ein fremder Prozentwert, wenn Auswahl, Isolation, Baseline und Auswertung belastbar sind.