Wie Coding-Agent-Evaluationen Testlücken finden

Ein Coding-Agent, der alle sichtbaren Tests einer Aufgabe besteht, kann trotzdem zu unsicher für einen Merge sein. Er kann altes Verhalten löschen, für das es keinen Testfall gibt, eine generierte Datei statt ihrer Quelle bearbeiten, vierzig Minuten lang das falsche Teilsystem untersuchen oder einen Patch erzeugen, der nur in dem Repository sinnvoll ist, das seine Entwickler kennen. Eine ernsthafte Evaluation muss solche Ergebnisse erkennen und darf sich nicht mit einem grünen Testlauf zufriedengeben.

Die sinnvolle Einheit ist kein Testlauf. Es ist ein Aufgabenversuch mit einem festgelegten Ausgangszustand des Repositorys, einer Anweisung, einem Budget, einem beobachtbaren Ablauf, einem Patch und mehreren unabhängigen Bewertungen. Wer den gesamten Versuch als Beleg behandelt, misst anders und behebt andere Fehler.

Wie sollte eine Aufgabe für einen Coding-Agent definiert sein?

Eine Aufgabe für einen Coding-Agent braucht einen eingefrorenen Ausgangs-Commit, eine realistische Anforderung, eine ausdrücklich definierte Ausführungsumgebung und verborgene Abnahmetests. Fehlt einer dieser vier Punkte, können zwei vermeintlich gleiche Versuche unterschiedliche Probleme lösen.

Beginnen Sie mit Arbeit, die Ihrer echten Warteschlange ähnelt. Eine Aufgabe kann einen Fehlerbericht, eine kleine Funktion, eine Abhängigkeitsmigration oder eine betriebliche Änderung betreffen. Erhalten Sie die Mehrdeutigkeit, die eine fähige Entwicklerin durch Lesen des Repositorys auflösen kann. Entfernen Sie aber Unklarheiten, die nur ein ausgeschiedener Mitarbeiter beantworten könnte. "Rundung von Rechnungen beibehalten, wenn nach einer steuerpflichtigen Zeile eine Gutschrift folgt" ist fair, sofern Code und vorhandenes Verhalten die Antwort enthalten. "Die Finanzabteilung zufriedenstellen" ist es nicht.

Fixieren Sie mehr als den Commit. Erfassen Sie Toolchain, Regeln für Abhängigkeits-Caches, verfügbare Umgebungsvariablen, Netzwerkrichtlinien, Test-Einstiegspunkte und Ressourcenlimits. Wenn die Umgebung driftet, vermischt die Kennzahl Agentenqualität mit Runner-Glück. Build-Images brauchen unveränderliche Kennungen, und Fixtures gehören versioniert neben den Evaluator.

Jeder Aufgabeneintrag sollte prüfbar sein. Eine kompakte Spezifikation kann so aussehen:

{
  "task_id": "billing-credit-rounding-014",
  "repo_commit": "4f93c2a",
  "request": "Preserve tax rounding when a credit line follows a taxable line.",
  "visible_checks": ["test_billing_unit"],
  "hidden_checks": ["credit_after_tax", "mixed_currency_unchanged"],
  "budget": {"wall_seconds": 900, "model_cost_usd": 8.00},
  "allowed_paths": ["src/billing", "tests/billing"]
}

Die verborgenen Prüfungen sind kein Trick. Sie hindern den Agenten daran, sich direkt an der vollständigen Musterlösung zu orientieren. Bewahren Sie einige Verhaltensprüfungen außerhalb des Repositorys auf und wechseln Sie einen Teil regelmäßig aus, denn Agenten können aus Testnamen und benachbarten Fixtures erstaunlich viel ableiten.

Führen Sie jede Aufgabe mehrmals aus. Das Verhalten eines Agenten schwankt, selbst wenn Modell und Prompt gleich bleiben. Ein glücklicher Durchlauf zeigt, dass die Aufgabe lösbar ist. Wiederholte Versuche zeigen, ob das System verlässlich arbeitet. Speichern Sie Seed oder Sampling-Einstellungen, wenn der Anbieter sie bereitstellt, aber tun Sie nicht so, als beseitigten sie jede Schwankung.

Warum bestandene Tests nur ein Urteil liefern

Tests beantworten, ob ausgewählte Beobachtungen den Erwartungen entsprechen. Sie beweisen nicht, dass der Patch passend begrenzt, wartbar, sicher oder mit Verhalten kompatibel ist, das die Suite nie erfasst hat.

Bewerten Sie die Aufgabenerfüllung in Schichten. Führen Sie zuerst die sichtbaren Prüfungen aus, die auch der Agent ausführen konnte. Danach folgen verborgene Tests für benachbarte Eingaben und den gemeldeten Grenzfall. Drittens kommen Prüfungen für das gesamte Repository, darunter Linting, Typprüfung, Builds und Tests abhängiger Pakete. Viertens prüfen Sie Eigenschaften, die Test-Frameworks selten bemerken: unerlaubte Dateiänderungen, neue Abhängigkeiten, Änderungen an öffentlichen APIs, Migrationen, generierte Artefakte und verdächtig gelöschte Tests.

Halten Sie diese Urteile getrennt, statt sie sofort in einer Prozentzahl zusammenzufassen. Ein Patch, der das Ziel behebt und ein anderes Paket beschädigt, unterscheidet sich von einem Patch, der das Ziel nie behoben hat. Beide dürfen nicht veröffentlicht werden, doch sie verlangen andere Korrekturen. Der erste deutet auf schwache Auswirkungsanalyse oder unzureichende Erkundung des Repositorys. Der zweite spricht für eine schlechte Umsetzung oder ein falsch verstandenes Ziel.

Die Patch-Prüfung lässt sich teilweise automatisieren. Lehnen Sie Änderungen außerhalb einer Positivliste ab, wenn die Aufgabe eine enge Grenze hat. Markieren Sie weniger Assertions, neue Skips, breite Exception-Handler und geänderte Snapshot-Dateien. Das sind Anlässe zur Prüfung, keine automatischen Beweise für Täuschung. Eine berechtigte Korrektur kann einen Snapshot ändern oder eine veraltete Assertion entfernen. Bewahren Sie deshalb den Diff und die Erklärung des Agenten für die menschliche Prüfung auf.

Ergänzen Sie eine kleine Bewertungsrubrik für Eigenschaften, die Maschinen noch nicht konsistent beurteilen. Prüfer können bewerten, ob der Patch lokalen Abstraktionen folgt, Validierung an der richtigen Grenze platziert, toten Code hinterlässt oder zusätzliche Wartung erzeugt. Verwenden Sie verankerte Optionen wie "entspricht einem vorhandenen Muster im Repository" und "schafft einen parallelen Mechanismus". Vage Punkte von eins bis fünf driften zwischen Prüfern und vermitteln kaum Erkenntnisse.

Die Entscheidung über das Bestehen sollte streng bleiben: gefordertes Verhalten, Regressionsprüfungen und Zustand des Repositorys müssen stimmen. Der diagnostische Datensatz sollte ausführlich bleiben. Teams zerstören oft den Nutzen einer Evaluation, indem sie nur Grün oder Rot speichern. Bei der nächsten Agentenversion fehlt ihnen dann jeder Beleg für eine Verschiebung der Werte.

Bereits behobenes Verhalten gehört in die Suite

Eine Evaluation für Coding-Agents sollte Fehler wiederholen, deren Verständnis Ihr Team bereits bezahlt hat. Solche Fälle legen das Regressionsrisiko viel besser offen als eine Sammlung aus ausschließlich neuen, sauber umrissenen Tickets.

Bewahren Sie nach der Behebung eines Produktionsfehlers drei Dinge auf: den Zustand des Repositorys vor der Korrektur, das für Benutzer sichtbare Symptom und ein Orakel, das richtiges Verhalten erkennt. Das Orakel kann ein gezielter Test, eine aufgezeichnete Anfrage mit Antwort, ein Übergang des Datenbankzustands oder ein Befehl mit normalisierter Ausgabe sein. Entfernen Sie Secrets und instabile Zeitstempel, bevor Sie Datenverkehr speichern.

Es gibt zwei unterschiedliche Regressionsfragen. "Kann der Agent einen alten Fehler ausgehend vom defekten Zustand beheben?" misst Reparaturfähigkeit. "Führt ein neuer Patch für eine andere Aufgabe diesen alten Fehler wieder ein?" misst die Erhaltung des Verhaltens. Teams vermischen beides und erhalten einen Benchmark, der Fehlerbehebung belohnt, aber nichts über Kollateralschäden aussagt.

Bauen Sie eine wachsende Verhaltensbank aus abgeschlossenen Vorfällen und schwierigen Review-Funden auf. Kennzeichnen Sie jeden Fall nach Teilsystem, Fehlermechanismus und Folge. Wählen Sie für jede Aufgabe passende Fälle sowie eine kleinere Stichprobe aus dem gesamten Repository. Die passende Auswahl findet Schäden in der Nähe. Die Stichprobe findet überraschende Kopplungen, etwa wenn ein Billing-Formatter einen Berichtsexport verändert, weil beide dieselbe Rundungshilfe nutzen.

Testen Sie gegen die Bank nicht nur den aktuellen Standard-Branch. Führen Sie den exakten Agenten-Patch auf seiner eingefrorenen Basis aus, denn spätere menschliche Änderungen können Fehler verdecken oder erzeugen. Schlägt ein Test auf Basis und Patch fehl, klassifizieren Sie ihn als vorhandenes Rauschen. Besteht er auf der Basis und scheitert nach dem Patch, ist die Regression dem Versuch zuzurechnen.

Instabile Prüfungen brauchen Quarantäne mit Zuständigkeit und Belegen, keine stillen Wiederholungen bis zum grünen Ergebnis. Erfassen Sie jeden einzelnen Lauf. Eine Retry-Regel kann zeigen, ob ein Patch nach Ihren aktuellen CI-Regeln veröffentlichbar ist. Die Rohdaten zeigen dagegen, dass die Evaluationsumgebung oder das Produkt nicht deterministisch ist. Wer beides vermischt, lässt den Agenten besser aussehen, ohne seinen Patch sicherer zu machen.

Eine wachsende Verhaltensbank wird teuer, daher braucht sie Stufen. Führen Sie nahe, schnelle Fälle bei jedem Versuch aus, breitere Wiederholungen vor der Freigabe einer Agentenversion und die langsamsten Systemfälle nach Zeitplan. Entscheidend ist monoton wachsende Abdeckung: Ein Fall verschwindet nur, wenn das Verhalten nicht mehr existiert oder ein stärkeres Orakel ihn ersetzt.

Kosten brauchen einen Nenner und ein Fehlerbuch

Kosten pro erfolgreich abgeschlossener Aufgabe sind aussagekräftiger als Token-Kosten pro Lauf. Günstige Versuche, die scheitern oder einen Entwickler zur Reparatur des Patches zwingen, sind keine günstige Arbeit.

Erfassen Sie Modellkosten für Ein- und Ausgabe, Kosten für gecachte Tokens, Tool-Rechenzeit, Sandbox-Zeit und jeden kostenpflichtigen externen Dienst, den ein Lauf aufruft. Behalten Sie die technische Prüfzeit als eigenes Feld, statt einen erfundenen Geldbetrag anzusetzen. Medianwerte der Prüfminuten lassen sich trotzdem zwischen Agentenversionen und Aufgabenklassen vergleichen.

Betrachten Sie Kosten mindestens aus vier Perspektiven:

• Kosten pro Versuch zeigen ausufernde Erkundung;
• Kosten pro akzeptierter Aufgabe schließen Fehlversuche ein;
• Kosten nach Aufgabenklasse und Repository verhindern, dass leichte Arbeit teure Fälle verdeckt;
• Kosten verschwendeter Läufe nach Fehlerkategorie führen zu behebbaren Orchestrierungsfehlern.

Berichten Sie Verteilungen statt nur Durchschnittswerte. Der Median beschreibt einen üblichen Lauf. Das 90. oder 95. Perzentil findet Agenten, die dieselben Dateien wiederholt durchgehen, immer neu bauen oder das ganze Repository in den Kontext laden. Ein hartes Budget sollte solche Läufe beenden und als Budgetüberschreitung markieren, nicht als gewöhnlichen Aufgabenfehler.

Caching erschwert Vergleiche. Ein warmer Abhängigkeits-Cache kann für einen internen CI-Worker realistisch sein, während ein warmer Modell-Prompt-Cache wiederholte Benchmark-Aufgaben künstlich verbilligt. Wählen Sie die Bedingung, die der Produktion entspricht, kennzeichnen Sie sie und nehmen Sie einen Durchlauf mit kaltem Cache auf. Vergleichen Sie nie eine Version mit warmen Aufgaben und eine andere mit neu erstellten Aufgaben.

Das Fehlerbuch ist wichtig, weil Einsparungen aus verschiedenen Änderungen stammen. Kommt der Großteil verschwendeter Ausgaben von Fehlern beim Einrichten der Umgebung, hilft ein Modellwechsel nicht. Liest der Agent wiederholt vendorten Code, verbessern Sie Repository-Hinweise oder Tool-Filter. Erreicht er nach langen Testzyklen einen korrekten Patch, verbessern Sie Testauswahl und inkrementelle Builds.

Kostengrenzen verändern auch das Verhalten. Unter engem Limit kann ein Agent die erste plausible Korrektur umsetzen und breite Prüfungen auslassen. Bewerten Sie die Qualität bei mehreren Budgets, bevor Sie eine Konfiguration als effizient bezeichnen. Der sinnvolle Betriebspunkt liegt dort, wo zusätzliche Ausgaben keine merkliche Steigerung akzeptierter Aufgaben oder Verringerung schwerer Regressionen mehr bringen.

Latenz sollte dem kritischen Pfad folgen

Messen Sie die verstrichene Zeit so, wie der Benutzer sie erlebt, und teilen Sie diese Zeit dann in Phasen, die das Team beeinflussen kann. Eine einzelne Dauer verrät nicht, ob das Modell nachdachte, ein Tool startete, Abhängigkeiten installiert wurden, Tests liefen oder ein Runner überlastet war.

Erfassen Sie Zeitstempel für Warteschlangeneintritt, Bereitschaft der Sandbox, erste Modellantwort, jeden Tool-Aufruf, ersten Patch, Beginn der Verifikation und Endergebnis. Daraus entstehen Wartezeit, Einrichtungszeit, Zeit bis zur ersten Änderung, aktive Agentenzeit, Prüfzeit und Gesamtdauer. Halten Sie Modelllatenz und Befehlsdauer getrennt.

Die Zeit bis zur ersten Änderung sagt besonders viel. Eine sehr kurze Zeit kann bedeuten, dass der Agent geraten hat, bevor er lokale Konventionen las. Eine sehr lange Zeit kann bedeuten, dass er irrelevante Verzeichnisse durchsuchte. Beides ist nicht automatisch schlecht. Setzen Sie den Wert in Beziehung zu Patch-Akzeptanz und untersuchten Dateien.

CI sollte die Latenz des kritischen Pfads messen, nicht parallele Arbeit addieren. Laufen Unit-Tests und statische Analyse gleichzeitig acht Minuten, hat der Benutzer acht und nicht sechzehn Minuten gewartet. Der Ressourcenverbrauch kann trotzdem sechzehn Worker-Minuten betragen und gehört dann in den Kostendatensatz.

Definieren Sie Ziele nach Aufgabenklasse. Eine Korrektur in einer Konfigurationsdatei und eine paketübergreifende Schemaänderung dürfen nicht denselben Grenzwert haben. Vergleichen Sie den Agenten mit dem menschlichen Ablauf, den er ersetzt oder unterstützt: Zeit bis zum prüfbaren Patch, Zeit bis zum akzeptierten Merge und Arbeitszeit des Prüfers. Der Agent kann langsamer einen Patch liefern und insgesamt schneller sein, wenn seine Belege das Review erleichtern. Er kann auch schnell sein und einen Nachmittag für Korrekturen verbrauchen.

Timeouts verdienen ein eigenes Ergebnis. Bewerten Sie einen abgebrochenen Lauf nicht genauso wie einen falschen Patch. Bewahren Sie seinen letzten zusammenhängenden Zustand, den Tool-Ablauf und den Budgetverbrauch auf. Wiederholte Timeouts in einem Repository zeigen oft ein Evaluator-Problem, etwa einen Testbefehl, der auf einen nicht verfügbaren Dienst wartet, statt schwacher Codeerzeugung.

Führen Sie den Latenz-Benchmark auf kontrollierten Workern aus und beobachten Sie die gemeinsam genutzte CI getrennt. Kontrollierte Läufe erlauben Modellvergleiche. Gemeinsame Runner zeigen Kapazitätsbedarf und die tatsächliche Erfahrung der Entwickler. Eine Vermischung erzeugt einen verrauschten Wert, der keine der beiden Fragen beantwortet.

Fremde Repositories legen andere Fehler offen

Ein Agent, der nur auf Repositories evaluiert wird, die seine Entwickler kennen, übernimmt deren Annahmen. Ein fremder Codebestand prüft, ob der Agent Regeln entdecken kann, statt sie über das Benchmark-Design vorgegeben zu bekommen.

Die typischen Fehler beginnen vor der Codeerzeugung. Der Agent wählt den falschen Testbefehl, verwechselt generierten Code mit der Quelle, übersieht eine zweite Sprache im Build, ignoriert eine lokale Patch-Konvention oder bearbeitet ein gemeinsames Modul, ohne seine Nutzer zu finden. Solche Versuche können kompilieren und einen gezielten Test bestehen. Sie scheitern, weil der Agent eine falsche Karte des Systems aufgebaut hat.

Wählen Sie externe oder neu übernommene Repositories mit rechtlicher Erlaubnis und reproduzierbarem Build. Frieren Sie sie ein, bevor die Autoren der Aufgaben sie gründlich erkunden. Eine Gruppe sollte die Umgebung paketieren, eine andere Aufgaben aus echter Issue-Historie oder beobachteten Defekten erstellen. Wenn dieselbe Person den Code studiert, detaillierte Hinweise schreibt und das Ergebnis bewertet, gelangt ihr Verständnis in die Anweisung.

Messen Sie das Erkundungsverhalten, ohne eine ideale Reihenfolge vorzuschreiben. Aussagekräftige Signale sind, ob der Agent Repository-Hinweise liest, Build-Einstiegspunkte findet, vor der Änderung eines gemeinsamen Symbols nach Aufrufern sucht, mehrere Implementierungen erkennt und vor dem Abschluss den Diff prüft. Vergeben Sie keine Punkte für die Zahl der Tool-Aufrufe. Zehn Suchen können Sorgfalt oder Verwirrung bedeuten.

Nehmen Sie Repositories mit unbequemen, aber echten Merkmalen auf: mehrere Sprachen, eigene Generatoren, wenige Tests, große Fixtures, plattformspezifische Skripte und irreführende Verzeichnisnamen. Bauen Sie keine künstlichen Fallen. Sie wollen sehen, ob der Agent mit normaler angesammelter Geschichte zurechtkommt, nicht ob er ein Rätsel des Evaluators löst.

Kontamination lässt sich schwer beweisen, daher sollte das Design sie abfedern. Nutzen Sie privaten Code, sofern Sie dazu berechtigt sind, aktuelle Snapshots, die in älteren Trainingsdaten nicht vorkommen konnten, und lokale Transformationen wie umbenannte Geschäftsobjekte. Eine Umbenennung allein schafft kein neues Denkproblem, reduziert aber einfaches Auswendiglernen. Starke Belege kommen aus vergleichbarer Leistung auf bekannten und tatsächlich unbekannten Repositories, nicht aus der Frage an ein Modell, ob es den Code kennt.

Der Ablauf erklärt Fehler, die im Patch unsichtbar bleiben

Speichern Sie die beobachtbaren Aktionen des Agenten, weil der endgültige Diff weder den Weg zur Antwort noch ignorierte Hinweise oder den Grund für ein ausgeschöpftes Budget zeigt. Ein kompakter Ereignisverlauf macht Fehler reproduzierbar, ohne private Modellgedanken anzufordern.

Bewahren Sie für jede Modellrunde Prompt-Version, Antwortkennung, Token-Verbrauch, Tool-Anfrage, Ergebnisstatus, Zeitstempel und betroffene Dateien oder Befehle auf. Entfernen Sie Secrets vor dem Speichern und begrenzen Sie Befehlsausgaben strikt. Beim Debugging kann der Agent Umgebungswerte oder Kundendaten ausgeben. Deshalb braucht der Zugriff auf Abläufe denselben Schutz wie der Quellcode.

Bewerten Sie keine verborgenen Gedankentexte und belohnen Sie den Agenten nicht dafür, den erwarteten Ansatz zu erzählen. Anbieter geben unterschiedliche interne Signale heraus, und eine saubere Erklärung kann schlechte Entscheidungen verdecken. Beurteilen Sie Aktionen und Artefakte: Der Agent hat Build-Anweisungen gelesen, nach Aufrufern gesucht, eine Datei geändert, eine gezielte Prüfung gestartet, einen Fehler gesehen und den Patch überarbeitet.

Klassifizieren Sie die erste entscheidende Fehlentscheidung. Spätere Symptome entstehen oft daraus. Wenn der Agent einen generierten Client bearbeitet, dann gegen den Generator kämpft und schließlich abbricht, beschreibt "Timeout" nur den Endzustand, nicht die richtige technische Reaktion. Die nützliche Kategorie lautet Erkennung der maßgeblichen Quelle. Weitere Kategorien können Umgebungserkundung, Aufgabenverständnis, Abhängigkeitswahl, Auswirkungsanalyse, Umsetzung und Verifikation sein.

Erfassen Sie auch die Erholung von Fehlern. Ein Agent, der nach einer gescheiterten Prüfung eine falsche Annahme erkennt, unterscheidet sich von einem Agenten, der denselben Befehl sechsmal wiederholt. Nützliche Ablaufkennzahlen sind identische Tool-Aufrufe in Folge, Zeit zwischen einer gescheiterten Prüfung und der nächsten Änderung, Anteil untersuchter Dateien außerhalb des betroffenen Teilsystems und eine abschließende Verifikation auf sauberem Zustand. Deuten Sie diese Signale zusammen mit dem Aufgabenergebnis. Keines davon ist allein eine Qualitätszahl.

Abläufe legen auch Eingriffe des Harness offen. Ein Tool kann genau den Compilerfehler abschneiden, der den Defekt benennt. Eine Sandbox-Regel kann einen normalen Repository-Befehl blockieren. Die Orchestrierung kann Erfolg melden, nachdem sie einen Kindprozess beendet hat. Trennen Sie Evaluator-Ereignisse von Agenten-Ereignissen, damit der Eigentümer jedes Fehlers sichtbar bleibt.

Die Aufbewahrung braucht klare Regeln. Patch, normalisierte Ergebnisse und aggregierte Kennzahlen sollten länger erhalten bleiben als rohe Befehlsausgaben. Wenn Sie detaillierte Abläufe löschen, bewahren Sie Fehlerklassen und Evaluator-Versionen auf, damit historische Vergleiche möglich bleiben. Ein Evaluationsarchiv, das unbemerkt Zugangsdaten und Produktionsausschnitte sammelt, ist selbst eine misslungene Sicherheitskontrolle.

Der Evaluator kann vor dem Agenten versagen

Ein Evaluations-Harness ist Produktionssoftware. Wenn sein Orakel falsch liegt, die Sandbox Zustand preisgibt oder sich eine Fixture nicht bauen lässt, misst die Kennzahl Fehler des Evaluators.

Prüfen Sie jede Aufgabe mit zwei Kontrollen. Die negative Kontrolle ist der unveränderte defekte Commit und muss am Zielorakel scheitern. Die positive Kontrolle ist die bekannte menschliche Korrektur und muss Ziel- und Regressionsorakel bestehen. Eine Aufgabe, die eine Kontrolle nicht erfüllt, gehört erst nach der Reparatur in die bewertete Sammlung.

Testen Sie dann die Isolation. Jeder Versuch braucht einen frischen Worktree, einen sauberen Prozess-Namespace, bei zeitabhängigem Verhalten eine kontrollierte Uhr und eigene Dienstressourcen. Eine Datenbank aus dem vorigen Lauf kann den nächsten Patch fälschlich korrekt erscheinen lassen. Gemeinsame Abhängigkeits-Caches können zulässig sein, dürfen aber keine veränderlichen Aufgabenausgaben enthalten.

Der Runner sollte ein kompaktes, stabiles Ergebnis ausgeben, das CI aufbewahren kann:

$ ./eval-agent fixtures/billing-credit-rounding-014
task=billing-credit-rounding-014 outcome=regression
target=pass hidden=pass repository=fail
cost_usd=3.42 wall_seconds=286 review=required
artifacts=patch.diff,events.json,test-results.xml

Normalisieren Sie nicht deterministische Werte vor dem Vergleich. Sortieren Sie ungeordnete Datensätze, ersetzen Sie generierte Kennungen durch stabile Platzhalter und vergleichen Sie nach Möglichkeit strukturierte Daten statt Screenshots oder Logs. Jede Normalisierungsregel kann einen Fehler verdecken, daher gehört das rohe Artefakt neben das normalisierte.

Versionieren Sie Evaluator, Aufgabe und Orakel unabhängig voneinander. Wenn sich ein Orakel ändert, müssen genug Metadaten für die Reproduktion alter Werte erhalten bleiben. Rechnen Sie sie neu, wenn das machbar ist. Eine Modellversion darf nicht allein deshalb besser aussehen, weil jemand im selben Pull Request eine Fixture gelockert hat.

Untersuchen Sie regelmäßig eine Stichprobe vermeintlicher Evaluator-Fehler von Hand. Prüfen Sie Infrastrukturfehler, verdächtig schnelle Erfolge und Gruppen, bei denen jede Agentenversion identisch scheitert. Oft sind die Aufgaben defekt. Sie als Modellfehler zu zählen mag vorsichtig wirken, lenkt die Entwicklungsarbeit aber auf das falsche System.

Eine Scorecard muss harte Fehler bewahren

Die Scorecard sollte Freigabeentscheidungen klären, ohne eine Sicherheitsregression oder Datenbeschädigung durch Mittelwerte verschwinden zu lassen. Nutzen Sie Sperren für unzulässige Ergebnisse und Kennzahlen für Abwägungen.

Beginnen Sie mit Zulassungssperren: Der Agent muss in der erlaubten Umgebung bleiben, unerlaubten Zugriff auf Secrets vermeiden, einen prüfbaren Patch erzeugen und alle schweren Regressionsorakel bestehen. Ein Verstoß schließt den Kandidaten unabhängig von seiner durchschnittlichen Erfolgsrate aus. Definieren Sie Schweregrade vor dem Vergleich, sonst werden Teams unbequeme Fehler nachträglich umetikettieren.

Zeigen Sie für zugelassene Kandidaten eine Tabelle nach Aufgabenklasse und Repository. Sie sollte Rate akzeptierter Aufgaben, Zielkorrekturen, regressionsfreie Läufe, Median und Randwerte der Kosten pro akzeptierter Aufgabe, Median und Randwerte der Laufzeit, Prüfminuten und Fehlerkategorien enthalten. Nennen Sie neben Prozentwerten die absoluten Zahlen. Drei von vier und fünfundsiebzig von hundert ergeben denselben Prozentwert, aber nicht dieselbe Sicherheit.

Vermeiden Sie einen gewichteten Gesamtwert, solange kein automatisches Auswahlsystem ihn erzwingt. Gewichte verstecken Richtlinienentscheidungen und führen zu Diskussionen über Rechenwege. Eine Freigabeprüfung kann stattdessen fragen, ob der Kandidat jede Sperre überwindet, die wichtigen Kennzahlen verbessert und Regressionen innerhalb der erklärten Toleranz hält.

Vergleichen Sie mit sinnvollen Baselines. Dazu gehören die aktuelle Agentenkonfiguration, ein kleiner Agent mit weniger Tools und ein Zustand ohne Agent, in dem der Evaluator keinen Patch anwendet. Ergebnisse von Menschen können helfen, wenn Aufgaben und Arbeitsbedingungen vergleichbar sind. Erfahrene Maintainer im eigenen Code sind aber kein allgemeiner Maßstab für einen fremden Agenten.

Teilen Sie Ergebnisse auf, bevor Sie dem Gesamtwert vertrauen. Prüfen Sie Sprache, Repository-Größe, Testqualität, Aufgabentyp und Überschreitung von Teilsystemgrenzen. Ein Kandidat kann die Schlagzeilenzahl verbessern, indem er bei kleinen TypeScript-Änderungen stark zulegt und bei Datenbankmigrationen schlechter wird.

Behandeln Sie abweichende Prüferentscheidungen als Daten. Akzeptiert ein Prüfer einen vom Harness abgelehnten Patch oder lehnt er einen bestandenen ab, verlangen Sie einen Grundcode und untersuchen Sie das Orakel. Der Prüfer kann sich irren, doch aus der Abweichung lernt die Scorecard.

Die CI-Einführung braucht Kontrollgruppen und Stoppregeln

Führen Sie einen Coding-Agent in CI als gemessene Änderung mit festem Vergleichsfenster und Stoppbedingungen ein. Wer ihn sofort auf jeden Pull Request loslässt, macht Entwickler zu unbezahlter Evaluationsinfrastruktur.

Beginnen Sie im Schattenmodus mit repräsentativen Aufgaben. Der Agent erhält denselben Repository-Zustand und dieselbe Anforderung, darf aber den echten Branch nicht verändern. Vergleichen Sie Patch und Belege mit dem Ergebnis der normalen Entwicklungsarbeit. Der Schattenbetrieb deckt Lücken in der Umgebung und Prüfaufwand auf, ohne Änderungen auf den Merge-Pfad zu setzen.

Erlauben Sie danach Vorschläge für Aufgabenklassen mit geringen Folgen und verpflichtendem Review. Behalten Sie per Zufall eine Kontrollgruppe auf der vorherigen Agentenversion oder im normalen Ablauf. Ohne gleichzeitige Kontrolle können Änderungen der Aufgabenverteilung, Repository-Aktivität und CI-Last wie Verbesserungen aussehen.

Schreiben Sie Stoppregeln vor der Einführung. Pausieren Sie automatische Vorschläge, wenn eine schwere Regression auftritt, Secret-Grenzen verletzt werden, Infrastrukturfehler des Evaluators die Toleranz überschreiten oder Randkosten das Budget sprengen. Eine Stoppregel muss benennen, wer die Einführung fortsetzen darf und welche Belege dafür nötig sind.

Beobachten Sie Anpassungen. Entwickler können ungewöhnlich genaue Issues für den Agenten verfassen, schlecht geeignete Aufgaben meiden oder vertraute Patch-Formen ungeprüft bestätigen. Das verändert die scheinbare Leistung. Prüfen Sie Stichproben von Anforderungen und Review-Kommentaren und halten Sie einen stabilen Benchmark außerhalb der Live-Warteschlange.

Der Paritäts-Harness von CodeHero vergleicht das Verhalten des neu geschriebenen Systems mit aufgezeichnetem Produktionsverkehr, weil ein sauberer Build nicht beweist, dass Jahrzehnte an Grenzfällen einen Architekturwechsel überstanden haben. Für einen CI-Agenten gilt dasselbe Prinzip: Bewahren Sie echtes Verhalten als ausführbaren Beleg und prüfen Sie jeden Patch dagegen.

Eine Beförderung muss umkehrbar sein. Halten Sie die alte Konfiguration bereit, kennzeichnen Sie jeden Agenten-Patch mit der Evaluator-Version und bewahren Sie den Aufgabenversuch lange genug für spätere Regressionsanalysen auf. Wenn Sie einen Produktionsfehler nicht mit Prompt, Repository-Zustand, Patch und freigebenden Prüfungen verbinden können, ist der Evaluationsdatensatz unvollständig.

Prüfen Sie den Benchmark nach jeder wesentlichen Änderung an Modell, System-Prompt, Tool-Berechtigungen, Kontextaufbau oder Runner-Image erneut. Diese Komponenten wirken zusammen. Eine reine Modellversionsnummer identifiziert das System hinter einem Patch nicht. Halten Sie eine kleine Canary-Auswahl für schnelle Vergleiche stabil und aktualisieren Sie die breitere Sammlung mit der Live-Arbeit. Wenn Aufgaben ausscheiden, führen Sie alte und neue Sammlung eine Zeit lang parallel aus, damit geänderte Schwierigkeit nicht wie geänderte Qualität erscheint.

Ein Agent verdient erst mehr Befugnisse, wenn er in den vorgesehenen Repositories wiederholt akzeptable Patches innerhalb eines vertretbaren Budgets erzeugt. Grüne Tests eröffnen die Prüfung. Sie beenden sie nicht.