Harness Lens révèle la structure des agents de code

Ce que montre réellement Harness Lens

Ce qui retient l’attention n’est pas une énième vitrine de modèles, mais la tentative de mettre en ordre une couche qui reste habituellement cachée derrière l’interface d’un agent de code. Dans son README et son dépôt Hugging Face, Harness Lens est présenté comme un outil interactif d’analyse de systèmes de harness : Codex, OpenCode, pi, Qwen Code et Claude Code.

Il est possible de comparer simultanément deux à quatre environnements. L’interface aligne les prompts système, les modes et les instructions de compactage, tout en indiquant le nombre de tokens, les recouvrements d’outils et les différences de capacités. Une taxonomie distincte couvre les formats d’édition, la gestion du contexte, les sous-agents, les permissions, les instructions de projet, l’extensibilité et les intégrations de fournisseurs.

Il ne s’agit pas d’un visualiseur de poids, de cartes d’attention ou d’activations. Harness Lens expose l’architecture du produit agent autour du modèle : ce qu’il est autorisé à utiliser, sa manière de modifier les fichiers, ce qu’il reçoit dans le contexte système et la façon dont il compresse l’historique. Cette couche explique souvent mieux qu’un beau schéma de réseau neuronal pourquoi deux agents utilisant le même modèle se comportent différemment.

Le projet applique aussi une discipline à la provenance des données. Les documents disponibles décrivent l’extraction de prompts depuis des révisions épinglées, la vérification des références aux lignes sources et une validation stricte du schéma comme de la taxonomie. Les commandes extract, verify et validate concernent l’intégrité des données, non la qualité de résolution des tâches.

Il serait donc erroné de considérer Harness Lens comme une suite de benchmarks automatisée. Au 7 novembre 2026, les sources accessibles ne fournissent aucun résultat standardisé sur la précision, la latence, le coût, SWE-bench ou le taux de réussite de l’outil lui-même. C’est une couche d’observabilité comparative et de documentation, pas un classement.

Pourquoi comparer le harness et pas seulement le modèle

La conclusion pratique est simple : le nom du modèle ne suffit plus à évaluer un agent de code. Le prompt système, l’ensemble d’outils, les permissions d’action et la stratégie de compactage peuvent modifier le résultat avant même de se demander quelle intelligence de base est la « meilleure ».

J’utiliserais une telle carte comme point de départ d’un audit, et non comme verdict définitif. Elle permet d’abord de repérer les différences de permissions, de protocole d’édition et de traitement des instructions de projet ; ces différences peuvent ensuite devenir des scénarios de test vérifiables. Les développeurs y gagnent lorsqu’ils cherchent la cause d’un comportement plutôt qu’un simple score global.

La limite est tout aussi nette : une excellente traçabilité des sources ne prouve pas l’efficacité d’un agent. Un prompt épinglé peut être vérifié caractère par caractère, sans que cela démontre que le harness est plus rapide, moins coûteux ou plus fiable dans un vrai dépôt. La question ouverte devient donc plus précise : quelles différences d’architecture de harness produisent réellement un effet mesurable ?

Pydantic Monty montre comment exécuter en sécurité du code généré par un LLM sans conteneurs. Il complète Harness Lens, où le contrôle de l’environnement d’exécution compte autant que les essais de modèles.