Ein neues Modell oder eine neue Agentenversion auf Ihren Repositories prüfen, bevor sie Standard wird

Was sich bei einem Upgrade tatsächlich ändert

Anthropics Leitfaden zur Evaluierung macht einen Punkt, der hier zählt: Wer einen Agenten bewertet, bewertet Harness und Modell zusammen. Ein Upgrade kann das Modell ändern, die Version des Tools, seine Standardeinstellungen oder die Art, wie es Ihre Anweisungen liest, und jede dieser Änderungen kann die Ergebnisse auf Ihren Repositories verschieben.

Upgrades kommen außerdem, ohne dass jemand entscheidet. Die Modell-Aliase von Claude Code zeigen auf die empfohlene Version und ändern sich mit der Zeit, während ein vollständiger Modellname eine Version fixiert und Administratoren die wählbaren Modelle mit availableModels in den verwalteten Einstellungen einschränken können. Bei Copilot Business und Enterprise aktiviert GitHub ein neu benanntes Basismodell automatisch nach 60 Tagen und sagt zu, ein Long-Term-Support-Modell ab seiner Benennung ein Jahr lang verfügbar zu halten.

Zwei Suites mit unterschiedlichen Aufgaben

Anthropic unterscheidet Capability-Evaluierungen von Regressions-Evaluierungen, und diese Trennung passt gut zu einer Upgrade-Entscheidung.

• Regressions-Suite: Aufgaben, die Ihr aktuelles Setup zuverlässig besteht, etwa typische Bugfixes, ergänzte Tests und Dependency-Updates aus Ihrer Historie. Sie sollte nahezu vollständig bestehen, deshalb ist jeder Rückgang eine Warnung.
• Capability-Suite: Aufgaben, mit denen Ihr aktuelles Setup kämpft und bei denen sich ein besseres Modell zeigen sollte. Sie beginnt absichtlich mit einer niedrigen Erfolgsquote.
• Verhaltens-Checks für beide: geskriptete Prüfungen Ihrer Vorgaben, etwa unveränderte generierte Pfade, keine gelöschten Tests und keine neuen Abhängigkeiten ohne Auftrag.

Anthropic hält 20 bis 50 Aufgaben aus echten Fehlschlägen für einen guten Anfang. Bauen Sie sie aus gemergten Änderungen, nachgespielt in isolierten Kopien des Repositorys, deren Historie vor der Änderung endet, ohne spätere Refs, Remotes oder Netzwerkzugriff auf die gemergte Lösung. Der Agent sieht die vorhandenen Tests, und die mit jeder Änderung hinzugefügten Akzeptanztests werden für die Bewertung zurückgehalten.

Einen fairen Vergleich durchführen

1. 1

   Alles andere konstant halten

   Dieselben Aufgaben, Anweisungsdateien, Berechtigungen und Tools für beide Versionen. Protokollieren Sie für jeden Lauf Tool-Version, Modell-ID und Einstellungen und ändern Sie jeweils nur eines davon, wo das Tool es zulässt.

2. 2

   Jeden Durchlauf sauber starten

   Eine frische Umgebung pro Lauf, ohne Dateien, Caches, Agenten-Memory oder Historie aus früheren Versuchen.

3. 3

   Mehrere Durchläufe pro Aufgabe

   Ergebnisse schwanken von Lauf zu Lauf. Berichten Sie die Erfolgsquote im ersten Versuch und, für Aufgaben, die immer gelingen müssen, wie oft alle Durchläufe bestehen. Bei 75 Prozent Erfolg pro Durchlauf bestehen drei unabhängige Durchläufe nur in etwa 42 Prozent der Fälle alle, und echte Durchläufe sind selten völlig unabhängig.

4. 4

   Zuerst kaputte Aufgaben prüfen

   Eine Aufgabe, die keine Version je besteht, ist laut Anthropic häufiger eine kaputte Aufgabe als ein unfähiger Agent. Reparieren Sie sie, bevor sie den Vergleich verzerrt.

Die Ergebnisse Fall für Fall lesen

Vergleichen Sie die Versionen pro Aufgabe, nicht nur in Summe: welche Aufgaben der Kandidat neu besteht, welche er neu nicht besteht und welche unverändert sind. Eine höhere Gesamtzahl kann eine Regression bei einem Aufgabentyp verdecken. Lesen Sie dann die Transkripte jedes neuen Fehlschlags. Anthropics Teams nehmen Werte nicht für bare Münze, bevor jemand Transkripte gelesen hat, weil ein Fehlschlag ebenso leicht von Aufgabe, Bewertung oder Harness kommen kann wie vom Modell.

Ein hypothetisches Ergebnis: Bei 40 Regressionsaufgaben mit je drei Durchläufen hält der Kandidat 37 und scheitert neu an 3, allesamt Datenbankmigrationen. In der Capability-Suite besteht er neu 6 von 25 Aufgaben, und die Kosten pro bestandener Aufgabe sind etwa gleich. Die Transkripte zeigen, dass er bereits gemergte Migrationen umschreibt, was die Anweisungsdatei in einer Zeile verbietet, die auf die Eigenheiten des alten Modells zugeschnitten war, also genau die Art Eintrag, die laut Claude-Code-Dokumentation nach größeren Modellwechseln überprüft werden sollte. Das Team präzisiert diese Anweisung. Damit ändert sich das Harness, also lässt es die vollständigen Regressions-, Capability- und Verhaltens-Suites mit dieser endgültigen Konfiguration erneut laufen und testet die aktuelle Version unter denselben Anweisungen, um zu sehen, wie viel der Verbesserung auf das Modell entfällt. Erst dann wird der Kandidat zum Standard, während die alte Version für ein Rollback fixiert bleibt.

Vom Ergebnis zum neuen Standard

• Vereinbaren Sie vor dem Lauf, was ein bedeutsamer Unterschied ist und was das Upgrade blockieren würde, und akzeptieren Sie nicht eindeutig als mögliches Ergebnis.
• Stellen Sie zuerst eine freiwillige Gruppe um, dann den Standard, und halten Sie die vorherige Version für ein Rollback fixiert und zugelassen.
• Dokumentieren Sie die Entscheidung mit Stand der Suite, Tool-Version, Modell-ID und Einstellungen, damit das nächste Upgrade von einer bekannten Ausgangslage startet.
• Halten Sie die Suite lebendig: Ergänzen Sie Aufgaben aus neuen Fehlschlägen, verschieben Sie Capability-Aufgaben, die nun zuverlässig bestehen, in die Regressions-Suite, und ersetzen Sie Aufgaben, denen das Repository entwachsen ist.

Evaluierungen auf Ihren RepositoriesEinen fairen Pilot für Coding-Agenten planen