Comment évaluer un agent au-delà des tests réussis

Un agent de programmation qui réussit les tests visibles d'une tâche peut tout de même être dangereux à fusionner. Il peut supprimer un ancien comportement absent des cas de test, modifier un fichier généré plutôt que sa source, passer quarante minutes à explorer le mauvais sous-système ou produire un correctif qui n'a de sens que dans le dépôt connu de ses concepteurs. Une évaluation sérieuse doit détecter ces résultats au lieu de féliciter l'agent pour des voyants au vert.

L'unité pertinente n'est pas l'exécution d'un test. C'est une tentative complète avec un état initial du dépôt, une instruction, un budget, une trajectoire observable, un correctif et plusieurs jugements indépendants. Considérer toute la tentative comme une preuve change ce que l'équipe mesure et les défauts qu'elle corrige.

Comment définir une tâche pour un agent de programmation ?

Une tâche d'agent de programmation exige un commit de départ figé, une demande réaliste, un environnement d'exécution explicite et des contrôles d'acceptation cachés. Sans ces quatre éléments, deux exécutions censées traiter le même sujet peuvent résoudre des problèmes différents.

Partez d'un travail semblable à celui de votre vraie file d'attente. La tâche peut concerner un bug, une petite fonctionnalité, la migration d'une dépendance ou un changement d'exploitation. Conservez l'ambiguïté qu'une personne compétente résoudrait en lisant le dépôt, mais retirez celle à laquelle seul un ancien salarié pourrait répondre. « Corriger l'arrondi de facture lorsqu'une ligne de crédit suit une ligne taxable » est une demande valable si le code et le comportement existant contiennent la réponse. « Satisfaire la finance » ne l'est pas.

Figez davantage que le commit. Consignez la chaîne d'outils, la politique de cache des dépendances, les variables d'environnement accessibles à l'agent, la politique réseau, les points d'entrée des tests et les limites de ressources. Si l'environnement dérive, le score mêle la qualité de l'agent à la chance du runner. Les images de build doivent avoir des identifiants immuables, et les fixtures doivent être versionnées avec l'évaluateur.

Chaque fiche de tâche doit pouvoir être inspectée. Une spécification compacte peut ressembler à ceci :

{
  "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"]
}

Les contrôles cachés ne constituent pas un piège. Ils empêchent l'agent de s'optimiser directement sur la totalité du corrigé. Gardez certains contrôles comportementaux hors du dépôt et renouvelez-en une partie, car un agent peut déduire beaucoup de choses à partir des noms de tests et des fixtures voisines.

Exécutez chaque tâche plusieurs fois. Le comportement d'un agent varie même lorsque le modèle et le prompt restent identiques. Une réussite chanceuse montre que la tâche est possible. Des tentatives répétées montrent si le système est fiable. Stockez la graine ou les réglages d'échantillonnage quand le fournisseur les expose, sans prétendre qu'ils suppriment toute variation.

Pourquoi les tests réussis ne donnent qu'un seul jugement

Les tests disent si certaines observations correspondent aux attentes. Ils ne prouvent pas que le correctif a le bon périmètre, reste maintenable et sûr, ou respecte les comportements que la suite n'a jamais encodés.

Évaluez la réalisation de la tâche par couches. Lancez d'abord les contrôles visibles que l'agent pouvait exécuter. Lancez ensuite des tests cachés sur les entrées voisines et le cas limite signalé. Puis contrôlez tout le dépôt, avec le lint, la vérification des types, les builds et les tests des paquets dépendants. Enfin, examinez ce que les frameworks de test voient rarement : modifications de fichiers interdits, ajout de dépendances, changement d'API publique, migrations, artefacts générés et suppression suspecte de tests.

Gardez ces jugements séparés au lieu de les réduire immédiatement à un pourcentage. Un correctif qui résout la cible mais casse un paquet indépendant diffère d'un correctif qui ne résout jamais la cible. Les deux bloquent la livraison, mais ils appellent des remèdes distincts. Le premier indique une mauvaise analyse d'impact ou une exploration insuffisante du dépôt. Le second signale une mauvaise mise en œuvre ou une tâche mal comprise.

L'inspection du correctif peut être en partie mécanique. Refusez les modifications hors d'une liste autorisée lorsque la tâche a des limites étroites. Signalez la baisse du nombre d'assertions, les nouveaux tests ignorés, les gestionnaires d'exception trop larges et les snapshots modifiés. Ce sont des motifs de revue, pas des preuves automatiques de triche. Une correction légitime peut modifier un snapshot ou retirer une assertion obsolète. Conservez donc le diff et l'explication de l'agent pour la revue humaine.

Ajoutez une petite grille pour les qualités que les machines ne jugent pas encore avec régularité. Les relecteurs peuvent dire si le correctif suit les abstractions locales, place la validation à la bonne frontière, laisse du code mort ou alourdit la maintenance. Utilisez des choix ancrés tels que « suit un motif déjà présent dans le dépôt » et « crée un mécanisme parallèle ». Des notes vagues de un à cinq dérivent d'un relecteur à l'autre et apprennent peu de choses.

La décision finale doit rester stricte : le comportement demandé, les contrôles de régression et la santé du dépôt doivent tous passer. Le dossier de diagnostic doit rester riche. Beaucoup d'équipes abîment leur évaluation en ne conservant que le vert ou le rouge, puis ne disposent d'aucune preuve quand une nouvelle version de l'agent déplace le score.

Les comportements déjà corrigés appartiennent à la suite

Une évaluation d'agent de programmation doit rejouer les bugs que votre équipe a déjà payé pour comprendre. Ces cas exposent beaucoup mieux le risque de régression qu'une collection composée uniquement de tickets récents et propres.

Après la correction d'un bug de production, conservez trois éléments : l'état du dépôt avant le correctif, le symptôme visible par l'utilisateur et un oracle qui distingue le bon comportement. Cet oracle peut être un test ciblé, une requête et sa réponse enregistrées, une transition d'état en base de données ou une commande à la sortie normalisée. Retirez les secrets et les horodatages instables avant de stocker du trafic.

Il existe deux questions de régression distinctes. « L'agent peut-il corriger un ancien bug depuis l'état cassé ? » mesure la capacité de réparation. « Un nouveau correctif pour une autre tâche réintroduit-il cet ancien bug ? » mesure la préservation du comportement. Les équipes confondent souvent les deux et obtiennent un benchmark qui récompense la correction sans rien dire sur les dégâts collatéraux.

Constituez une banque cumulative de comportements à partir des incidents clos et des découvertes difficiles faites en revue. Étiquetez chaque cas par sous-système, mécanisme de panne et conséquence, puis choisissez des cas pertinents pour chaque tâche avec un petit échantillon de tout le dépôt. L'ensemble pertinent détecte la casse proche. L'échantillon trouve des couplages inattendus, par exemple un formateur de facturation qui modifie un export parce que les deux utilisent la même fonction d'arrondi.

Ne testez pas seulement la branche par défaut actuelle sur cette banque. Exécutez l'exact correctif de l'agent sur sa base figée, car des changements humains ultérieurs peuvent masquer ou créer des échecs. Si un test échoue sur la base et sur le correctif, classez-le comme bruit préexistant. S'il passe sur la base et échoue après le correctif, la tentative a causé une régression.

Les contrôles instables doivent être placés en quarantaine avec un responsable et des preuves, pas relancés en silence jusqu'au vert. Enregistrez chaque exécution. Une règle de nouvelle tentative peut dire si le correctif est publiable selon votre CI actuelle. Les résultats bruts révèlent le non-déterminisme de l'environnement d'évaluation ou du produit. Mélanger les deux améliore l'apparence de l'agent sans rendre son correctif plus sûr.

Une banque de comportements coûte de plus en plus cher, alors organisez-la par niveaux. Exécutez les cas proches et rapides à chaque tentative, une répétition plus large avant d'accepter une version candidate, puis les cas système les plus lents selon un calendrier. La couverture doit progresser : un cas ne sort que si le comportement n'existe plus ou si un oracle plus fort le remplace.

Le coût a besoin d'un dénominateur et d'un registre d'échecs

Le coût par tâche réussie est plus utile que la dépense en tokens par exécution. Les tentatives peu coûteuses qui échouent ou obligent une personne à réparer le correctif ne constituent pas un travail bon marché.

Consignez les frais du modèle en entrée et en sortie, les tokens mis en cache, le calcul des outils, le temps de sandbox et tout service externe payant appelé pendant l'exécution. Gardez le temps de revue technique dans un champ séparé au lieu de lui inventer un montant. Vous pourrez toujours comparer les minutes médianes de revue selon les versions et les classes de tâches.

Examinez le coût sous au moins quatre angles :

• le coût par tentative révèle les explorations sans fin ;
• le coût par tâche acceptée inclut les tentatives ratées ;
• le coût par classe de tâche et par dépôt empêche le travail facile de cacher le travail cher ;
• le coût des exécutions perdues par catégorie d'échec indique les défauts d'orchestration réparables.

Présentez des distributions, pas seulement des moyennes. La médiane décrit une exécution ordinaire, tandis que le 90e ou le 95e percentile révèle les agents qui parcourent les mêmes fichiers en boucle, reconstruisent sans cesse ou chargent le dépôt entier dans le contexte. Un budget ferme doit arrêter ces exécutions et les classer comme épuisement de budget, pas comme échec ordinaire de la tâche.

Les caches compliquent les comparaisons. Un cache de dépendances chaud peut correspondre à un worker CI interne, mais un cache de prompt chaud peut rendre les tâches répétées artificiellement peu coûteuses. Choisissez la condition qui ressemble à la production, nommez-la et incluez une tranche à cache froid. Ne comparez jamais une version sur des tâches chaudes avec une autre sur des tâches nouvellement créées.

Le registre d'échecs compte parce que les économies viennent de changements différents. Si les erreurs de mise en place de l'environnement absorbent l'essentiel des dépenses perdues, changer de modèle n'aidera pas. Si l'agent lit sans cesse du code vendorisé, améliorez les consignes du dépôt ou les filtres des outils. S'il atteint un correctif juste après de longs cycles de test, améliorez la sélection des tests et les builds incrémentaux.

Les limites de coût changent aussi le comportement. Avec un plafond serré, l'agent peut appliquer la première correction plausible et sauter la vérification large. Évaluez la qualité avec plusieurs budgets avant de déclarer une configuration efficace. Le bon point de fonctionnement se trouve là où une dépense supplémentaire n'apporte plus d'augmentation sensible des tâches acceptées ni de baisse des régressions graves.

La latence doit suivre le chemin critique

Mesurez le temps écoulé tel que l'utilisateur le vit, puis découpez-le en phases sur lesquelles l'équipe peut agir. Une durée unique ne dit pas si le retard vient du raisonnement du modèle, du démarrage d'un outil, de l'installation des dépendances, des tests ou d'un runner encombré.

Enregistrez les horodatages de l'entrée en file, de la disponibilité de la sandbox, de la première réponse du modèle, de chaque appel d'outil, du premier correctif, du début de la vérification et du résultat final. Déduisez-en le temps en file, la préparation, le délai avant première modification, le travail actif de l'agent, la vérification et le total. Séparez latence du modèle et durée des commandes.

Le délai avant première modification est particulièrement instructif. Un délai très court peut indiquer que l'agent a deviné avant de lire les conventions locales. Un délai très long peut signaler une errance dans des répertoires sans rapport. Aucun n'est forcément mauvais, alors mettez-le en relation avec l'acceptation du correctif et les fichiers consultés.

La CI doit aussi mesurer la latence du chemin critique au lieu d'additionner le travail parallèle. Si les tests unitaires et l'analyse statique tournent ensemble pendant huit minutes, l'utilisateur a attendu huit minutes, pas seize. Les ressources peuvent tout de même totaliser seize minutes de worker, ce qui appartient au registre de coût.

Définissez des objectifs par classe de tâche. Une correction de configuration dans un fichier et un changement de schéma entre plusieurs paquets ne doivent pas partager le même seuil. Comparez l'agent au flux humain qu'il remplace ou assiste : délai jusqu'à un correctif révisable, délai jusqu'à une fusion acceptée et temps du relecteur. L'agent peut produire un correctif plus lentement mais finir plus tôt si ses preuves facilitent la revue. Il peut aussi être rapide et consommer un après-midi de corrections.

Les expirations méritent un résultat propre. Ne notez pas une exécution expirée comme un correctif incorrect. Conservez son dernier état cohérent, sa trace d'outils et son budget consommé. Des expirations répétées dans un dépôt révèlent souvent un problème d'évaluateur, comme une commande de test qui attend un service absent, plutôt qu'une faible génération de code.

Exécutez le benchmark de latence sur des workers contrôlés, puis observez séparément la CI partagée. Les exécutions contrôlées permettent de comparer les modèles. Les exécutions partagées montrent les besoins de capacité et l'expérience réelle des développeurs. Les fusionner produit une mesure bruitée qui ne répond à aucune question.

Les dépôts inconnus révèlent d'autres échecs

Un agent évalué seulement sur des dépôts connus de ses concepteurs hérite de leurs hypothèses. Un code que vous n'avez pas écrit vérifie si l'agent découvre les règles au lieu de les recevoir par la conception du benchmark.

Les échecs fréquents commencent avant la génération de code. L'agent choisit la mauvaise commande de test, prend du code généré pour la source, manque un second langage dans le build, ignore une convention locale de correctif ou modifie un module partagé sans trouver ses consommateurs. Ces tentatives peuvent compiler et réussir un test ciblé. Elles échouent parce que l'agent a dressé une mauvaise carte du système.

Choisissez des dépôts externes ou récemment acquis avec une autorisation légale et un build reproductible. Figez-les avant que les auteurs des tâches ne les explorent en profondeur. Demandez à un groupe de préparer l'environnement et à un autre de créer des tâches depuis l'historique réel des tickets ou des défauts observés. Si la même personne étudie le code, écrit des indices détaillés et juge le résultat, sa compréhension fuit dans l'instruction.

Mesurez le comportement de découverte sans imposer une séquence idéale. Les signaux utiles comprennent la lecture des consignes du dépôt, l'identification des points d'entrée du build, la recherche des appels avant de modifier un symbole partagé, la détection de plusieurs implémentations et la vérification du diff avant de terminer. Ne donnez pas de points selon le volume d'appels d'outils. Dix recherches peuvent traduire de la prudence ou de la confusion.

Incluez des dépôts aux caractéristiques gênantes mais réelles : plusieurs langages, générateurs maison, peu de tests, grosses fixtures, scripts propres à une plateforme et noms de répertoires trompeurs. Ne fabriquez pas de pièges. Vous cherchez à savoir si l'agent gère une histoire accumulée ordinaire, pas s'il résout une énigme conçue par l'évaluateur.

La contamination est difficile à prouver, alors concevez le test pour la limiter. Utilisez du code privé lorsque vous y êtes autorisé, des snapshots récents absents des anciens ensembles d'entraînement et des transformations locales comme le renommage des entités métier. Le renommage ne crée pas un nouveau problème de raisonnement, mais réduit la mémorisation simple. La preuve solide vient d'une performance comparable sur des dépôts connus et réellement inconnus, pas d'une question posée au modèle sur ses souvenirs.

La trajectoire explique les échecs invisibles dans le correctif

Conservez les actions observables de l'agent, car le diff final ne montre ni comment il a trouvé la réponse, ni ce qu'il a ignoré, ni pourquoi il a épuisé son budget. Une trace d'événements compacte rend les échecs reproductibles sans demander le raisonnement privé du modèle.

Pour chaque tour du modèle, gardez la version du prompt, l'identifiant de réponse, les tokens utilisés, la demande d'outil, l'état du résultat, les horodatages et les fichiers ou commandes touchés. Masquez les secrets avant conservation et limitez strictement la taille des sorties de commandes. L'agent peut afficher des valeurs d'environnement ou des données client en déboguant, alors l'accès aux traces doit suivre les mêmes règles que l'accès au code source.

Ne notez pas un texte de raisonnement caché et ne récompensez pas l'agent parce qu'il raconte l'approche attendue. Les fournisseurs exposent des signaux internes différents, et une explication soignée peut cacher de mauvaises décisions. Jugez les actes et les artefacts : il a lu les instructions de build, cherché les appels, modifié un fichier, lancé un contrôle ciblé, vu un échec et révisé son correctif.

Classez le premier mauvais choix décisif. Les symptômes suivants en découlent souvent. Si l'agent modifie un client généré, se bat ensuite contre le générateur puis expire, « expiration » décrit l'état final, pas la bonne réponse technique. La catégorie utile est l'identification de la source de vérité. Les autres peuvent inclure la découverte de l'environnement, l'interprétation de la tâche, le choix des dépendances, l'analyse d'impact, la mise en œuvre et la vérification.

Consignez la récupération autant que l'échec. Un agent qui remarque une hypothèse erronée après un contrôle raté diffère de celui qui répète six fois la même commande. Les mesures utiles de trajectoire comprennent les appels d'outils identiques répétés, le délai entre un contrôle raté et la modification suivante, la part des fichiers consultés hors du sous-système modifié et l'exécution de la vérification finale sur un état propre. Interprétez ces signaux avec le résultat de la tâche. Aucun ne constitue seul un score de qualité.

Les traces révèlent aussi l'interférence du harnais. Un outil peut tronquer précisément l'erreur de compilation qui nomme le défaut, une politique de sandbox peut bloquer une commande normale du dépôt, ou l'orchestration peut déclarer une commande réussie après avoir tué son processus enfant. Séparez les événements de l'évaluateur de ceux de l'agent afin que le responsable de chaque échec soit visible.

La conservation exige une politique réfléchie. Gardez le correctif, les résultats normalisés et les mesures agrégées plus longtemps que la sortie brute des commandes. Lorsque vous supprimez les traces détaillées, conservez les étiquettes d'échec et les versions d'évaluateur pour préserver les comparaisons historiques. Une archive d'évaluation qui accumule discrètement des identifiants et des extraits de production constitue elle-même un contrôle de sécurité raté.

L'évaluateur peut échouer avant l'agent

Un harnais d'évaluation est un logiciel de production. Si son oracle est faux, si sa sandbox laisse fuiter un état ou si sa fixture ne peut pas être construite, le score mesure les défauts de l'évaluateur.

Validez chaque tâche avec deux contrôles. Le contrôle négatif est le commit cassé inchangé et doit échouer sur l'oracle cible. Le contrôle positif est la correction humaine connue et doit réussir les oracles cible et de régression. Une tâche qui échoue à l'un des contrôles reste hors de l'ensemble noté jusqu'à sa réparation.

Testez ensuite l'isolation. Chaque tentative doit recevoir un worktree neuf, un espace de processus propre, une horloge contrôlée lorsque le temps compte et des ressources de service uniques. Une base de données laissée par l'exécution précédente peut faire paraître le correctif suivant juste. Les caches de dépendances partagés peuvent être acceptables, mais ils ne doivent pas contenir de sorties de tâche modifiables.

Le runner doit émettre un résultat compact et stable que la CI peut conserver :

$ ./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

Normalisez les valeurs non déterministes avant comparaison. Triez les enregistrements non ordonnés, remplacez les identifiants générés par des substituts stables et comparez des données structurées plutôt que des captures d'écran ou des logs lorsque c'est possible. Chaque règle de normalisation risque de cacher un défaut, alors conservez l'artefact brut avec l'artefact normalisé.

Versionnez séparément l'évaluateur, la tâche et l'oracle. Lorsqu'un oracle change, gardez assez de métadonnées pour reproduire les anciens scores et les recalculer quand c'est possible. Une version du modèle ne doit pas sembler meilleure simplement parce qu'une fixture a été assouplie dans la même pull request.

Inspectez manuellement un échantillon des échecs d'évaluation. Examinez les erreurs d'infrastructure, les réussites étrangement rapides et les groupes où toutes les versions d'agent échouent de la même façon. Il s'agit souvent de tâches cassées. Les compter comme des échecs du modèle peut sembler prudent, mais dirige le travail technique vers le mauvais système.

Un tableau de bord doit préserver les échecs bloquants

Le tableau de bord doit rendre les décisions de livraison claires sans dissoudre une régression de sécurité ou une corruption de données dans une moyenne. Utilisez des barrières pour les résultats inadmissibles et des mesures pour les compromis.

Commencez par les conditions d'éligibilité : l'agent doit rester dans l'environnement permis, éviter tout accès interdit aux secrets, produire un correctif révisable et réussir tous les oracles de régression grave. Toute violation rend le candidat inéligible, quel que soit son taux moyen de réussite. Définissez la gravité avant la comparaison, sinon les équipes renommeront après coup les échecs gênants.

Pour les candidats éligibles, affichez un tableau par classe de tâche et par dépôt. Incluez le taux de tâches acceptées, le taux de correction de la cible, le taux sans régression, la médiane et la queue du coût par tâche acceptée, la médiane et la queue du temps écoulé, les minutes de revue et les catégories d'échec. Affichez les nombres avec les pourcentages. Trois réussites sur quatre et soixante-quinze sur cent ont le même pourcentage, mais pas le même niveau de confiance.

Évitez un score pondéré unique sauf si un système de sélection automatique l'exige. Les poids cachent des choix de politique et invitent à débattre de l'arithmétique. Une revue de livraison peut plutôt demander si le candidat franchit chaque barrière, améliore les mesures qui comptent pour vous et maintient les régressions sous la tolérance déclarée.

Comparez à des références utiles. Incluez la configuration actuelle de l'agent, un agent minimal avec moins d'outils et un état sans agent où l'évaluateur n'applique aucun correctif. Les résultats humains peuvent aider lorsque les tâches et conditions sont comparables, mais des mainteneurs expérimentés sur leur propre code ne constituent pas la référence universelle d'un agent qui découvre le dépôt.

Découpez les résultats avant de croire l'agrégat. Vérifiez le langage, la taille du dépôt, la qualité des tests, le type de tâche et le franchissement éventuel de frontières entre sous-systèmes. Un candidat peut améliorer le taux global grâce aux petites modifications TypeScript tout en régressant sur les migrations de base de données.

Traitez les décisions contraires des relecteurs comme des données. Si un relecteur accepte un correctif rejeté par le harnais, ou rejette un correctif réussi, exigez un code de raison et inspectez l'oracle. Le relecteur peut se tromper, mais le désaccord permet au tableau de bord d'apprendre.

Le déploiement en CI exige des groupes témoins et des règles d'arrêt

Déployez un agent de programmation dans la CI comme un changement mesuré, avec une fenêtre de comparaison fixe et des conditions d'arrêt. Le lancer immédiatement sur chaque pull request transforme les développeurs en infrastructure d'évaluation gratuite.

Commencez en mode fantôme sur des tâches représentatives. L'agent reçoit le même état du dépôt et la même demande, mais ne peut pas modifier la vraie branche. Comparez son correctif et ses preuves au résultat du travail technique normal. Le mode fantôme révèle les lacunes d'environnement et la charge de revue sans placer ses changements sur le chemin de fusion.

Autorisez ensuite des suggestions pour les classes de tâches à faible conséquence avec revue obligatoire. Gardez aléatoirement un groupe témoin sur la version précédente de l'agent ou le flux normal. Sans contrôle concurrent, un changement dans le mélange des tâches, l'activité des dépôts ou la charge CI peut passer pour une amélioration.

Rédigez les règles d'arrêt avant le déploiement. Suspendez les suggestions automatiques si une régression grave apparaît, si les frontières de secrets sont franchies, si les erreurs d'infrastructure de l'évaluateur dépassent votre tolérance ou si le coût de queue dépasse le budget attribué. Une règle doit nommer la personne autorisée à reprendre et les preuves nécessaires.

Surveillez l'adaptation. Les développeurs peuvent commencer à écrire des tickets anormalement explicites pour l'agent, éviter les tâches qu'il traite mal ou approuver trop vite des formes de correctif familières. Ces changements affectent la performance apparente. Examinez un échantillon de demandes et de commentaires de revue, et maintenez un benchmark stable hors de la file en direct.

Le harnais de parité que nous utilisons chez CodeHero compare le comportement du système réécrit au trafic de production enregistré, car un build propre ne prouve pas que des décennies de cas limites ont survécu à un changement d'architecture. Le même principe vaut pour un agent en CI : conservez le comportement réel sous forme de preuve exécutable, puis jugez chaque correctif face à cette preuve.

La promotion doit être réversible. Gardez l'ancienne configuration disponible, étiquetez chaque correctif créé par un agent avec la version de l'évaluateur et conservez la tentative assez longtemps pour enquêter sur les régressions ultérieures. Si vous ne pouvez pas relier un défaut de production au prompt, à l'état du dépôt, au correctif et aux contrôles qui l'ont accepté, le dossier d'évaluation est incomplet.

Relancez le benchmark après toute modification importante du modèle, du prompt système, des permissions d'outils, de l'assemblage du contexte ou de l'image du runner. Ces composants interagissent, donc une version de modèle seule n'identifie pas le système qui a produit un correctif. Gardez un petit ensemble canari stable pour les comparaisons rapides et actualisez l'ensemble large avec l'évolution du travail réel. Quand des tâches sont retirées, exécutez l'ancien et le nouvel ensemble pendant une période commune afin qu'un changement de difficulté ne ressemble pas à un changement de qualité.

Un agent ne mérite davantage d'autorité qu'après avoir produit régulièrement des correctifs acceptables sur les dépôts où il travaillera, dans un budget que l'équipe sait défendre. Des tests au vert ouvrent la revue. Ils ne la terminent pas.