Tout le monde parle d'Apprentissage Continu comme s'il ne désignait qu'une seule chose : la mise à jour des poids du modèle. Mais il y a une vérité qui dérange dans l'écosystème des agents : la grande majorité des agents en production aujourd'hui exploitent des modèles propriétaires de pointe. Quand on ne possède pas les poids, on ne peut certainement pas les affiner. Pour la plupart des développeurs d'agents, l'apprentissage continu au niveau des poids est hors de question, surtout lorsqu'on travaille à la toute frontière des capacités (pensez à Fable 5 ou GPT 5.6).
Cela ne signifie pas que les agents ne peuvent pas apprendre. Les systèmes agentiques peuvent s'améliorer à trois niveaux — modèle, harnais et contexte [0] — et les deux derniers sont entièrement sous votre contrôle. C'est là que se trouve une opportunité massive (mais souvent négligée) : l'apprentissage au niveau du harnais vous permet d'exploiter les traces de production pour améliorer systématiquement le code, les outils et les instructions qui alimentent chaque instance de votre agent, tandis que l'apprentissage au niveau du contexte vous permet de personnaliser au niveau de l'agent, de l'utilisateur et de l'organisation, afin que votre produit s'améliore à chaque interaction. Faites tout ce qui précède, et vous accumulerez des améliorations que vous pourrez déployer quotidiennement.
Dans le reste de cet article, je vais vous expliquer comment nous avons appliqué l'apprentissage continu à Replit Agent au cours de l'année écoulée, et partager toutes les leçons que nous avons apprises en cours de route.
Évaluer et améliorer Replit Agent à grande échelle
La plupart des utilisateurs de Replit Agent commencent avec une idée. Ils décrivent l'objectif en langage naturel — sans dépôt, suite de tests ou framework choisi — et s'attendent à ce que l'agente le transforme en une application fonctionnelle. Le résultat peut être un site web, un diaporama, une application mobile, plusieurs artefacts connectés, ou quelque chose de totalement différent.
Les « vibe codeurs » ne vérifient généralement pas les diffs ou les résultats de tests. Le succès de Replit Agent est d'une simplicité trompeuse : l'application doit fonctionner lorsque les utilisateurs cliquent.
Cela change la donne pour l'évaluation. Un score unique peut aider à une décision de déploiement spécifique, mais il ne peut pas nous dire, semaine après semaine, si Replit Agent s'améliore pour les utilisateurs. Pour répondre à cette question, l'évaluation doit faire partie de la boucle d'amélioration.
NASA Lewis Research Center, Salle de Contrôle Centrale du Bâtiment de Recherche sur les Moteurs, 1968 — La mesure compte quand elle change ce qui est déployé.
L'évaluation doit faire plus maintenant
L'évaluation des agents ressemblait autrefois à un processus à sens unique : exécuter l'évaluation, produire un score et prendre une décision de déploiement. Cela fonctionne quand les versions sont lentes et que ce qui est mesuré change rarement. Cela s'effondre quand les modèles, les prompts, les outils et les surfaces produit changent tous rapidement.
L'ancienne boucle donnait l'impression que l'évaluation était limitée. Mais Replit Agent évolue trop rapidement pour qu'un seul score porte toute la décision. Un score peut comparer deux candidats sur un même ensemble de tâches. Il ne peut pas expliquer ce qui importe aux utilisateurs, ce qui casse en production, ou ce qu'il faut améliorer ensuite.
L'évaluation devait passer d'un simple contrôle de lancement à une boucle d'amélioration.
L'ancien travail d'évaluation se terminait par une décision humaine de déploiement ; le nouveau alimente un système continu qui apprend de la production et déploie des agents améliorés.
Le système repose sur deux piliers de mesure et une boucle d'optimisation. Les benchmarks hors ligne nous indiquent si les changements candidats peuvent accomplir des tâches simulées de création d'applications avant que nous les déployions. Les tests A/B en ligne et les traces de production montrent comment les utilisateurs réels sont affectés après le déploiement des changements. Ces signaux sont ensuite réinjectés dans les évaluations et les décisions de déploiement.
Aucune couche ne suffit à elle seule. Les benchmarks détectent les régressions avant la publication. Les tests A/B montrent si le comportement en production a changé. Les regroupements de traces expliquent les échecs sous les métriques agrégées. Le jugement humain maintient la boucle d'amélioration orientée vers les bons résultats produit et ingénierie. La forme est analogue au modèle du fromage suisse en ingénierie de la sécurité : chaque couche a des trous, mais ensemble, elles en attrapent plus qu'une seule couche ne le pourrait.
Les benchmarks existants s'arrêtent avant l'utilisateur
Les benchmarks de codage agentique tels que SWE-bench [1] et Terminal-Bench [2] notent le code dans des environnements contraints et reproductibles. Ces benchmarks sont précieux et largement adoptés, mais ils passent à côté du signal qui importe à un « vibe codeur ».
Replit Agent crée souvent la base de code à partir de zéro. Les utilisateurs n'apportent pas de routes fixes, de signatures de fonctions, de sélecteurs ou de tests ; ils apportent une demande de produit. L'agent choisit la pile, le schéma, les routes, les composants et les flux d'interaction.
Cela crée un écart de correction fonctionnelle. Un agent peut satisfaire les contraintes locales d'un benchmark de codage et échouer néanmoins sur ce que l'utilisateur voit : si l'application terminée fait ce qui a été demandé. Pour le « vibe coding », la cible de l'évaluation est l'artefact lui-même : se charge-t-il, le flux de travail principal fonctionne-t-il, et le résultat correspond-il à la demande ?
Présentation de ViBench
C'est précisément le besoin de ce style d'évaluation de bout en bout qui nous a poussés à construire ViBench [3], notre benchmark public pour le « vibe coding », mesurant un signal simple mais important : l'application construite par l'agent répond-elle au cahier des charges ?
ViBench commence par un document de spécification produit (PRD) en anglais simple, tiré de traces de production anonymisées de Replit. De là, l'agent reçoit le PRD et construit une application fonctionnelle à partir de zéro, sans être contraint par l'échafaudage, les routes ou les références que les benchmarks de codage traditionnels exigent.
Cependant, la même flexibilité qui rend ViBench réaliste exige un agent d'évaluation tout aussi flexible, qui reste ancré dans le PRD. Dans les benchmarks de type SWE-bench, le projet existe déjà, donc la surface d'évaluation est fixe. Dans le « vibe coding », l'agent choisit la pile, les routes, les composants et le flux. L'évaluation doit explorer tout ce qu'il a inventé.
À cette fin, chaque tâche ViBench associe le PRD à un ensemble de plans de test en langage naturel qui décrivent les interactions et les assertions au niveau des fonctionnalités que l'application finale doit satisfaire. L'agent d'évaluation utilise Playwright comme base flexible, ce qui lui permet d'exercer des fonctionnalités complexes telles que la simulation hors ligne, la manipulation de fichiers et la multi-location. Parce qu'il ne connaît pas les localisateurs ou la structure de l'application a priori, il travaille dans un environnement de type notebook, découvrant progressivement comment l'application est construite et interagissant avec elle étape par étape, une approche tirée des recherches antérieures de Replit sur les auto-tests automatisés [4].
Exécuter ViBench, et nos évaluations en général, à l'échelle de Replit exige également une infrastructure solide [5]. En interne, nous nous appuyons sur la même infrastructure de production qui nous permet de lancer des environnements sandbox isolés et bien dotés en ressources pour construire des applications et exécuter nos agents. Parce que nous pouvons rapidement forker ces environnements sandbox [6], nous exécutons une grande partie de l'évaluation en parallèle, sans risque de contamination croisée des évaluations.
Au-delà de la construction d'applications à partir de zéro, la même base ViBench — un PRD en langage naturel évalué par des plans de test en langage naturel — s'adapte à une gamme de scénarios de « vibe coding ». Pour évaluer comment un agent travaille au sein d'une application existante, plus proche des charges de travail de trajectoire moyenne de Replit, nous le démarrons sur une base de code existante et mesurons dans quelle mesure il déploie des extensions de fonctionnalités à partir d'un PRD de fonctionnalité. Cette base de code peut provenir de nos propres implémentations de référence ou d'applications que l'agent a lui-même « vibe-codées », ce que nous appelons Vibe-to-ref et Vibe-on-Vibe dans notre publication. Lorsque nous déployons de nouvelles surfaces produit, la même base nous permet de dériver rapidement de nouveaux problèmes pour évaluer des modèles d'interaction inédits, comme nous l'avons fait pour les décompositions parallèle-et-fusion et sous-agent d'Agent 4.
ViBench maintient l'évaluateur comportemental fixe tout en faisant varier l'entrée et la stratégie de construction.
Les premiers résultats de ViBench nous ont apporté deux leçons utiles. Premièrement, les scores des benchmarks de codage de pointe ne se transfèrent pas toujours à la construction complète d'applications, en particulier pour les modèles à poids ouverts. Deuxièmement, la plupart des modèles empirent lorsqu'ils étendent leur propre code, car les erreurs ont tendance à se cumuler. Ensemble, ces leçons nous donnent une meilleure colline à gravir : non seulement écrire du code qui réussit les tests, mais construire des applications capables de survivre à la prochaine demande de l'utilisateur.
Les tests A/B : comment nous restons honnêtes
Nous faisons profondément confiance aux évaluations hors ligne, mais elles ne sont pas les seules juges. Nous avons vu suffisamment de mises à jour d'agents sembler bonnes dans des environnements contrôlés, pour ensuite régresser sur le comportement réel des utilisateurs, pour savoir que la production a besoin de sa propre couche de mesure.
Les utilisateurs sont sans script, toujours actifs et opèrent à une échelle qu'aucun benchmark hors ligne ne peut reproduire entièrement. Ils abandonnent des projets, changent d'avis, combinent des fonctionnalités de manière surprenante et découvrent des modes de défaillance que nous ne savions pas tester.
C'est pourquoi nous testons en A/B la plupart des mises à jour affectant l'agent : prompts, outils, révisions du harnais, changements de modèle et modifications de comportement plus importantes. Plusieurs expériences sont souvent menées simultanément — avec une attribution claire pour éviter de masquer les effets d'interaction. Les tests A/B révèlent le comportement, le sentiment et le succès des utilisateurs : les utilisateurs ont-ils continué, le coût s'est-il comporté de manière inattendue, le sentiment a-t-il évolué, et les utilisateurs ont-ils déployé quelque chose ?
Les tests A/B nous donnent une lecture contrôlée du comportement en production, mais les métriques agrégées ne s'expliquent pas d'elles-mêmes. Est-ce un succès ? Quel est le changement de comportement sous-jacent ?
Un défi avec les tests A/B est que les résultats sont difficiles à interpréter. Si la durée d'exécution augmente, l'agent a-t-il effectué un travail plus utile, ou s'est-il bloqué ? Si le coût diminue, avons-nous amélioré l'efficacité, ou l'agent a-t-il silencieusement cessé de faire quelque chose de précieux ? Si le sentiment baisse, quels cas d'utilisation ont régressé, quels modes de défaillance sont nouveaux, et quels utilisateurs ont abandonné ?
Telescope : ce qui casse
Les tests A/B nous disent quand le comportement en production a changé. Telescope — notre système d'analyse et de regroupement des traces — aide à expliquer pourquoi.
À l'échelle de la production, aucun ingénieur ne peut lire chaque trace. Telescope organise les motifs répétés en groupes de problèmes sur lesquels les ingénieurs et les agents peuvent agir. Il résume les trajectoires d'échec, les intègre, regroupe les cas similaires et classifie les nouvelles sessions à mesure que la distribution change. L'objectif n'est pas seulement de compter les échecs, mais de découvrir ceux qui sont cachés à la vue de tous.
GIF
Regrouper ce que nous ne savions pas chercher.
Telescope utilise des facettes courtes et fondées sur des preuves, inspirées de la même approche ascendante que Clio [7]. Pour les traces, il reconstruit la session à partir des messages utilisateur, des réponses visibles de l'agent, des appels d'outils, des erreurs, des métadonnées et d'autres contextes. De là, Telescope résume ce qui a mal tourné, intègre ces résumés et utilise le regroupement basé sur la densité [8] pour former des groupes de problèmes émergents.
Les facettes accélèrent l'investigation, surtout lorsque le regroupement seul ne suffit pas. Lorsque les rapports de support pointent vers un problème large, comme des échecs de port, les ingénieurs et les agents peuvent d'abord rechercher dans la couche compacte, explorer les facettes pertinentes, puis plonger dans les sessions représentatives avec le contexte des journaux et de l'observabilité nécessaire pour l'expliquer.
Globalement, la même structure transforme les échecs dispersés en questions produit : quels flux de travail dominent, lesquels sont abandonnés, qu'est-ce qui casse de manière répétée, et si une atténuation réduit le groupe de problèmes visé.
Pour plus d'informations sur cette architecture sous-jacente, consultez l'article détaillé sur Topics de nos collaborateurs chez Braintrust [9].
La boucle : des preuves aux améliorations de l'agent
Une fois la mesure en place, le goulot d'étranglement se déplace. ViBench, les tests A/B et Telescope peuvent nous dire ce qui a échoué, où cela a échoué et à quelle fréquence cela se produit. Nous devons encore transformer ces preuves en correctifs plausibles.
Nous nous tournons vers une boucle d'auto-amélioration pour résoudre ce problème. Le principe de fonctionnement est simple : si les agents sont utiles pour construire des logiciels, ils devraient également être utiles pour améliorer l'agent. Chaque passage commence par la lecture des journaux de production, des regroupements de traces et des échecs récents pour trouver une hypothèse qui mérite d'être poursuivie. Ensuite, il construit un candidat, ouvre un PR brouillon avec le raisonnement joint, mesure le résultat par rapport à ViBench, aux résultats A/B, aux données de trajectoire et aux références récentes, et recommande de déployer, d'itérer ou d'abandonner.
La boucle d'optimisation découvre les problèmes, propose des changements d'agent, les évalue et décide de déployer, d'itérer ou d'abandonner.
Le déploiement ne devient pas automatique. La boucle peut préparer les preuves et la première implémentation ; les ingénieurs examinent toujours le résultat et sont responsables de la décision de lancement.
Chaque exécution enregistre ce qui a été tenté et ce qui s'est passé, y compris les échecs. Cet enregistrement améliore la boucle au fil du temps : les exécutions futures peuvent réutiliser ce qui a fonctionné, éviter les impasses connues et proposer des changements qui se généralisent.
L'itération de l'agent s'accélère sans abandonner le contrôle de l'ingénierie. Étant donné un nouveau modèle, une nouvelle surface produit ou un nouvel objectif de fiabilité, la boucle peut trouver de manière proactive des modifications de prompt, des propositions de compétences, des correctifs d'outils et des changements de harnais pendant que les ingénieurs maintiennent le système orienté vers l'optimum produit global.
Un exemple concret
Un récent passage a commencé par un petit groupe Telescope en pleine croissance. La configuration de l'environnement se dégradait silencieusement dans une longue traîne de scénarios de démarrage à froid. Ces sessions n'étaient pas évidentes à partir des métriques agrégées, mais le groupe montrait un modèle qui méritait d'être étudié.
Après avoir mis en évidence le modèle, la boucle a lu les trajectoires affectées, proposé un correctif, ajouté un test de régression et exécuté le candidat contre ViBench pour confirmer que le chemin heureux n'avait pas régressé. Les ingénieurs ont examiné les preuves, approuvé le changement et l'ont poussé en production le jour même.
Après le déploiement du correctif, le sentiment s'est rétabli et les utilisateurs affectés ont été débloqués. C'est la forme que nous voulons — une boucle qui trouve un véritable modèle d'échec, le relie aux utilisateurs affectés, propose le bon niveau de correctif et rapporte suffisamment de preuves pour qu'un humain décide de déployer ou non.
Là où le goût humain compte encore le plus
Une grande partie de cela peut fonctionner de manière autonome : regrouper les échecs, proposer des hypothèses, construire des candidats, exécuter des évaluations et rassembler des preuves. Les humains fixent toujours la direction et contrôlent la plupart des sorties, notamment :
- Sélection des hypothèses. Un système peut mettre en évidence des milliers d'échecs, mais les humains décident quelles questions méritent le budget de nuit de la boucle. Tous les groupes ne sont pas également importants, et toutes les régressions ne pointent pas vers le bon problème produit.
- Architecture de l'implémentation. Les traces peuvent montrer que les utilisateurs abandonnent un flux de travail, mais décider s'il faut lisser ce chemin, changer le comportement de l'agent ou reconcevoir la surface est un jugement d'ingénierie et de produit.
- Curation des évaluations. Ce n'est pas un travail administratif ; cela façonne la colline que l'agent gravit. Si l'évaluation récompense le mauvais comportement, la boucle d'optimisation optimisera fidèlement vers la mauvaise chose.
- Approbation du lancement. Déployer un changement d'agent ne se résume pas à lire un chiffre. L'approbation du lancement signifie lire les preuves, comprendre le rayon d'impact, décider si le risque est acceptable et assumer la responsabilité du déploiement.
Cet équilibre est important : la boucle peut faire davantage de recherche, de mesure et de synthèse. Les ingénieurs choisissent toujours la direction, prennent les décisions produit et décident ce qui est déployé.
Boucler la boucle
L'évaluation n'est plus seulement une porte avant le lancement. Elle aide à décider quoi corriger, quoi tester et quoi publier.
Le travail ne consiste pas à produire un meilleur chiffre. Il s'agit de transformer les échecs des utilisateurs en meilleures versions, afin que davantage d'idées deviennent des applications dont les gens sont fiers de publier.
Nous sommes ravis de continuer à repousser les limites des agents autonomes, en mettant l'accent sur la fiabilité pour les tâches de codage les plus complexes. Si vous êtes intéressé par le travail sur les agents de codage autonomes, je recrute toujours dans l'équipe Replit AI — contactez-moi à [email protected]
Auteurs : Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta
Références
[0] Apprentissage continu pour les agents IA
[1] SWE-bench : Les modèles de langage peuvent-ils résoudre des problèmes GitHub du monde réel ?
[3] ViBench : Un benchmark sur le Vibe Coding
[4] Permettre à l'Agent 3 de s'auto-tester à grande échelle avec la vérification basée sur REPL
[5] Quantifier le bruit d'infrastructure dans les évaluations de codage agentique
[6] Dans les coulisses du Snapshot Engine de Replit : La technologie qui rend les agents IA sûrs
[7] Clio : Informations préservant la vie privée sur l'utilisation réelle de l'IA
[9] Comment nous avons rendu possible l'intelligence de trace continue à grande échelle
