Les agents de code ont leur propre couche d'outillage : mémoire, hygiène des tests et outils MCP épinglés

Threadnote vend le transport de contexte pour agents de code. La société a publié le résultat le 5 octobre pour sa version 5.1.0-beta.2. Sur cinq dépôts publics, elle rapporte 65,62 % de tokens fournisseur en moins par tâche vérifiée sur l'ensemble du cycle de vie. Elle rapporte aussi 46,14 % de temps de cycle en moins par rapport à une base qui ne lit que les fichiers.

La branche fichiers seuls a passé la vérification sur 4 tâches sur 5. Threadnote a passé 5 sur 5.

L'entreprise reconnaît elle-même qu'il s'agit d'une petite étude sur un seul modèle, pas d'une évaluation indépendante. Les dix tentatives de reprise ont utilisé OpenAI gpt-5.6-luna avec la même configuration scellée. Chaque condition a eu une tentative, sans nouvel essai. La seconde condition combinait une passation générée par le produit avec une requête obligatoire au graphe de code. Les chiffres ne séparent donc pas la mémoire de la recherche dans le graphe.

Pourquoi c'est important : si l'effet tient, relire le code source cesse de dominer le coût de finition d'une tâche. Cela change les budgets des équipes qui font tourner des agents sur des dépôts anciens. Cela ne change pas ce que prouve un test réussi. L'étude reste une mesure de l'éditeur lui-même.

Petits modèles, grandes annonces, tests appariés

Jeff-Code est un fork de l'agent de code Pi. Il place un modèle de décision de 800 000 000 de paramètres devant Qwen 3.8-27B, soit 27 000 000 000 de paramètres. Le petit modèle fait deux appels par tour de Qwen, environ 0,2 seconde chacun. L'un demande s'il peut franchir seul l'étape d'information suivante. L'autre demande si Qwen a besoin de réfléchir fort. La réflexion restait coupée tant que la probabilité d'en avoir besoin n'atteignait pas 0,6. Environ trois quarts des tours de Qwen ont tourné sans elle.

Le dépôt rapporte 1 242 tâches appariées. Le taux de réussite ressort à 62,4 % contre 62,8 % pour Qwen seul. Soit une différence appariée de moins 0,2 point, avec un intervalle à 95 % de moins 2,6 à plus 2,1. Le temps moyen par tâche valait 0,68 fois la base. Le temps total sur toutes les tâches valait 0,86 fois, parce que sur environ 5 % des tâches Jeff-Code a tourné plus de 30 minutes de plus que Qwen seul.

Deux réglages ne tiennent pas. Couper la réflexion à chaque tour allait plus vite mais coûtait 7,6 points (de moins 10,6 à moins 4,5). Un Jeff moins prudent, au seuil de 0,7, perdait 4,5 points. Les gains de vitesse disparaissaient aussi sur Terminal-Bench 2.0 (0,96 fois) et SkillsBench (0,91 fois).

Le harnais devient objet d'étude et de mesure

Reika est un CLI d'agent de code conçu autour de petits modèles locaux. Il publie ses propres constats plutôt qu'un tableau de benchmarks. Une réécriture en milieu de contexte a retraité 8 453 tokens de prompt, ce qu'il chiffre à 7,9 minutes de préremplissage. Un ajout dans la même session a coûté 25 tokens et 3,5 secondes. Lors des tests, les modèles de 9 000 000 000 à 35 000 000 000 de paramètres ont géré le plus sûrement les tâches multi-fichiers. Ceux de 7 000 000 000 à 9 000 000 000 de paramètres s'en sortaient sur des tâches simples et bien cadrées, et les modèles sous 7 000 000 000 de paramètres allaient rarement loin.

Un article arXiv soumis le 15 juillet donne au domaine un cadre plus large. Paul Barbaste et trois coauteurs ont audité onze harnais de code en production. On y trouve Claude Code, Codex CLI, Gemini CLI, OpenHands, Aider, Hermes, Pi, OpenCode et OpenClaw, plus un méta-harnais nommé Omnigent. Ils ont parcouru environ quatre millions de lignes de Python, TypeScript et Rust. Ils n'ont trouvé aucun runtime d'agent qui importe un framework agentique généraliste. Aucun ne récupère du code par plongements vectoriels. Les Skills devançaient le MCP en adoption, 9 systèmes sur 11 contre 8 sur 11.

Cela compte pour quiconque achète ou construit ces outils. La différenciation se joue dans la boucle, la gestion du contexte et les contrôles de sécurité. Elle ne se joue pas dans un framework commun que tout le monde licencie. L'article a aussi suivi les mêmes harnais sur un trimestre. Il décrit une convergence qui vire à l'imitation, la politique de comportement passant du texte du prompt à la configuration.

Sédiments de tests et coût du vert

Ian Maurer, dans un texte du 5 octobre, soutient que le vrai problème de tests pour les agents est ce qu'ils laissent derrière eux. Il cite l'équipe OpenClaw, qui rapporte avoir supprimé environ 400 000 lignes de ses propres tests sans grand changement de couverture. Il appelle ces résidus des sédiments de tests. Ils ralentissent les builds, cassent lors de refactorisations qui préservent le comportement, et peuvent figer un comportement erroné.

Sa correction : écrire d'abord des tests de l'extérieur vers l'intérieur, dans la langue de l'utilisateur. Ne les garder que s'ils énoncent un comportement, couvrent un cas limite ou vérifient un contrat dont d'autres dépendent. La couverture, écrit-il, est une carte de ce qui n'est pas testé, jamais une preuve de ce qui l'est.

Les tests de mutation posent la meilleure question : si ce code cassait, un test échouerait-il ?

Le risque de fond est que les agents produisent un travail qui a l'air vérifié. Groundrun rapporte une exécution de 29,7 heures le 5 octobre. Claude Code avec Claude Opus 5.5 a implémenté et validé six méthodes de mise à jour over-the-air pour un appareil Matter sur une carte ESP32-H2, via un banc avec matériel dans la boucle. L'exécution a aussi révélé un bug dans le code Matter. Groundrun note que l'OTA est obligatoire en pratique sous le Cyber Resilience Act de l'UE. Il note aussi qu'une mise à jour ratée peut rendre un appareil inutilisable.

L'approbation n'est pas l'intégrité

MCP-pin, publié sur GitHub le 5 octobre, vise un trou plus étroit. Quand vous approuvez un serveur MCP, le client affiche une fois ses descriptions d'outils. Le serveur peut ensuite servir d'autres descriptions, et la plupart des clients ne redemandent jamais, affirme le projet. La spécification MCP n'exige aucun contrôle d'intégrité.

L'outil est un proxy local qui épingle des empreintes et bloque les dérives, avec un journal public en ajout seul. Visual Studio est l'exception nommée. Depuis la version 18.7 en juin 2026, il compare au démarrage les outils, prompts, ressources et instructions d'un serveur avec la dernière version de confiance.

Le serveur peut servir un jeu de définitions d'outils le lundi et un autre le mardi.

C'est la formulation du projet lui-même, et c'est le bon modèle de menace. Une description d'outil modifiée atteint le modèle avec la même force qu'un prompt système modifié. On ignore si d'autres clients adopteront le même contrôle.

Une commande, un checkout, une revue

Rivet, d'Agilno, prend l'approche inverse de l'autonomie : il la verrouille. L'outil est encore en alpha et s'installe depuis npm sous le nom @agilno-tech/rivet. Il exécute une tâche dans un checkout Git isolé, lance les vérifications du projet, puis propose un menu. Le menu permet de relire le diff, d'appliquer en local ou de préparer une livraison en pull request. La publication demande une approbation séparée. Il exige Node.js 22 ou 24 et Git sur macOS ou Linux. Il fonctionne avec un Claude Code ou un Codex CLI authentifié.

Ostoyae est un exécuteur de graphe sans dépendance npm, et il coupe autrement. Les jobs forment un DAG qui grandit pendant l'exécution. Quand un agent bloque parce qu'une dépendance n'existe pas, ce manque devient un nouveau nœud. Chaque job tourne dans son propre worktree git. Un travail ne compte qu'une fois sa commande de vérification passée sur un checkout neuf.

Il importe des issues GitHub et lance un agent par job. Il mélange Claude Code, Codex, Hermes et Grok sur le même tableau.

Les deux supposent qu'il existe une vérification que l'agent ne peut pas contourner par la parole. C'est la même hypothèse derrière les tâches vérifiées de Threadnote et derrière le banc matériel de Groundrun. Les outils diffèrent sur la place de l'humain, pas sur le fait que la vérification soit le point central.

Deux pièces plus petites complètent le tableau. Tmux-agent-status, publié le 5 octobre, n'affiche rien pendant que les agents travaillent. Il montre un petit marqueur quand l'un est bloqué sur une permission ou a terminé. Le blog PixLab a rapporté le 5 octobre plus de 20 étudiants de dernière année qu'il a observés. Les outils de code utilisés étaient ChatGPT ou les modèles GLM de Z.ai. Un junior de niveau master demandait sans cesse à un chatbot comment récupérer un élément HTML par son ID. C'est une observation tirée du programme de stage d'une entreprise, pas une enquête.

Rien de tout cela ne tranche si les agents rendent les développeurs meilleurs ou seulement plus rapides à approuver. Les chiffres qui existent sont surtout produits par les éditeurs, sur des tâches appariées, avec des intervalles assez larges pour masquer de petits effets.

L'article sur les harnais fait exception : tourné vers les pairs, fondé sur le code source, et direct sur la jeunesse de la discipline.