HarnessDev pose une question plus opérationnelle que la plupart des benchmarks d’agents : un modèle de langage peut-il concevoir le harnais logiciel qui entoure un autre agent, puis améliorer ce harnais au fil du temps ? Les auteurs évaluent une infrastructure exécutable plutôt que seulement les réponses finales. Le résultat met en évidence un risque concret : une nouvelle version peut progresser sur les tâches visibles tout en régressant sur des tâches cachées ou avec un autre modèle d’exécution.
Cette distinction compte parce que le harnais concentre une grande partie des mécanismes de production : décomposition, appels d’outils, état, reprises, vérification et conditions d’arrêt. Si un agent modifie lui-même cette couche, l’évaluation du modèle ne suffit plus. Le harnais devient un artefact logiciel versionné qui doit suivre une discipline de mise en production.
Le benchmark évalue l’infrastructure, pas seulement les réponses
Le préprint HarnessDev, soumis le 1er septembre, comporte deux volets. Dans la phase de création, six modèles créateurs produisent des harnais dans quatre domaines et cinq benchmarks aval, pour 2 207 instances uniques. Le point de départ volontairement faible ne contient ni boucle d’agent, ni logique de décomposition, ni politique d’outils, ni gestion du contexte, ni état persistant, ni vérificateur, ni reprise, ni règle d’arrêt. Toute performance non nulle dépend donc des mécanismes ajoutés par le modèle créateur.
Les harnais générés sont exécutables, mais leur qualité varie selon le domaine. Les auteurs rapportent qu’ils restent derrière des références humaines matures pour le code et la recherche, tandis que certaines tâches de rédaction et d’expérimentation en apprentissage automatique atteignent ou dépassent les références retenues.
Le transfert est le point faible
La phase d’évolution est plus instructive pour la production. Le projet suit 73 versions officielles réparties sur neuf trajectoires d’optimisation. Selon la page du projet, l’ensemble utilisé pour guider les changements et l’ensemble caché ne sont d’accord que sur 34 transitions sur 64, soit 53,1 %. Deux seulement des neuf versions déclarées finales sont aussi optimales sur l’ensemble caché.
Le classement peut également changer lorsque le modèle exécuteur change. Dans une comparaison publiée, l’utilisation d’un modèle Gemini fixe rend négatives trois trajectoires sur quatre. L’exécuteur doit donc être traité comme une partie du système évalué et non comme un détail interchangeable.
Les changements de harnais doivent suivre une discipline de livraison
La conclusion la plus solide n’est pas que les agents savent désormais construire de meilleurs agents de manière autonome. Les résultats sont trop hétérogènes pour cela. Ils montrent plutôt que l’auto-modification de l’infrastructure crée un problème classique de gestion des versions.
Chaque version devrait avoir une identité immuable, un ensemble de validation distinct des tâches qui ont motivé le changement, un enregistrement du modèle exécuteur et une possibilité de retour arrière. La promotion devrait dépendre de seuils explicites sur la qualité, le coût, la latence et les comportements sensibles pour la sécurité.
Un mécanisme présent dans le code peut être absent à l’exécution
Le projet vérifie aussi si les composants générés sont réellement utilisés. Sur 108 instances de composants, 18 ne sont jamais observées pendant l’exécution, toutes liées à l’état ou à la mémoire. Onze artefacts définissent une classe d’état, mais un seul expose une sauvegarde, un seul met en œuvre des points de contrôle périodiques, et le projet ne relève aucun événement de point de contrôle sur 26 679 trajectoires.
C’est un signal important pour l’assurance. L’inspection statique peut confirmer qu’un contrôle existe sans prouver qu’il se déclenche. La même distinction vaut pour les reprises, vérificateurs, mémoires, contrôles d’autorisation et garde-fous.
Ce que les équipes peuvent en retenir
HarnessDev reste un préprint. Les modèles, benchmarks et systèmes de référence sont sélectifs, et l’analyse cachée après gel de la phase d’évolution est surtout centrée sur le génie logiciel. Les résultats ne prouvent donc pas de manière générale que l’évolution autonome des harnais est dangereuse ou inefficace.
Ils proposent néanmoins une méthode de validation utile. Si un agent peut modifier sa propre orchestration, l’unité de déploiement contrôlée n’est plus seulement le modèle. Elle comprend le modèle, le harnais, l’exécuteur, la politique d’outils, le système d’état et le processus de promotion.
La bonne question devient alors : « cette version précise du système s’est-elle améliorée sous validation indépendante, avec des contrôles réellement actifs à l’exécution ? » Pour les équipes qui explorent les agents auto-améliorants, c’est un critère de livraison beaucoup plus solide.