Claude Code a écrit le moteur de recherche en 3 jours, mais l'équipe Jmix a mis 3 semaines à adopter le code

Les agents écrivent du code vite, mais un humain doit toujours le lire, le comprendre et en assumer la responsabilité. L'équipe de la plateforme open source Jmix en témoigne à partir de sa propre expérience. Elle a écrit en trois jours, avec Claude Code, une nouvelle recherche et un nouvel index pour l'assistant IA. Pour que quelqu'un dans l'équipe soit prêt à répondre du résultat, il a fallu près de trois semaines.

Deux chronomètres au lieu d'un

Avant de répondre, l'assistant cherche lui-même des fragments de documentation dans une base vectorielle. L'équipe y a ajouté des fiches de classes tirées de la Javadoc et découpé la documentation en exemples courts et complets. La qualité est vérifiée par un circuit d'évaluation : 74 questions de contrôle, dont les réponses sont notées par un modèle-juge.

La première version du code a été écrite par Claude Fable 5, et GPT-5.6 Sol a revérifié indépendamment certains morceaux. Le résultat : un diff de 122 fichiers et près de 15 000 lignes. Les auteurs tablaient d'emblée sur deux à trois jours de revue. Ils voyaient chaque modification, et ils pouvaient interroger l'agent sur n'importe quelle décision. Mais parcourir un diff et le comprendre assez bien pour en répondre sans l'agent, ce sont deux choses différentes.

L'équipe décrit cela comme deux chronomètres. Le premier tourne jusqu'à l'obtention d'un code qui fonctionne, et il s'est arrêté au bout de trois jours. Le second tourne jusqu'à ce qu'un membre de l'équipe soit capable de réparer le système de mémoire.

Les auteurs appellent ce moment l'« adoption du code » (code adoption) ; au fond, c'est de l'ownership. Voici les signes : la personne suit le chemin des données de l'entrée au résultat, explique les invariants, prédit ce qu'une modification va toucher et change un contrat en sachant ce qu'il faudra revérifier. Un build au vert ne garantit rien de tout cela, car il ne répond qu'aux questions posées à l'avance.

Par exemple : quelqu'un a-t-il vérifié que les anciens fragments restent en place si une panne survient au milieu d'une réindexation ?

Où sont parties les trois semaines

La vitesse de lecture n'explique qu'une partie du délai. Selon SmartBear et Cisco, il convient de relire 200–400 lignes en 60–90 minutes par session. Sur les 15 000 lignes, environ 3 000 sont des fixtures HTML, qu'il n'est pas nécessaire de lire. Il en reste à peu près 12 000, soit 30 sessions et 30–45 heures de lecture. Cela représente environ une semaine de travail, et les tests se lisent plus vite. Les auteurs reconnaissent que l'estimation est grossière et que l'étude a près de vingt ans.

Trois choses ont absorbé le reste. D'abord, l'agent modifiait le code « au passage ». Le troisième jour de la revue, la prise en charge de plusieurs versions de Jmix avait disparu du code.

L'agent avait changé le format de réponse de /api/search dès le premier jour : il a fallu rétablir l'ancien contrat, et le nouveau format a déménagé vers /api/v2/search. Il a aussi fallu retirer du dépôt des captures d'écran et des exports de 3,5 Mo, ainsi que des logs Playwright. Une série de commits « Restore …

as in main » a duré près d'une semaine. Ensuite, l'agent explique avec la même assurance des choses justes et des choses fausses ; ses explications devaient donc être confrontées au code et confirmées par des tests. Enfin, des corrections tardives sont arrivées : le seuil de validation est devenu un champ distinct de l'exécution, les règles du juge ont été durcies, et la forme abrégée de la requête DataManager a été ajoutée à la référence.

Tout ce que l'équipe avait déjà compris sur la signification du score a dû être revérifié.

L'historique des commits donne : 44 commits pendant les trois premiers jours, puis 53 en une semaine et demie d'analyse, et encore 47 sur les neuf derniers jours.

Le contexte des données sectorielles est le suivant. Selon DORA 2024, une hausse de 25% de l'usage de l'IA est associée à une meilleure documentation et à une revue plus rapide, mais le débit de livraison a reculé d'environ 1,5% et la stabilité de 7,2%. Il s'agit d'une corrélation issue d'une enquête, pas d'une expérience.

Dans DORA 2025, le lien avec le débit est devenu positif, tandis que celui avec la stabilité est resté négatif. Dans l'expérience de METR, des développeurs expérimentés équipés d'IA passaient 19% de temps en plus sur leurs tâches, tout en estimant avoir gagné 20% de vitesse. Les outils utilisés dataient du début de 2025, et une nouvelle mesure en février 2026 s'est révélée statistiquement peu fiable.

Ce que l'équipe fait maintenant

L'idée centrale consiste à distinguer trois frontières. La livraison détermine ce qui entre en bloc dans main. L'itération agentique amène le travail à un état stable, qu'on peut lancer et vérifier. Le point d'adoption du code indique quelle partie un humain maintient déjà lui-même. Auparavant, l'équipe avait fusionné les trois dans une seule grosse pull request, et le second chronomètre ne démarrait qu'après le premier.

Désormais, le travail est découpé en trois tranches : le cycle de vie du corpus, la recherche avec son API, et le circuit d'évaluation. Chaque tranche est vérifiée et acceptée par un humain avant la suivante. Les tranches avancent sous forme de branches empilées, et une seule pull request finale part vers main, où l'on ne vérifie que les points de jonction. Par exemple : après une réindexation ratée, la recherche renvoie-t-elle toujours l'ancienne génération de données ?

Six pratiques : décrire le contrat de l'ensemble du système avant la première session, découper le travail en états stables et laisser une note entre les sessions, demander à l'agent une confirmation plutôt qu'un rapport, confier la vérification à un agent distinct avec un contexte neuf, impliquer un humain après chaque tranche, et terminer par une recette d'intégration complète. Des idées proches figurent dans les expériences d'Anthropic sur les tâches longues des agents et dans les recommandations de Claude Code sur la vérification du diff par un sous-agent.

Limites

Les auteurs le disent honnêtement : il ne s'agit pas encore d'un règlement, et ils ne disposent d'aucune mesure comparable aux trois semaines de cette branche. Reste une question : le vérificateur distinct a-t-il aidé par son regard neuf, ou simplement parce que c'était un autre modèle ? La tranche acceptée n'est pas non plus figée : il a fallu revoir la signification du score le dernier jour. La conclusion pratique pour les équipes est simple : ne comptez pas seulement le temps de génération du code, mais aussi le temps nécessaire pour qu'apparaisse une personne prête à en répondre, et intégrez des points de validation au plan avant la première session de l'agent.