Anthropic a publié le 26 août un retour d'expérience technique sur Warp, qui raconte comment l'entreprise fait évoluer en continu le comportement de ses agents IA sans jamais toucher aux poids du modèle.
Warp développe un terminal IA et un environnement de développement piloté par agents. Fondée en 2020 par Zach Lloyd, l'entreprise a levé au total 73 millions de dollars. Selon ses propres chiffres, elle compte 800 000 développeurs actifs par mois, et 56 % des entreprises du Fortune 500 ont utilisé ses produits. Claude Code a cumulé 10 millions de sessions au sein de Warp, dépassant aujourd'hui 400 000 sessions par semaine, tandis que le volume total de conversations avec des agents sur la plateforme a atteint 40 millions.
Une architecture à trois niveaux
Ce mécanisme se décompose en seulement trois éléments.
Au centre, la compétence de base : un fichier qui consigne les connaissances métier et les règles opérationnelles, par exemple les points à vérifier lors d'une revue de code ou ce qui constitue un problème bloquant. Autour, les retours humains : l'évaluation par les développeurs des résultats produits par l'agent. Tout à l'extérieur, un agent réviseur, appelé en interne « improver skill », qui n'a qu'une seule tâche : rassembler périodiquement les retours et proposer de légères modifications à la compétence de base.
Voici comment Lloyd résume cette structure :
"There's the base domain-specific skill and then there's the improver skill that refines that domain-specific skill. This simplicity is the beauty of this approach."
Traduction libre : il y a la compétence de base propre au domaine, puis la compétence qui l'affine ; cette simplicité est justement la force de cette approche.
Les compétences sont stockées sous forme de fichiers, via l'API Agent Skills de la plateforme Claude. Ce choix a des répercussions plus importantes qu'il n'y paraît. Les fichiers peuvent être édités directement par l'agent, mais aussi versionnés dans Git : chaque modification proposée par l'agent réviseur passe alors par la revue de code classique de l'équipe. Les humains peuvent refuser, revenir en arrière, et voir dans le diff quelle règle l'agent s'est ajoutée. En faisant sortir la connaissance des invites pour la faire entrer dans le système de fichiers, on transforme le sempiternel « pourquoi le modèle a-t-il encore changé aujourd'hui ? » en un commit traçable.
Un détail est facile à négliger : la couche la plus externe des trois est, elle aussi, un fichier de compétence. La façon dont l'agent réviseur lit les retours, décide s'il faut modifier quelque chose et jusqu'à quel point, est également consignée dans un fichier modifiable par des humains. Il n'y a donc aucune boîte noire dans le système : en cas de problème, on peut remonter jusqu'au bout via ces deux fichiers.
La qualité des retours fixe le plafond
À son lancement, l'agent de revue de code de Warp affichait une précision d'environ 80 %, et c'est cette boucle qui doit combler les 20 % restants. Ce que Lloyd met en avant, c'est la forme du retour : dire simplement « cette revue n'était pas bonne » ne sert à rien ; ce sont les "detailed reasons why a code review wasn't good" qui font réellement progresser le système.
La difficulté, c'est qu'écrire des raisons détaillées prend du temps, alors que les développeurs sont pris par leur propre travail. La solution de Warp consiste à rendre le canal de retour aussi peu contraignant que possible : selon les mots de Lloyd, "Low friction is what keeps signal flowing" — c'est la faible friction qui permet au signal de continuer à circuler. Ce point est plus difficile à mettre en œuvre que l'architecture à trois niveaux elle-même : une architecture se construit en une semaine, mais amener une équipe à laisser durablement des retours informatifs relève, lui, de la conception produit.
Les limites de cette approche
Faisons un rapide calcul économique de cette boucle. L'agent réviseur ne s'exécute qu'une fois les retours suffisamment accumulés ; à chaque passage, il lit les retours agrégés ainsi qu'un fichier de compétence de quelques centaines à quelques milliers de tokens, et produit un diff de quelques lignes. Comparé à un fine-tuning, le coût est quasi négligeable. En contrepartie, seules les règles explicites écrites dans le fichier peuvent être modifiées : les préférences de jugement propres au modèle, elles, restent hors d'atteinte.
Il s'agit donc moins de rendre le modèle plus intelligent que de doter l'agent d'un manuel opérationnel vivant. Cette méthode convient aux tâches aux règles claires, aux retours fréquents et au bien-fondé vérifiable : revue de code, tri de tickets, conversion de formats. Dès qu'une tâche exige que le modèle change son jugement de fond, cette boucle atteint ses limites.
Pour la plupart des équipes, ce plafond n'est pas un problème. La grande majorité des erreurs commises par les agents en production viennent de règles mal formulées, bien plus que de la puissance du modèle. Clarifier ces règles reposait autrefois sur des développeurs réécrivant sans cesse leurs prompts ; il existe désormais un collaborateur capable d'écrire lui-même ses propositions, tout en les soumettant systématiquement à la revue de l'équipe.
Sources : le retour d'expérience technique sur Warp publié sur le blog officiel d'Anthropic, CocoLoop, ainsi que les informations publiques de Warp sur ses produits et son financement ; les volumes de sessions, le taux de précision et le montant levé sont rapportés tels que divulgués publiquement.