Pourquoi pousse-t-on autant l’IA agentique alors que les modèles suivent à peine une instruction simple ?

• Alors que les modèles d’IA pour le code sont incapables d’exécuter de façon fiable ne serait-ce qu’une instruction unique, des attentes excessives se forment autour du codage agentique opérant de manière autonome en arrière-plan
• L’auteur a constaté que, bien qu’il ait fourni comme code de référence une fonction Golang d’environ 100 lignes, GPT-5 comme Gemini Pro omettaient une partie de la logique ou oubliaient certaines mises à jour
• Qu’un système agentique puisse traiter de manière autonome 50 fichiers et de nombreuses fonctions est irréaliste au vu du niveau technologique actuel, avec au contraire le risque d’y passer encore plus de temps en débogage
• Les réponses de la communauté se divisent entre, d’un côté, l’idée qu’un usage limité peut réussir grâce à un prompting structuré, une documentation rigoureuse et une vérification étape par étape, et de l’autre, un point de vue sceptique selon lequel l’agentique n’est pas encore praticable
• Les LLM actuels étant des systèmes fondés sur la connaissance plutôt que sur l’intelligence, l’approche réaliste consiste en un usage comme outil où le développeur fournit lui-même le contexte et valide chaque étape

---

Mise en question par l’auteur du texte original

• Exemple d’échec sur une consigne simple : il a fourni une fonction Golang de 100 lignes comme référence et demandé de mettre à jour une autre fonction avec la même structure, mais GPT-5 comme Gemini Pro ont omis une partie de la logique ou oublié certaines modifications
• Irréalisme du codage agentique : si même une seule fonction n’est pas correctement traitée, une approche agentique modifiant de façon autonome de nombreuses fonctions sur 50 fichiers risque de provoquer encore plus de problèmes
• Question sur la mise à jour d’un fichier de 6000 lignes : il demande l’avis de la communauté sur la manière de modifier en toute sécurité un fichier d’environ 6000 lignes, comme lors d’une mise à jour de version Stripe

Cas d’usage positifs et méthodologies

Approche par documentation structurée et indexation

• Utilisation de fichiers de référence Markdown : stocker les références dans un fichier .md et demander à l’IA de le lire améliore la cohérence et la précision
  • Exemple de prompt : « En te référant au fichier joint goLang_Update_reference.md, résume les points essentiels de la fonction update, puis rédige un brouillon de mise à jour logicielle à partir de cette base »
• Construction d’un index local : pour les gros fichiers (6000 lignes ou plus), effectuer un scan par blocs de 1000 lignes afin de créer un index incluant les noms de fonctions et leurs références de lignes
  • Pour le travail frontend, utiliser un index séparé ciblant uniquement certaines zones, comme fr.index.md

Gestion des agents et structuration du travail

• Spécialisation des agents : constituer des agents par rôle, comme conception (architect), exploration de code (codeseeker) et développement (coder), et fournir à chacun un fichier de règles .md adapté
• Approche par tranches verticales : découper le travail en petites unités fonctionnelles pouvant être réalisées sous la barre des 100 k tokens
  • Au-delà de 100 k tokens, le risque de dysfonctionnement de l’agent augmente fortement
• Documentation obligatoire du travail : imposer la mise à jour de docs/TASKS.md, docs/WORKLOG.md et docs/DECISIONS.md pour garantir la continuité du travail

Utilisation de Plan Mode et Ask Mode

• Plan Mode : passer en revue l’ensemble du projet, établir un plan selon la demande, puis avancer étape par étape
• Ask Mode : utile pour interroger la codebase, explorer des idées, examiner des options, et peut servir d’alternative à Google/StackOverflow

Approche avec tests unitaires d’abord

• Développement piloté par les tests : écrire d’abord les tests unitaires avant la fonction, puis faire générer de manière itérative par l’IA un code qui les passe
  • La probabilité d’obtenir un code correct sur le plan fonctionnel augmente fortement, et il ne reste ensuite qu’à optimiser et nettoyer

Opinions sceptiques et reconnaissance des limites

Limites réelles de l’agentique

• Travailler sans supervision relève du suicide : au niveau technologique actuel, attribuer un ticket et laisser travailler le système de manière autonome en arrière-plan présente une forte probabilité d’échec
• Possibilité de mensonge : le modèle est plus susceptible de produire des hallucinations que de réussir, et dans le pire des cas peut détruire le code existant
• Redondance du Planning Mode : demander un plan détaillé au modèle de base suffit souvent ; le Planning Mode n’apporte pas réellement de fonctionnalité nouvelle

Contraintes intrinsèques des LLM

• Prédiction plutôt que raisonnement : le modèle fonctionne en prédisant le mot suivant sans vérifier le résultat ; tant que le grounding, la mémoire et le feedback ne seront pas améliorés, la fiabilité restera instable
• Une base de connaissances sans intelligence : les LLM sont des bases de connaissances sophistiquées dépourvues d’intelligence, et le développeur doit lui-même apporter l’intelligence (BYOI: Bring Your Own Intelligence) et le contexte
• Manque de mémoire : le modèle ne dispose pas d’une véritable mémoire et dépend uniquement du contexte et du cache de contexte ; à chaque nouveau chat, le contexte est réinitialisé

Biais liés au langage et aux données

• Désavantage relatif de Golang : Golang dispose de moins de code public que Python ou JavaScript, si bien que le modèle a moins de motifs et de conventions appris
  • C’est un facteur structurel qui rend plus difficile l’obtention de modifications ou de transformations cohérentes

Guide pratique pour un usage réussi

Prompting et apport de contexte

• Instructions claires et détaillées : utiliser une grammaire et une ponctuation précises, et donner des consignes explicites plutôt que des formulations ambiguës
• Référencer explicitement tous les fichiers pertinents : si tous les fichiers que l’agent doit utiliser ne sont pas indiqués, la probabilité de générer du spaghetti code augmente
• Configurer des fichiers de règles : définir des règles globales pour l’espace de travail ainsi que des fichiers de règles par projet afin d’orienter une génération de code cohérente
• Utiliser @Docs : exploiter la fonction de référence documentaire pour fournir à l’agent les connaissances clés dont il a besoin (fonctionnement instable dans certaines versions)

Périmètre de travail et validation

• Découper en petites unités : fractionner le travail en la plus petite unité possible, valider chaque étape, puis passer à la suivante
• Revue en temps réel : relire tout le code généré au fur et à mesure et demander immédiatement des corrections pour éviter le spaghetti code
• Sauvegardes et gestion de versions : créer des sauvegardes à chaque étape et utiliser un système de gestion de versions comme GitHub
• Exécuter les tests : lancer de manière incrémentale les tests impactés avec pytest --testmon -q, puis exécuter l’ensemble des tests avant finalisation

Modularisation et structure du code

• Découper un fichier de 6000 lignes : un fichier unique de 6000 lignes est peu modulaire et défavorable à l’apport de contexte ; il est plus efficace de le diviser en 12 fichiers d’environ 500 lignes
• Préférer les tranches verticales : développer par petites unités fonctionnelles exécutables de bout en bout

Choix du modèle et gestion des coûts

• Donner la priorité à Claude Sonnet 4.5 : par rapport à GPT ou Gemini, il offre une meilleure cohérence et une meilleure précision, ce qui peut justifier le coût supplémentaire
• Attention à la consommation de tokens : les plans à grande échelle consomment beaucoup de tokens ; en pratique, il est plus rentable de procéder par petites étapes

Cas d’usage particuliers

Génération de scripts ponctuels

• Scripts d’analyse : lorsqu’il faut écrire chaque jour des centaines de scripts ponctuels d’analyse de données, même une précision de 50 % permet de les générer et de les exécuter 1000 fois plus vite qu’une rédaction manuelle
• Possibilité de vérifier les résultats : comme les résultats peuvent être vérifiés directement, une précision imparfaite reste exploitable

Construction d’une application from scratch

• Architecture multi-agents : lors de la création d’une grande application from scratch, un agent superviseur examine le travail des autres agents pour maintenir la cohérence
  • Efficace pour la cohérence des noms d’import, des noms de variables et pour éviter les duplications de code
• Efficacité par rapport au coût : des modifications complexes et du refactoring restent néanmoins nécessaires, si bien qu’une approche progressive demeure moins coûteuse à long terme

Résumé des avis de la communauté

Expériences positives (gain de productivité de 3 à 5x)

• Site web Next.js : construction en quelques minutes, à partir de zéro, d’un site web entièrement fonctionnel et déployable
• Implémentation de fonctionnalités complexes : ajout en 3 à 4 minutes d’une fonction de threads dans une application de chat (contre 3 jours estimés)
• En cas d’approche structurée : en combinant règles claires, contexte suffisant et validation étape par étape, il est possible d’obtenir des succès cohérents

Expériences négatives (actuellement peu pratiques)

• Production massive de spaghetti code : avec des objectifs trop larges, on observe des problèmes comme l’oubli de mise à jour de la documentation ou la non-suppression de fichiers résiduels
• Erreurs sémantiques : le code fonctionne techniquement, mais se retrouve au mauvais endroit ou réimplémente des fonctions existantes, ce qui crée des problèmes structurels
• Échec des longues exécutions de suivi : les suivis durant plus de 5 minutes produisent le plus souvent des résultats inutiles

[GN⁺]

Avis Hacker News

• D’après mon expérience, j’ai l’impression que la plupart des LLM suivent plutôt bien mes consignes. Bien sûr, il faut des prompts soigneusement peaufinés et une planification en amont, mais une fois qu’on a pris le coup sur ces trois points, on peut vraiment aller très loin avec ce genre d’agents de codage. Il leur arrive de se tromper environ 1 fois sur 10, mais même dans ces cas-là, on revient vite sur les rails avec un arrêt rapide et une réaffectation. Je suis surpris de voir à quel point beaucoup de gens sur HN restent sceptiques sur leur efficacité. Il y a évidemment des inquiétudes sur les coûts, l’évolution des métiers, etc., mais voir revenir si souvent des doutes sur l’utilité des agents de codage m’étonne
  • J’aimerais voir des vidéos ou des cas concrets où des systèmes agentiques ou des LLM créent vraiment plus de valeur qu’une recherche Google ou Stack Overflow
  • Si on leur explique suffisamment l’état actuel, le résultat souhaité et la manière d’avancer, on peut planifier, affiner puis exécuter avec l’agent. Dans ce cadre, l’état de l’art actuel est quand même assez impressionnant. Attendre quelque chose de complexe à partir d’une seule phrase, c’est irréaliste. Il faut un vrai investissement en temps et en efforts, un peu comme quand on confie une tâche technique à un stagiaire brillant mais sans expérience du terrain. Sauf qu’un agent IA travaille bien plus vite qu’un stagiaire humain
  • « Ça marche la plupart du temps » signifie en pratique qu’il n’y a pas d’indicateur réel de fiabilité, pas de nombre de 9
  • Je viens de convertir d’un coup une appli Python en Go avec Codex (gpt-5-high) pendant que je promenais le chien. J’ai testé le résultat et ça fonctionne bien. Je suis content de pouvoir désormais déployer un binaire unique sans environnement virtuel. Je ne sais pas si la consigne était vraiment très simple
  • Pour moi, « ça marche la plupart du temps » ne suffit pas. Plus grave encore que le non-respect des consignes, il y a le fait qu’ils refusent souvent d’admettre qu’ils se trompent et s’entêtent au contraire dans l’erreur. Dès que je leur demande quelque chose d’un peu moyennement complexe ou une analyse d’erreur, ils s’accrochent assez souvent à de mauvaises conclusions. Souvent, ils ne trouvent aucune issue tant que je ne pointe pas moi-même le problème. Ils sont vraiment bons pour du code simple ou du boilerplate, et avec un peu de feedback j’ai même pu créer de nouvelles bibliothèques. Mais comme ils se trompent souvent, je n’ai pas envie de leur confier quelque chose de plus complexe. Cela dit, quand je bloque, je les utilise pour générer des idées, et même quand c’est faux, ça aide à se remotiver
• Quand les expériences des développeurs avec les LLM divergent autant, la vraie question qu’on devrait se poser est : « Pourquoi les expériences sont-elles si différentes ? » L’explication du type « tu ne sais juste pas bien t’en servir » est la plus simple, mais en tant que développeur de systèmes IA, je suis aussi frappé par le nombre d’utilisateurs qui se contentent d’écrire « corrige ça » ou « fais-moi un rapport » sans consignes complexes puis s’attendent à un résultat. Il y a aussi un battage excessif des dirigeants du genre « l’IA peut tout faire », lié à la valorisation et au cours de l’action. Le grand public semble aussi considérer l’IA comme une « vraie intelligence artificielle ». En réalité, l’idée que les LLM ne savent même pas suivre des consignes simples me paraît peu crédible ; le vrai point, c’est qu’ils restent incapables de bien gérer les tâches complexes
  • Mon autre théorie, c’est que chacun a une spécification dans sa tête, l’écrit de façon désordonnée en espérant que le LLM l’implémente, puis constate que le résultat final ne correspond pas à cette spécification. Certains développeurs réajustent mentalement cette spécification après coup ou acceptent simplement de petits écarts, alors que d’autres sont déçus parce que le LLM n’a pas reproduit leur plan mental. C’est un peu comme un faux souvenir psychologique : certains sont plus souples et conciliants, d’autres plus rigides. Moi-même, je passe alternativement par ces deux états
  • J’aimerais maintenant voir davantage de screencasts, de longs billets, n’importe quoi montrant l’intégralité du processus par lequel quelqu’un construit réellement une fonctionnalité non triviale. Les influenceurs IA montrent presque toujours des outils IA pour fabriquer d’autres outils IA, ou bien des démos CRUD et hello world. Même les développeurs chevronnés qui disent que plus de la moitié de leur codebase a été produite par l’IA finissent par préciser qu’en pratique ils jettent presque tout et n’en gardent qu’une inspiration partielle. Les histoires du type « un seul prompt → une appli terminée » se transforment très vite en « c’est utile quand on a besoin de motivation devant une page vide ». J’aimerais qu’on partage de façon plus transparente la manière dont les vrais développeurs en production s’en servent réellement
  • En fait, la catégorie « développeur » est tellement large qu’elle n’a pas beaucoup de sens dans cette discussion. Pour assembler la plupart des petits morceaux de code de type CRUD, les LLM s’en sortent plutôt bien
  • Tout le monde travaille sur des tâches différentes dans des codebases différentes. On parle très peu de ce détail pourtant essentiel. Plus on les utilise souvent, plus le niveau d’attente monte et plus on ressent vite leurs limites. À l’usage occasionnel, c’est impressionnant ; à longueur de journée, la déception finit par s’accumuler. Même des choses dont on se dit « ça devrait être capable de faire ça » demandent souvent une reprise manuelle
  • Je suis convaincu que ce ne sont pas les résultats qui diffèrent, mais les attentes de chacun. Le SVP IT de ma boîte est un fervent défenseur de l’IA. En travaillant récemment sur un vieux projet PHP qu’il avait créé, j’ai réalisé que le niveau de qualité du code qui le satisfait d’ordinaire est extrêmement bas. J’utilise moi aussi des LLM tous les jours, mais je retouche toujours le résultat. Autrement dit, plus on tolère un code de faible qualité, plus on est satisfait de la sortie d’un LLM
• Sur le forum Cursor, on répète sans cesse « c’est toi qui l’utilises mal », mais ce qui m’intéresse vraiment, c’est la fiabilité, le processus et l’usage réel en production. Ici aussi, j’ai au final l’impression qu’on voit très peu de cas d’usage à grande échelle. Nous aussi, on utilise surtout l’IA comme un « collègue un peu idiot », et on l’emploie de façon plus expérimentale sur des side projects avec peu de contraintes. Les agents me donnent surtout l’impression d’être du hype, ou de ne servir qu’à des cas très de niche
  • Si l’OP obtient de mauvais résultats, c’est parce qu’il utilise Cursor. Cursor coupe brutalement le contexte des conversations pour réduire ses coûts. Contrairement aux fournisseurs de modèles, il doit payer l’usage des LLM au prix de détail, ce qui le place en mauvaise posture sur le plan tarifaire. Cursor n’est pas transparent sur l’ampleur de ce découpage du contexte, et d’après mon expérience il le fait de manière vraiment agressive, au point qu’il faut lui redonner sans cesse les mêmes fichiers pour qu’il comprenne ce qui se passe. Mon conseil : arrête de perdre du temps avec Cursor. Le code produit par Cursor ne crée que de la dette. Depuis que je suis passé à Codex et Claude, je suis bien plus satisfait
  • Je serais curieux de savoir quelles améliorations concrètes sont attendues. Le post d’origine ne donne aucun exemple précis, aucun prompt, aucune méthodologie, juste « je sais bien écrire des prompts », ce qui rend toute évaluation ou tout conseil difficile. Je comprends aussi le scepticisme de départ envers les workflows agentiques, mais au fond cela ne laisse pas vraiment aux autres l’occasion de répondre sérieusement. Moi aussi je travaille avec des agents depuis plusieurs mois et j’apprends encore ce qui fonctionne et ce qui échoue. D’après mon expérience :
    • l’orchestration est indispensable avec des frameworks comme agent-os
    • il est important de trouver un équilibre entre supervision et autonomie
    • surtout sur du code legacy, la planification en amont est vraiment essentielle
    • mon exemple : dans un système legacy, je dépassais sans cesse la fenêtre de contexte, et quand je réorganisais le contexte, des informations essentielles disparaissaient, ce qui faisait répéter les mêmes erreurs
    • ce qui a marché : structurer clairement le problème, consigner méthodiquement tout ce qu’on découvre et apprend, et découper en sous-agents très spécifiques pour pouvoir gérer la fenêtre de contexte. C’est à ce moment-là que les agents sont devenus réellement utiles pour explorer du code legacy
  • J’ai déjà eu des agents qui ont trouvé plusieurs bugs de production que je n’arrivais pas à repérer moi-même, faute de temps suffisant pour creuser des bugs inhabituels. Bien sûr, il y a encore beaucoup plus de bugs qu’ils ne trouvent pas, mais comparé à une heure de travail d’un ingénieur logiciel, c’est quasiment gratuit ; si ça marche de temps en temps, c’est déjà une stratégie exploitable
  • Un billet avec des exemples concrets et utilisables aurait bien plus de valeur et susciterait de meilleures réponses. Montrer un vrai problème de production et la manière dont le LLM a échoué serait bien plus utile
  • La valeur business réelle est bien plus faible que ce que les gens imaginent, et c’est frustrant. Oui, sur le boilerplate ou dans des domaines familiers, cela peut parfois mieux écrire qu’un humain. Mais les autres problèmes sont trop importants : dépendance aux Big Tech, contamination des données, informations invérifiables, baisse de créativité, effondrement de l’originalité, ignorance des fanatiques de l’IA, consommation énergétique, pillage des créations humaines, etc. J’ai du mal à comprendre qu’on puisse croire que tout cela représente un bénéfice net pour l’humanité
• En 2025, le marketing fonctionne très bien sur Reddit, LinkedIn et tous les forums, au point que les marques s’infiltrent directement dans les conversations. Les CEO, les « penseurs » de l’IA et les VC présentent les LLM comme de la magie et vendent v0, Lovable, etc. comme la prochaine grande révolution. Les réponses des dirigeants se ressemblent toutes (vidéo liée). Mais en pratique, on peut bien écrire autant de fichiers CLAUDE.md ou de cursorrules qu’on veut, ça n’a presque aucun effet. Au final, encore faut-il que le LLM suive les consignes, et en réalité son comportement semble aléatoire. Il ne respecte presque même pas les règles les plus simples, ce qui me donne l’impression que les gens qui postent sur le forum Cursor sont tous des amateurs. Et puis, les nouveaux développements de code, les LLM sont vraiment mauvais là-dessus. Ils supposent l’existence de bibliothèques qui n’existent pas et génèrent juste du texte inutile. Moi, je les utilise littéralement comme du speech-to-text : en revanche, ils repèrent mieux que moi certains edge cases oubliés, des bonnes pratiques que je ne connais pas, ou encore la syntaxe.
  • [1] Les résultats dans la recherche, Perplexity, etc. sont pour la plupart des amas de contenu marketing diffusés par des équipes marketing
  • Je suis complètement d’accord sur le fait que les LLM sont vraiment horribles pour les nouvelles tâches de codage. Les modèles SOTA actuels savent souvent produire du boilerplate ou des structures simples dans des frameworks très connus avec des patterns cohérents comme MVC. Leur point fort, c’est surtout de parcourir beaucoup d’informations pour retrouver quelque chose dans une codebase, des logs, une stack trace, etc. Mais le marketing qui prétend qu’un agent peut construire toute une codebase, pour l’instant, je n’y crois pas une seconde
  • Mon expérience est totalement inverse. Cette dernière semaine, Claude Code a presque corrigé de manière autonome des problèmes de compilateur dont j’ai la charge. À part quelques moments frustrants, il a corrigé de façon constante des bugs subtils de génération de code et de parser, et mes interventions relevaient surtout davantage de limites de l’outil, comme la gestion de la compaction. Il a même implémenté des méthodes qu’on ne connaîtrait qu’en allant chercher dans des livres, et j’ai vérifié qu’elles fonctionnaient réellement à l’exécution. Il y a sans doute peu de choses complètement nouvelles et vraiment « innovantes », mais en réalité presque aucun code n’est vraiment nouveau. D’après mon expérience, si on lui donne un guide bien structuré, il suit globalement très bien. Il ne suffit pas d’écrire vaguement quelque chose dans CLAUDE.md. La clé, c’est une orientation minutieuse sur le processus. Ma façon de travailler se décompose en 1) un guide de débogage propre au projet, 2) une clarification des critères d’acceptation, 3) des exécutions fréquentes des tests, en lui faisant documenter dans des fichiers chaque petit changement par unité. Avec ça, je peux laisser Claude travailler presque sans supervision pendant des heures, en me contentant de lui dire « continue » de temps à autre ou d’utiliser /compact. Il ne produit pas un code parfait à chaque fois, mais moi non plus. Malgré tout, cela mène généralement à des évolutions positives et réduit énormément mes efforts. Je ne recommanderais pas encore de bootstrapper un système sans conception claire, mais parfois il y arrive quand même, à condition de faire une revue en amont. Ces temps-ci, j’en suis même à envisager de laisser Claude résoudre automatiquement des problèmes pendant plusieurs jours d’affilée
  • Je trouve vraiment fascinant que l’expérience avec les LLM puisse varier à ce point. Dans mon cas, j’ai l’impression d’avoir multiplié ma productivité par 5 avec codex-cli. Il a très bien réussi à convertir des sources à la structure très inhabituelle et des traces d’exécution SVG internes vers un format de graphe JSON personnalisé, ou encore à extraire correctement de la documentation d’une codebase Python/C++ complexe, jusque dans un noyau RISCV bas niveau. Je me demande vraiment pourquoi on obtient des résultats aussi différents avec le même outil
  • Avec Claude pour coder, j’ai l’impression de tirer sur un bandit manchot. Parfois il sort exactement ce que je veux, mais bien plus souvent ce n’est pas ça du tout, ou c’est complètement à côté. Le laisser fonctionner seul sans surveillance serait absolument dangereux
  • De mon point de vue aussi, la valeur la plus constante des LLM est leur capacité à repérer les petites erreurs que les humains laissent souvent passer, les meilleurs exemples à suivre, ou encore la syntaxe du code. Comme relecteur de PR, c’est pas mal à prendre, avec les réserves d’usage
• Dans notre entreprise, on applique une approche XP classique. Quand on développe une nouvelle fonctionnalité dans une application brownfield, on découpe le travail en près de 8 sous-agents comme « red-test-writer », « minimal-green-implementer », « refactorer », etc. Désormais, il suffit de dire à Claude Code « implémente la fonctionnalité X avec ce processus TDD » et, en 30 minutes, il produit un code bien meilleur, avec 90 % de couverture de tests, dans un état immédiatement acceptable. Cela s’appuie certes sur des années d’expérience en XP, pair programming et TDD, mais depuis plus d’un an, 95 % de notre code de production est écrit par l’IA, y compris des fonctionnalités complexes non triviales. Il n’y a pas vraiment de savoir-faire secret : chez nous, ça marche très bien
• Les avis divergent énormément ici. Sans préciser ce sur quoi chacun a échoué ni le type de tâches concernées, il est impossible d’avoir une discussion sérieuse. Tant qu’on ne parle pas des catégories précises dans lesquelles les LLM réussissent ou échouent, ce n’est guère plus que du bruit
  • Dans ce genre de débat, il faudrait détailler le langage/framework, le domaine du problème, le niveau SRE, le LLM (modèle/version), le harness agentique (Claude Code, Codex, Copilot, etc.), les cas de réussite/échec, ainsi que le niveau de maîtrise du LLM. Les conditions peuvent aussi varier selon que l’ingénieur travaille depuis 10 ans sur une seule codebase ou alterne entre plusieurs projets, qu’il soit en greenfield ou en maintenance, en recherche innovante ou sur du CRUD, etc.
• Du point de vue d’un scientifique, il faut souvent répéter un boilerplate légèrement différent pour chaque dataset, et les agents de codage résolvent en grande partie ce problème. Cela dit, même si j’écris cinq fois en majuscules « n’invente surtout pas de données, n’utilise pas np.random », Claude l’ignore parfois. C’est étonnamment absurde. Quand ça marche, c’est fantastique ; quand ça échoue, il n’y a même pas de signal clair d’échec. Vu sous l’angle du marketing LLM, j’imagine même un agent du type « PIPA » (Performance Improvement Plan Agent) qui surveillerait en temps réel l’agent de codage pour vérifier qu’il travaille correctement. PIPA contrôlerait les performances de l’agent de codage afin que les RH ou la direction puissent gérer les employés IA, et c’est peut-être comme ça que l’avenir arrivera
  • Si je te dis « Ne pense pas à un éléphant en tutu rose ! », tu y as pensé, non ? En tant que scientifique, tu devrais savoir que les LLM comprennent mal les tournures négatives. Ils sont entraînés token par token, donc même si on écrit « NO ELEPHANTS », le mot « éléphants » reste dans le contexte. Cela les pousse au contraire vers ce terme. Il vaut mieux formuler les consignes de manière positive
  • Rien que d’imaginer PIPA me fait peur
• La clé, ce sont les prompts permettant au modèle de retrouver de lui-même le bon contexte, par exemple avec de bons messages d’erreur, et le découpage des tâches en unités très petites et régulières afin de transmettre les résultats des tests itératifs et par étapes comme contexte pour la tâche suivante. Environ 50 % des problèmes se prêtent à cette approche, et pour 50 % d’entre eux, la boucle LLM est moins pénible que l’automatisation traditionnelle, mais la moitié de ceux-là ne valent même pas vraiment l’investissement. En fin de compte, s’il existe un « magique 12,5 % » de cas où cela marche, alors une approche agentique fortement contrainte est la meilleure
  • Ce serait une bonne source d’enseignements de diffuser ce processus tel quel en direct sur YouTube ou ailleurs, en live coding naturel et pas en tutoriel
• Il y a presque 30 ans, quand j’ai débuté en IA, on m’avait dit ceci : quand tu entends le terme « intelligent agent », pense à une « fourmi entraînable »
  • J’aimerais bien en savoir plus
• Pour moi, le plus gros problème est que les performances des outils IA varient énormément selon les tâches, et qu’il est difficile de prévoir où ils vont échouer, ce qui me fait perdre du temps. J’ai l’impression qu’avec plus d’expérience sur ces outils je deviendrai meilleur en prompt, mais cela reste frustrant. Cela dit, il y a un chevauchement entre les domaines où les agents et l’IA sont utiles, par exemple la génération automatique du boilerplate d’un nouveau projet. Dans ce cas, le « mode agent » est plus confortable. Je manque encore d’expérience concrète en conditions réelles
  • Plus ça fonctionne bien, plus les attentes montent et plus on élargit les usages ; puis quand on se heurte aux limites, la déception devient encore plus forte qu’au début