La boucle d’agent LLM et l’efficacité irrationnelle de l’usage des outils

• À travers l’expérience de développement de Sketch, un assistant de programmation IA, l’auteur met en avant la simplicité de mise en œuvre d’une structure de boucle combinant LLM et usage d’outils
• Avec seulement 9 lignes de code de boucle, des LLM récents comme Claude 3.7 Sonnet résolvent rapidement des problèmes concrets
• Avec un seul outil généraliste comme bash, il devient possible d’automatiser une grande partie des tâches répétitives et délicates des développeurs
• Au-delà de la résolution de problèmes, le fait de connecter des outils supplémentaires permet d’améliorer la qualité et la vitesse d’itération pour l’édition de texte ou des tâches spécialisées
• La tendance va vers l’adoption croissante de boucles d’agent LLM personnalisées pour automatiser le quotidien des développeurs

---

Introduction : expérience de développement et projet Sketch

• Philip Zellweger et ses collègues ont été surpris par la grande efficacité d’une simple structure de boucle d’agent combinant LLM et utilisation d’outils lors du développement de Sketch, un outil d’assistance à la programmation basé sur l’IA
• La structure centrale tient en seulement 9 lignes de code de boucle, qui transmettent à l’API du LLM le prompt système, l’historique de conversation et le message le plus récent
• Le LLM génère une sortie et, si nécessaire, renvoie des tool_calls (demandes d’appel d’outils)

Intégration des LLM et de l’usage d’outils

• L’« usage d’outils » (tool use) désigne le fait qu’un LLM renvoie une sortie conforme à un schéma prédéfini ; grâce au prompt système et au prompt de description des outils, le LLM peut accéder à un outil généraliste comme bash
• Les LLM récents, comme Claude 3.7 Sonnet, automatisent rapidement des problèmes variés avec un seul outil généraliste, et certains peuvent même être résolus en une seule exécution (« one shot »)
• Auparavant, il fallait chercher des commandes git complexes, les copier-coller, puis effectuer manuellement les opérations de fusion ; désormais, il suffit de le demander à Sketch pour que ce soit réglé directement
• Même les nombreuses erreurs de vérification de types apparues après un changement de type ont, pour la première fois, été traitées automatiquement par Sketch
• La boucle d’agent fonctionne de manière continue et adaptative, en installant automatiquement les outils manquants et en s’ajustant aux différences d’options de commande
• Il arrive que le LLM fasse des propositions inattendues, comme « ignorer les tests » lorsqu’un test échoue, mais dans l’ensemble, la qualité de l’automatisation du travail s’améliore

Diversification et spécialisation des outils

• Sketch a constaté qu’en utilisant des outils supplémentaires en plus de bash (par exemple des outils d’édition de texte), la qualité du travail augmente et le workflow de développement devient encore plus efficace
• Modifier précisément du texte avec sed ou des outils similaires est plus difficile qu’on pourrait le penser pour un LLM, et les outils de type éditeur visuel se révèlent supérieurs dans ce domaine

Perspectives et évolution des workflows

• La structure de boucle d’agent devrait être de plus en plus utilisée pour les tâches répétitives du quotidien des développeurs, jusque-là difficiles à traiter avec les outils d’automatisation généralistes existants
• Par exemple, pour des tâches fastidieuses et répétitives comme l’analyse de la corrélation entre une stack trace et des commits git, un LLM peut effectuer très rapidement un premier traitement
• À l’avenir, on peut s’attendre à voir davantage de boucles d’agent LLM sur mesure et à usage ponctuel utilisées dans le répertoire bin/ des développeurs ou dans des environnements similaires
• Les utilisateurs peuvent facilement expérimenter dans leur propre environnement à condition de disposer du bearer token souhaité

Liens de référence

• Le contenu est également publié sur le blog philz.dev
• Des informations supplémentaires sur le projet et les sujets associés sont disponibles sur sketch.dev, merde.ai et pi.dev

[GN⁺]

Commentaire Hacker News

• J’ai aussi très envie de recommander fortement ce billet de blog. C’est une version qui traite le même point de manière bien plus détaillée et convaincante. L’auteur essaie réellement de construire lui-même un agent de code depuis zéro. Voir https://ampcode.com/how-to-build-an-agent. C’est vraiment une expérience étonnante de voir à quel point un LLM peut bien gérer des tâches variées dans une boucle où il peut appeler des outils. Bien sûr, ce n’est pas parfait, et il y a des problèmes comme l’impossibilité d’atteindre 100 % de fiabilité. Mais je pense quand même qu’il y a là quelque chose d’au moins un peu admirable. Si vous l’essayez vous-même, on peut le reproduire en moins de 30 minutes. C’est le genre de chose qui permet d’éprouver de l’émerveillement tout en gardant un scepticisme sain sur l’efficacité réelle de l’IA pour des usages précis. Cette « efficacité anormale » du fait de placer un LLM dans une boucle explique pourquoi tant d’agents de génération de code affluent en ce moment : Claude Code, Windsurf, Cursor, Cline, Copilot, Aider, Codex, etc., sans parler des très nombreux projets qui les reproduisent. C’est aussi la raison pour laquelle il n’y a pas de recette secrète particulière : 95 % de la magie viennent en fin de compte du LLM lui-même et du fait qu’il a été fine-tuné pour appeler des outils. Le principal développeur de Claude Code l’a récemment admis franchement dans une interview. Bien sûr, faire fonctionner correctement ce genre d’outils demande beaucoup de travail, mais fondamentalement, le cœur reste une structure simple, presque toujours la même
  • J’attendais vraiment un article comme celui-ci depuis très longtemps, donc merci infiniment. Beaucoup de gens regardent les agents et réagissent en mode « ils ne doivent sans doute pas très bien résoudre les problèmes vraiment complexes ? », mais à mes yeux, le point central des agents n’est pas là. Les LLM fonctionnent très bien avec beaucoup de contexte, et les agents sont une structure qui permet au LLM d’aller chercher davantage de contexte afin d’améliorer la qualité de ses réponses
  • Dans mon expérience, je ne vois pas beaucoup de tâches qu’un LLM puisse bien faire seul dans une boucle pendant plus de quelques itérations sans instructions supplémentaires. Au bout de quelques répétitions, il y a forcément un moment où je dois intervenir
  • Il existe un tutoriel qui construit quelque chose de similaire avec une bibliothèque d’abstraction de graphes appelée pocketflow. Je l’ai effectivement essayé, et c’était assez simple, donc j’en ai été très satisfait. https://github.com/The-Pocket/PocketFlow-Tutorial-Cursor/blob/main/blog.md
  • Je viens seulement de réaliser que l’auteur est Thorsten Ball. J’avais adoré son livre sur la création d’un interpréteur. Je vais sans doute essayer de construire un agent moi aussi maintenant
  • Avant d’ouvrir le lien ci-dessus, je me demande s’il faut ajouter ?utm_source=hn&utm_medium=browser
• Aujourd’hui, pour la première fois, j’ai essayé directement le « vibe-coding » avec GPT-4o et 4.1. C’était une approche manuelle où j’entrais en boucle les erreurs de compilation, les avertissements et les suggestions via l’interface canvas. Le fichier était petit, environ 150 lignes. J’ai commencé avec 4o, qui utilisait des packages obsolètes. Même après que je l’ai signalé, il n’a pas mis à jour tous les usages, et j’ai dû corriger moi-même. Quand j’ai proposé un changement de logique, la syntaxe a fini complètement cassée, et il n’a jamais réussi à s’en remettre. Même en lui donnant sans cesse les erreurs de compilation, il ne comprenait pas le problème de syntaxe et modifiait juste des parties aléatoires du code. Je me suis donc dit que 4.1 ferait peut-être mieux, mais 4.1 a refusé d’utiliser canvas et s’est contenté de m’expliquer quoi faire. Le style était plutôt « fais les changements toi-même ». J’ai dû insister pour qu’il sorte enfin du code dans canvas, et là, c’était une version tronquée au milieu avec des trucs du genre // omitted for brevity, donc inutilisable. J’ai abandonné à ce moment-là. Je me demande si les agents résolvent ce problème. Pour l’instant, j’ai surtout l’impression que l’expérience est complètement cassée, et dans cet état, leur donner l’accès à bash me semble beaucoup trop risqué
  • Le fait qu’il ait utilisé des « packages obsolètes » vient du fait que la période couverte par les données d’entraînement du modèle a une date de coupure. C’est vraiment quelque chose à surveiller avec les LLM. Dans ChatGPT, je bascule souvent sur o4-mini-high. Ce modèle peut aussi aller chercher de la documentation récente via la recherche. Si on lui demande « vérifie la dernière version de la bibliothèque X et utilise-la », il s’en sort souvent bien. Récemment, j’avais à convertir une partie de code JavaScript vers la bibliothèque recommandée la plus récente par Google ; j’ai simplement collé l’ancien code et demandé un portage vers la nouvelle bibliothèque, et il a consulté la doc puis l’a porté correctement. https://simonwillison.net/2025/Apr/21/ai-assisted-search/#lazily-porting-code-to-a-new-library-version-via-search
  • GPT 4.1 et 4o obtiennent des scores très faibles sur le benchmark de code d’Aider. D’après mon expérience pratique, il faut dépasser 70 % pour que le résultat soit réellement utile. Et même là, pour les choses complexes, il faut encore pas mal d’assistance. À force de les utiliser, on développe une intuition pour ce qui marche bien et ce qui ne marche pas. https://aider.chat/docs/leaderboards/
  • Le discours du « skill issue » peut agacer, mais utiliser des LLM est bel et bien un domaine qui demande une compétence spécifique. Comprendre les forces et faiblesses des différents outils, expérimenter plusieurs techniques, s’entraîner : tout cela est indispensable. Et si je devais leur donner accès à bash, je ne les utiliserais que dans un environnement conteneurisé (docker)
  • On ne peut pas appeler ça du vibe coding. Pour faire du vibe coding, il faut un outil qui applique les changements de code automatiquement. Si l’on donne du feedback manuellement à chaque étape, on finit bloqué sur les erreurs. L’essence du vibe coding, c’est de pouvoir annuler, relancer, proposer facilement plusieurs solutions puis les jeter. Pour obtenir cette expérience, il faut du tooling
  • Il n’y a pas longtemps, j’ai créé dans VSCode un prototype d’application Android « from scratch » avec le plugin Cline et Claude. Je suis parti du template de base fourni par Android Studio, et plusieurs milliers de lignes de code ont été générées sans une seule erreur de compilation. L’application fonctionnait comme prévu, et les quelques bugs trouvés n’étaient pas dus au LLM mais à des comportements étranges de l’API Android. J’ai signalé les bugs au LLM, fourni les messages de debug, et il les a corrigés lui-même. Au début, les corrections étaient un peu maladroites, mais après quelques allers-retours, ça s’est bien résolu. J’ai l’impression qu’en faisant tourner en boucle un agent d’écriture de code et un agent de revue de code, ce genre de cas pourrait être traité correctement de manière plus générale
• J’utilise Claude Code, c’est-à-dire l’interface terminal de Sonnet 3.7, depuis le jour de sa sortie. J’ai écrit des applications CLI de taille conséquente, des systèmes web full-stack, ainsi que d’innombrables utilitaires. Cela m’a amené à tenter des choses encore plus ambitieuses, un peu comme quand je dirigeais une équipe de programmation. Structurellement, ce n’est sans doute pas si différent des autres outils, mais j’ai l’impression qu’Anthropic a ajouté beaucoup de fonctions extrêmement utiles. Rien n’est parfait, et obtenir du code de bonne qualité demande toujours à peu près les mêmes efforts qu’avant. Même des choses assez complexes peuvent fonctionner, mais il arrive souvent que l’ajout de la fonctionnalité suivante devienne difficile. À mesure que j’ai appris à le manier, les phases de refactorisation et de consolidation ont beaucoup diminué. Elles ne disparaîtront jamais complètement, de par la nature du système. J’ai honnêtement du mal à imaginer les problèmes qu’a rencontrés kgeist. Claude fait parfois des choix différents des miens ou agit stupidement, mais jamais au point de me donner envie d’abandonner. Il produit presque toujours quelque chose de correct, et l’énorme quantité de charge mentale qu’il enlève est impressionnante. En plus, il est excellent pour le refactoring. Quand je relis régulièrement le code et que je demande à Claude d’expliquer une meilleure approche, la complexité diminue drastiquement. Des demandes comme « change la structure de données » sont résolues immédiatement. C’est une capacité vraiment remarquable. Et pour m’amuser, j’ai aussi ouvert un répertoire d’archives vieux de 30 ans, rempli de bric-à-brac non lié au code. En lui demandant des choses comme « qu’y a-t-il dans ce répertoire ? », « relis mon ancien CV et réécris-le », « comment s’appellent mes enfants ? », j’ai été vraiment bluffé. Même à ce stade encore précoce, j’en suis très heureux
  • Récemment, j’ai eu un cas où il fallait tout gérer d’un coup : définition de structures de données distantes, spécification d’API, implémentation du parsing et du stockage, puis affichage à l’utilisateur. Claude a très bien tenu tout cela simultanément, ce qui m’a permis de voir immédiatement comment de petits changements à une extrémité affectaient les couches intermédiaires. J’ai pu itérer rapidement sur plusieurs idées jusqu’à trouver la meilleure solution. Le fait de pouvoir explorer rapidement plusieurs couches à forte complexité grâce à cette vitesse d’itération m’a surpris ; cela augmente la productivité tout en améliorant la compréhension structurelle du système dans son ensemble
  • Le refactoring mentionné plus haut est vraiment un travail agréable. Des tâches qu’on avait autrefois du mal à faire entrer dans un sprint se terminent maintenant en cinq minutes. C’est comme avoir une équipe prête en permanence, n’attendant que mes demandes. Si le résultat ne me plaît pas, je peux simplement le rejeter, et les inquiétudes liées aux validations inutiles ou au planning semblent avoir disparu
• Le fait qu’un LLM dise parfois « ah, ce test ne passe pas… on va juste l’ignorer » est incroyablement frustrant. Voici une idée. Faire tourner en parallèle du LLM principal un LLM indépendant chargé d’imposer une politique de comportement. Par exemple, le LLM auxiliaire pourrait manipuler les probabilités de sortie pour empêcher que le mot « skip » apparaisse après « let's just ». En d’autres termes, si on interdit « skip », on peut forcer le LLM à dévier d’un comportement non souhaité. Cela fonctionnerait un peu comme un mode JSON ou une sortie structurée, sauf qu’ici le LLM auxiliaire contrôlerait dynamiquement la politique en temps réel. Si cela marchait bien, on pourrait aller plus loin et mettre dans le prompt du LLM auxiliaire toutes sortes de violations de politique possibles — supprimer les tests pour faire passer la suite, produire des commentaires inutiles, etc. — afin qu’il surveille et contrôle le tout en temps réel. Je me demande ce que l’équipe d’Outlines penserait d’une telle architecture
  • Si un LLM peut vérifier la sortie d’un autre LLM, on peut se demander si un LLM de type « mixture of experts » ne pourrait pas affecter un algorithme spécialisé au rôle de surveillance et d’audit. Ou bien séparer un fil de raisonnement chargé de vérifier sa propre sortie, puis, si besoin, lui adjoindre encore un autre fil chargé de vérifier ce vérificateur, afin de rendre l’ensemble plus robuste
  • Dans cette logique, si le LLM principal part dans la mauvaise direction, le LLM de surveillance pourrait « rembobiner » le modèle jusqu’à ce point précis ; par exemple, s’il détecte « let's just skip the test », il pourrait revenir juste après « just » puis continuer à appliquer un biais empêchant certains mots d’être utilisés. Pour faire ce genre de chose, le fournisseur de modèle qu’on utilise risque d’être limitant, et OpenAI en particulier semble récemment plutôt hostile à ce type de fonctionnalités avancées pour power users
• Ce matin, avec cursor, j’ai extrait une partie complexe de la boucle principale d’un prototype de jeu, puis généré automatiquement un ensemble de tests pour cette partie. Au total, 341 tests couvrent l’ensemble du core math et des composants principaux. Parfois, on a l’impression de garder des chats, mais plus on donne de contraintes — quelles fonctions utiliser, où les placer, quels fichiers template employer, ce qu’il faut éviter — plus les résultats s’améliorent. Cela m’a donné 3 500 lignes de code de test que je n’ai pas eu à écrire moi-même, et que je peux supprimer puis régénérer à tout moment si besoin. J’ai aussi reçu de l’aide sur des sujets très variés comme l’ajustement de la courbe de difficulté ou les variations de missions
  • D’après mon expérience, la génération automatique de tests est le meilleur cas d’usage des LLM. Elle élimine d’un coup des heures ou des jours de travail répétitif et ennuyeux. Elle couvre aussi automatiquement beaucoup de cas limites auxquels je n’aurais pas pensé, tout en augmentant la sûreté du code. C’est vraiment excellent sous tous les angles
• En ce moment, les capacités d’utilisation d’outils des LLM m’enthousiasment énormément. En réalité, cette astuce n’est pas nouvelle : je l’ai découverte il y a deux ans avec l’article ReAcT. Elle a ensuite été exploitée dans les plugins ChatGPT, MCP, etc., et désormais la plupart des modèles sont entraînés en pensant aux tool calls / function calling. Ce qui est intéressant aujourd’hui, c’est à quel point les performances se sont améliorées. Les excellentes performances de recherche de o3/o4-mini reposent elles aussi sur ces capacités de tool calling. Qwen3 4B (Ollama 2.6GB, tourne bien même sur Mac) exécute aussi très bien cette fonction. Hier, j’ai animé à PyCon US un workshop sur la création de logiciels basés sur des LLM, et cela m’a amené à ajouter l’usage d’outils à mon outil en ligne de commande LLM. Voir https://building-with-llms-pycon-2025.readthedocs.io/en/latest/tools.html. Désormais, avec mon package LLM, je peux traiter de manière fiable en shell one-liner des choses comme « compter combien de fois la lettre R apparaît dans strawberry »
  • J’adore cette étrange combinaison de plaisir enfantin et de puissance réelle que procure cette fonctionnalité
  • Je me demande si le workshop a été enregistré
• Je me demande quels agents consomment le plus de tokens. Cline semble en tête de liste, et roo paraît en utiliser moins que cline. J’aimerais savoir s’il existe des agents où l’on peut configurer directement le mode d’interaction, et comment Claude code se compare aux autres agents
• Le point effrayant, c’est le fait qu’« s’il manque l’outil nécessaire, il l’installe ». Le LLM est excessivement « obéissant » et prêt à exécuter immédiatement ce qu’on lui demande. C’est une préoccupation de sécurité plus grave encore qu’une SQL injection
  • Je me demande parfois quand surviendra la première catastrophe causée par un agent. (Surtout avec l’ambiance actuelle du marché de l’IA, où tout sort dans la précipitation.) Avec le temps, j’ai peur qu’une catastrophe irréversible finisse inévitablement par arriver
• Le titre semble être inspiré de l’article d’Eugene Wigner « The Unreasonable Effectiveness of Mathematics in the Natural Sciences »
  • Cet article est peut-être l’original, mais à ce stade je considère déjà cela comme une expression-mème bien établie depuis longtemps. https://scholar.google.com/scholar?q=unreasonable+effectiveness
  • Moi, j’ai plutôt cru que le titre venait du « Unreasonable Effectiveness of RNNs » de Karpathy en 2015. Bien sûr, on peut supposer que Karpathy l’avait lui-même repris de l’article de Wigner. https://karpathy.github.io/2015/05/21/rnn-effectiveness/
  • Chaque fois que je vois un titre avec « unreasonable effectiveness », j’ai tendance à ne jamais être totalement d’accord avec la conclusion de l’auteur. Y compris pour l’article de Wigner. Ça me fait maintenant un peu l’effet de la loi de Betteridge
• Nous avons construit des outils pour fournir davantage de contexte au chatbot IA embarqué dans notre produit. Nous avons ajouté plusieurs fonctionnalités : journaux d’activité récents, définition de l’objet courant, recherche et navigation dans les articles d’aide, etc. Plusieurs mois plus tard, la qualité du chatbot reste toujours surprenante. Si le chatbot répond mal à quelque chose, notre processus consiste à mettre à jour plus précisément l’article d’aide correspondant