Recommandations pour le codage agentique

• Partage de cas d’usage concrets autour du codage agentique
• Utilise principalement le modèle Claude Code Sonnet et préfère confier l’ensemble du travail à l’IA plutôt que de passer par une intégration IDE
• Le langage Go est particulièrement recommandé pour les nouveaux projets backend grâce à sa structure adaptée aux agents et à la stabilité de son écosystème
• La vitesse et la simplicité sont au cœur du codage agentique, avec une importance particulière pour le cache de tests et une boîte à outils simple
• Le code doit être simple et parallélisable ; pour maximiser les performances de l’agent, le choix du bon moment pour refactorer est crucial

---

Préface

• Le nombre de développeurs partageant récemment leur expérience du codage agentique a fortement augmenté
• J’utilise actuellement le modèle Claude Code Sonnet avec l’abonnement Max (100 $/mois)
• L’IDE a perdu en importance ; à la place, je me suis remis à Vim, en confiant les tâches à Claude puis en vérifiant simplement le résultat
• Le rythme de l’innovation est très rapide, donc le contenu de ce billet peut vite devenir obsolète ; je me concentre donc sur des concepts plus durables

Les bases

• La commande claude --dangerously-skip-permissions est définie en alias sous claude-yolo afin de supprimer toutes les restrictions de permissions
  • Cela reste gérable en isolant de manière sûre l’environnement de dev avec Docker
• Comme Claude maîtrise bien la plupart des outils de base, MCP (Multi Capability Protocol) n’est utilisé que dans des cas particuliers
  • Exemple : automatisation du navigateur via playwright-mcp
• Les outils maison sont construits comme de simples scripts, en conservant autant que possible une boîte à outils très simple

Choix du langage

• Après avoir expérimenté le codage agentique dans plusieurs langages, Go s’est révélé le plus adapté pour les nouveaux projets backend
  • Système de context : fournit une structure de données claire qui traverse tout le code, ce qui facilite une transmission explicite à l’agent
  • Cache de tests : par rapport à Rust et à d’autres langages, l’exécution des tests et leur cache sont plus simples, ce qui rend la boucle code-test de l’agent plus efficace
  • Simplicité : la simplicité propre à Go joue aussi en faveur de l’agent
  • Interfaces structurelles : si les méthodes correspondent à un type, celui-ci est reconnu comme interface, ce que les LLM gèrent facilement
  • Faible taux de changement de l’écosystème : versions durables et changements explicites, ce qui réduit la génération automatique de code obsolète
• Python entraîne de nombreux problèmes
  • Les fixtures, l’async, la lenteur d’exécution, etc., réduisent l’efficacité dans une boucle agentique
• Pour le frontend : Tailwind + React + Tanstack Query/Router + Vite
  • Le symbole $ présent dans les noms de fichiers de Tanstack Router perturbe les agents et provoque des problèmes

Tools, Tools, Tools

• Les critères de choix des outils sont les suivants
  • Être rapides
  • Fournir des messages d’erreur clairs
  • Rester robustes même si le LLM les utilise mal
  • Être observables et faciles à déboguer
• Des commandes comme make dev, make tail-log, etc. sont fournies via un Makefile
  • Une version forkée de shoreman gère les PID afin d’éviter les doublons d’exécution
  • Les logs sont écrits à la fois sur stdout et dans des fichiers pour que l’agent puisse extraire directement l’information depuis les logs
• Exemple : les liens de vérification d’e-mail sont eux aussi enregistrés dans les logs afin de permettre une procédure de validation e-mail via automatisation du navigateur

Tout repose sur la vitesse

• La plus grande inefficacité du codage agentique vient du coût de raisonnement et d’un usage inefficace des outils
• La rapidité de réponse des outils est au cœur de la productivité
• Quand l’agent crée et utilise lui-même des outils temporaires, la rapidité d’exécution/compilation améliore fortement l’efficacité du travail
• Dans les environnements lents, il est avantageux de recourir à des alternatives comme le chargement dynamique de modules (par ex. surveillance de modules de fichiers pour Sentry et exécution automatique)
• Les logs doivent rester concis et clairs afin d’optimiser la consommation de tokens et la vitesse ; fournir si besoin une interface permettant au LLM d’ajuster le niveau de logs peut aider
• Il est important de concevoir dès la phase de génération du code une observabilité et des logs réellement utiles

Stabilité et copier-coller

• La stabilité de l’écosystème est très importante pour la réutilisabilité du code et la prévention de la confusion côté agent
  • Il est recommandé d’utiliser des langages/frameworks peu volatils et prévisibles comme Go et Flask
• Attention aux mises à niveau automatiques de bibliothèques : elles peuvent casser les commentaires laissés par l’agent ou la logique du code
• Dans la mesure du possible, il est recommandé d’adopter une stratégie écrire soi-même le code → minimiser les dépendances

Écrire du code simple

• Les agents se débrouillent mieux avec un code simple et explicite
• Recommandations
  • Préférer des fonctions aux noms longs et descriptifs, et écrire surtout des fonctions plutôt que des classes
  • Éviter l’héritage et les astuces trop complexes
  • Recommandation d’utiliser du SQL pur ; les agents sont à l’aise en SQL, et cela facilite la comparaison et la traçabilité dans les logs
  • Les vérifications d’autorisations explicites doivent apparaître de manière intuitive dans le code (éviter de les séparer dans des fichiers ou configurations distincts)

Le rendre parallélisable

• La vitesse de traitement d’un agent individuel n’est pas très élevée, mais le traitement en parallèle permet d’améliorer l’efficacité globale
  • Exemple : duplication de checkout basée sur le système de fichiers
  • Il faut réfléchir à la manière d’isoler les ressources partagées comme Redis ou la base de données
  • Outil d’exemple : isolation de sessions basée sur Docker avec container-use
• Le travail parallèle fondé sur la CI, ainsi que des outils comme le background agent de Cursor, méritent aussi l’attention

Apprendre à refactorer

• Dans une approche agentique, refactorer au bon moment est essentiel
  • Quand la complexité augmente, l’agent n’arrive plus à manipuler correctement le code
  • Exemple : transformer en bibliothèque de composants avant que des classes Tailwind ne se dispersent dans 50 fichiers
• Refactorer trop tôt comme trop tard est inefficace ; il faut donc demander des améliorations structurelles au bon moment

Et ensuite ?

• Le codage agentique évolue rapidement, et les principes clés sont la “simplicité, la stabilité, la visibilité et le parallélisme”
  • Même si les outils et les méthodes changent, ces principes restent valables
• L’objectif n’est pas seulement d’améliorer la productivité, mais aussi de viser une meilleure qualité de code
• La qualité du code produit par les agents s’est nettement améliorée par rapport à il y a quelques mois
• S’adapter avec souplesse aux changements et élargir son expérience de développement

[helloppfm]

Moi aussi, pour l’instant, je me contente surtout de demander à l’IA des tests simples ou des exemples de code, mais de plus en plus de gens essaient désormais de l’appliquer de manière globale.

C’est peut-être encore un peu prématuré, mais dans quelques années, ce sera sans doute devenu tout à fait normal.

[GN⁺]

Avis sur Hacker News

• J’expérimente le coding agentique dans VS Code Nightly en utilisant à la fois Copilot et Claude Sonnet 4. Même quand la moitié de ma journée est remplie de réunions, on ne le devinerait pas en regardant simplement mon historique git tellement le gain de productivité est sensible. Désormais, au lieu de m’attarder sur les détails d’implémentation, je réfléchis surtout à si le changement fonctionne correctement, si ce code est compréhensible, comment structurer les choses pour le rendre encore plus lisible, et ce que je pourrais ajouter à un Markdown de conventions IA pour réduire les malentendus de l’agent. Hier soir, j’ai confié à l’agent un fichier qui avait 38 erreurs mypy, puis je suis parti discuter 15 minutes avec ma famille ; à mon retour, l’agent m’avait résumé ce qu’il avait corrigé et pourquoi. On a même débattu d’une des modifications, mais j’ai fini par juger que l’agent avait raison. Le check mypy passait aussi. Maintenant, j’essaie aussi de faire comprendre à mon équipe le vrai potentiel de cette technologie, même si certains restent sceptiques ou s’y opposent parce que l’IA n’est pas parfaite. Mais pour reprendre la formule d’un ami : « aujourd’hui est le pire jour que toi et cette technologie aurez jamais à vivre », et je pense que c’est justement la preuve d’une innovation

  • Les erreurs de type checker sont en pratique l’un des aspects sur lesquels on devrait passer le moins de temps dans une journée de développement, donc je me demande pourquoi ça t’a pris autant de temps. Je pense que toutes les discussions sur l’usage de l’IA auraient beaucoup plus d’impact si on pouvait voir concrètement à quelles tâches chacun l’applique réellement (comme dans le billet de Cloudflare)

  • Personnellement, je fais plus confiance à l’agent sur du code Rust que sur du Python. En Python, l’analyse statique n’est pas au niveau de clippy ou de rust-analyzer, donc il faut exécuter soi-même tous les chemins de code à chaque fois

  • Tu dis qu’on ne le verrait pas dans l’historique git même si la moitié de ta journée est prise par des réunions, mais si j’étais ton employeur, je garderais bien à l’esprit que je vais bientôt m’attendre à ce niveau de production en permanence

  • Je suis curieux de connaître ton workflow. J’utilise Claude Code à titre expérimental sur des projets perso, et avec mon compte pro j’ai aussi testé Copilot dans le mode agent de VS Code en mélangeant 3.5, 3.7 Sonnet et jusqu’à o4-mini. Je l’ai utilisé sur un gros projet Go, et en dehors des tests, le résultat a été catastrophique. Je me suis demandé si j’utilisais mal l’outil, donc j’ai essayé toutes les « best practices » récentes : changer le contexte, changer de modèle, définir des règles, améliorer les prompts, tout. Malgré ça, aucune amélioration

  • Tu disais qu’on pouvait ajouter des éléments dans un Markdown de conventions IA pour réduire les erreurs de l’agent ; je me demande s’il s’agit d’un fichier joint au contexte pour chaque tâche, ou bien d’une convention officielle du Copilot Agent de VS Code. Et j’aimerais aussi savoir si tu t’es appuyé sur des références pour structurer cette documentation, ou si c’est quelque chose que tu as fait évoluer toi-même au fil du temps à partir des erreurs récurrentes de l’IA

• Il est vraiment encourageant de voir que la plupart des techniques qui rendent le coding agentique efficace améliorent aussi l’efficacité du codage humain. Avant, il y avait cette crainte d’un code « énorme tas de boue » compréhensible seulement par l’IA, mais en pratique c’est l’inverse. Un code clair est devenu encore plus important pour la productivité de l’IA, et cela permet même de quantifier très nettement les écarts de productivité. Comme Claude permet de montrer numériquement à quel point il fonctionne bien selon les codebases, la question de savoir si le code est bien structuré peut désormais se discuter sur une base objective plutôt que comme simple différence d’opinion

  • L’inquiétude autour du code qui devient un « tas de boue » existe en fait depuis toujours en programmation (voir les conférences de Rich Hickey). Les gens choisissent souvent la facilité immédiate et se retrouvent avec une dette technique énorme le lendemain. Avec les LLM, il devient aussi plus facile de produire du boilerplate en masse sans réel sens. Si la douleur diminue, on risque aussi de perdre toute envie de corriger le problème

  • Je tenais aussi à laisser cette remarque : « la crainte d’un code que seule l’IA comprend n’est peut-être pas justifiée aujourd’hui, mais on ne sait pas ce qu’il en sera plus tard »

  • Je me reconnais vraiment là-dedans. De bons messages d’erreur, des outils rapides, un écosystème stable, du code simple sans trop de « magie », du SQL intuitif : c’est exactement l’environnement de développement dont j’ai toujours rêvé. Comme les agents travaillent très vite, le moindre petit délai devient perceptible, donc je pense que ce type de technologie peut réellement élever le niveau global de l’expérience de développement

• J’entends dire qu’utiliser des agents pousse naturellement vers Go et Tailwind, simplement parce que l’IA sait bien les manipuler grâce à l’abondance des données d’entraînement. Du coup, je me demande si, dans un futur où tout le monde utilise ces outils, il ne deviendra pas plus difficile de voir émerger de nouveaux langages, frameworks ou bibliothèques. Il pourrait devenir plus dur de rivaliser avec les solutions existantes, et des communautés humaines comme Stack Overflow pourraient aussi disparaître

  • Je ne suis pas d’accord avec l’idée que de nouveaux langages ou frameworks ne pourront plus émerger. Les LLM sont extrêmement forts en traduction, donc même sans données d’entraînement, ils savent apprendre très vite à partir d’une codebase dès lors qu’un framework, même original, a une structure claire. J’en ai fait l’expérience avec mon framework C# idiosyncratique, que personne n’avait jamais vu, et les LLM s’en sortent très bien. Bien sûr, des spécificités comme les lifetimes de Rust ne seront pas forcément assimilées immédiatement, mais pour quelque chose de simple comme Go, ils s’adaptent vite. À l’avenir, il faudra peut-être concevoir les nouveaux langages en tenant explicitement compte de leur compatibilité avec les LLM — design, tooling, documentation, etc.

  • C’est une question vraiment importante. Dit autrement, à mesure qu’Internet se remplit de données générées par des LLM, les bonnes données d’entraînement vont se raréfier, et les développeurs sensibles à l’écosystème LLM pourraient être davantage attirés par des technologies anciennes, moins « radioactives » (JS/React, par exemple). JavaScript/React pourrait devenir le COBOL du futur, mais sans avoir besoin de consultants hors de prix, parce que les LLM pourront assurer toute la maintenance. Si on veut éviter la vague IA, alors créer de nouveaux langages — surtout des langages atypiques comme Lisp+DSL que les LLM ne peuvent pas assimiler immédiatement — pourrait rester une stratégie assez sûre jusqu’à l’ère de l’AGI

  • Le cycle traditionnel des stacks logicielles a toujours été le suivant. (1) Une stack existante grossit, absorbe tous les cas de niche et devient complexe, au point que les experts y multiplient des « architectures » inutiles. (2) En réaction, une nouvelle stack beaucoup plus simple et claire arrive, résout mieux la tendance du moment et gagne en popularité. (3) Puis, avec le temps, cette nouvelle stack s’alourdit à son tour pour les mêmes raisons, et le cycle recommence. Avec le coding IA, le contexte disponible s’élargit vite, donc je ne pense pas que ce cycle soit près d’être cassé

  • L’idée qu’on serait forcé d’aller vers Go et Tailwind reflète en réalité beaucoup les préférences personnelles de l’auteur. Ce n’est pas parce que Sonnet a des problèmes avec la CLI cargo test qu’il faut conclure que Rust, cargo, ou plus largement l’IA entière, sont en cause. En pratique, sur les tests PHP aussi, Junie n’utilise pas très bien le runner intégré, mais si on lui fournit un script bin/test-php, il l’emploie sans problème. Il est certes utile d’indiquer explicitement les exigences dans les guidelines, mais la vraie différence est surtout sa tendance à privilégier les outils fournis par défaut. Quant à l’expérience Stack Overflow, mon assistant IA a au moins l’avantage de ne pas fermer mes questions comme doublons. Les efforts de curation de SO ont du bon, mais ils ont aussi, de fait, fait fuir beaucoup d’utilisateurs

  • Hier encore, j’ai demandé à Claude (via Zed) de créer un nouveau projet Elixir Phoenix à partir de simples contraintes, et il l’a fait sans problème. Il a utilisé Tailwind pour le CSS, mais je pense que c’est simplement parce que Phoenix l’initialise par défaut. Je ne partage pas l’idée que l’IA pousse vers Go. Au contraire, quand on demande quelque chose sans contexte, elle déborde souvent de suggestions Python, et même avec Elixir, dont la communauté est bien plus petite, j’ai une très bonne expérience

• J’ai expérimenté pendant environ une semaine du code Rust avec Claude Code Sonnet 4.0, et c’était en dessous de mes attentes (en plus c’est cher en passant par Bedrock). Il passe beaucoup de temps à planifier au départ, mais au final il n’accomplit souvent que la moitié du travail. Je me demande si je rate quelque chose

  • J’ai à peu près le même ressenti. En mode Edit/Agent de Cursor, j’obtiens presque d’un coup les modifications que je veux, donc c’est extrêmement efficace, mais en environnement CLI c’est trop pénible. Je me demande si tu utilises Claude Code en lui confiant 10 à 15 minutes de travail avant de ne relire que le diff, ou si tu fais aussi une vraie revue de code

  • J’ai eu exactement la même expérience. Même en cherchant volontairement des cas d’usage où ça pourrait être utile, ça ne fonctionnait pas correctement, ce qui m’a vraiment surpris

  • Il ne faut pas trouver ça cher. Le plan Pro est à 20 dollars par mois, et Max à 100–200 dollars ; c’est moins coûteux que de l’utiliser via API et de dépasser les mille dollars mensuels

• Je suis plutôt content de voir les conteneurs mentionnés. Je contribue à dagger/container-use, et notre équipe compte aussi d’anciens membres de Docker ainsi que le fondateur de Docker. Je pense que faire tourner les agents en parallèle sera un point de bascule majeur dans le progrès technique, à condition qu’on sache le faire de manière fiable. En attendant, si l’on veut faire autre chose pendant qu’un agent travaille, ou si l’on craint qu’il touche à des zones du projet où il ne devrait pas aller, conteneuriser l’environnement de développement est extrêmement utile. L’usage des conteneurs en est encore à ses débuts, mais ça évolue très vite, avec pour priorités actuelles la stabilité, la réduction des conflits git et l’amélioration des interactions entre humains et agents

• Voici mon opinion sur le choix du langage. 1) Java est le plus complet pour les LLM grâce à l’ampleur et à l’ancienneté de son dataset de référence (ça ne veut pas forcément dire le plus précis). 2) Surtout, il faut travailler dans le langage que l’on maîtrise le mieux, afin de repérer rapidement les erreurs de raisonnement, les bugs et les hallucinations du LLM

  • L’idée selon laquelle Java bénéficierait du dataset le plus vaste, le plus ancien et le plus clair me semble n’être valable que si le LLM n’a pas accès à des outils lui permettant de consulter API, documentation et code source tiers. Si les outils permettent de déterminer automatiquement quoi utiliser, alors le langage choisi importe moins du moment que l’agent peut lire les sources. En revanche, je suis entièrement d’accord avec le deuxième point : une vérification humaine minutieuse reste indispensable, et connaître le langage facilite énormément le jugement sur les erreurs

  • Pourquoi Java aurait-il le plus grand dataset ? Est-ce parce que c’est le langage le plus représenté dans l’open source (à cause de toute la suite Apache, par exemple) ? Ou bien parce que la documentation des bibliothèques open source Java est particulièrement abondante ?

  • J’ai toujours pensé que Python devait être le langage le plus présent dans les datasets. Quand on ne précise rien, les LLM ont d’ailleurs tendance à recommander Python en premier

• L’affirmation selon laquelle le système de context de Go (conçu pour faire circuler explicitement des données le long des chemins d’exécution) apporterait de la simplicité aux agents IA suscite cette critique : « mettre autre chose que des données de tracing dans context.Context est en réalité une mauvaise pratique »

  • D’accord. Dans chromedp (le driver headless Chrome pour Go), context.Context est utilisé comme premier argument, mais la structure impose d’utiliser non pas un simple context.Background(), mais uniquement un context obtenu via une factory spéciale. On gère ensuite séparément le timeout avec context.WithTimeout, et au final on s’en sert presque comme d’un pointeur void*

  • Je ne suis pas expert Go, mais en pratique beaucoup de bibliothèques mettent dans le context des choses comme des connexions à la base de données, de la configuration, un rate limiter, un backend de cache, etc., donc pour l’instant ça ne me paraît pas si problématique

• « Écrire un code assez simple pour être compris par l’IA » n’est pas vraiment le point d’innovation que j’espérais. Je me demande aussi en quoi cela entre en conflit avec mon précédent billet sur le ugly code

  • Cette manière d’écrire du code simple et clair aide en réalité presque toujours dans le travail en équipe. Il y a parfois des moments où il faut se concentrer intensément sur le code ou faire preuve de créativité, mais ce sont des exceptions et cela doit rester étroitement lié à la valeur métier. Dans la plupart des cas, le bon choix est quelque chose « d’évident pour n’importe qui ». Si les développeurs sont lents, ce n’est pas à cause de la frappe, c’est à cause de la quantité de « concepts » qu’ils doivent garder en tête en même temps. Il ne faut pas surconcevoir les interfaces, il faut retarder les abstractions, autoriser le copier-coller et l’assemblage simple, appliquer les patterns comme dans la documentation officielle, ne jamais chercher à être trop malin. L’idée centrale, c’est que le code ne doit pas être « joli », mais clair et simple, et que la vraie difficulté se situe souvent moins dans le code lui-même que dans le « produit »

• Comme l’auteur l’a écrit à propos de Claude Code, il existe en pratique plusieurs alternatives (OpenCode, goose, Codex, Devin, Cursor background agent, etc.). Quelqu’un demande s’il existe des solutions open source + LLM locaux comparables à Claude Code

  • Pour l’instant, il n’y a pas vraiment de solution open source + LLM local que je recommanderais chaudement. Cela dit, OpenCode de SST évolue très vite côté UX, et si de meilleurs modèles locaux arrivent, il sera facile de les intégrer. Le plus gros problème, c’est qu’il existe très peu de bons modèles réellement performants en « usage d’outils ». Si Sonnet est aussi impressionnant, c’est justement grâce à un entraînement spécialisé sur ce point. Gemini reste encore très loin derrière ; à mon avis, c’est donc un problème qui se résoudra dès que de meilleurs modèles arriveront

  • Dans le cas d’Aider, on y est presque, mais l’outil n’est pas volontairement totalement agentique. Il sait déjà exécuter automatiquement les tests et l’analyse statique, corriger automatiquement les erreurs, et même gérer une spec de projet complète à partir d’une liste de tâches. Aujourd’hui, il y a une limite codée en dur sur le nombre de boucles de réflexion (3), mais on peut la contourner facilement, et si on lui ajoute du self prompting, il peut pratiquement devenir un agent entièrement automatisé

  • Je pense aussi que mon application à venir sera une bonne alternative. C’est un téléchargement en un seul fichier, sans installation, utilisable sur Mac, Windows, Linux et Docker. Elle fonctionne avec tous les modèles compatibles OpenAI API, y compris ceux qu’on exécute soi-même, et comme elle est basée sur le navigateur, elle est presque aussi pratique que Claude Code. On peut aussi créer des applis console pilotées par commandes. En plus, on peut ouvrir directement un terminal et le relier au service. C’est encore une alpha fermée, mais si ça vous intéresse, vous pouvez me contacter par e-mail

  • De nouvelles alternatives (ou tentatives) sortent presque tous les jours, donc je m’attends à ce qu’on dispose bientôt d’une alternative « parfaite ». Par exemple, app.build vient d’être lancé par l’équipe Neon (aujourd’hui chez Databricks) et semble assez prometteur

  • Le plugin Neovim CodeCompanion évolue lui aussi récemment vers quelque chose de plus agentique. Il prend déjà en charge une boucle d’auto-soumission, des outils intégrés et l’intégration MCP. Ce n’est pas un outil CLI autonome, mais le fait de disposer immédiatement d’un environnement d’édition complet est un avantage encore plus grand, surtout si l’on aime bricoler, personnaliser ou rester sur un éditeur léger

• 100 à 200 dollars par mois, c’est beaucoup trop cher pour une IA d’écriture de code encore non prouvée. Mon expérience personnelle n’a pas été très convaincante, et les controverses éthiques ajoutent encore une barrière à l’entrée

  • Claude Code peut s’utiliser avec une clé API, ou avec l’abonnement Pro à 20 dollars par mois

  • Je recommande d’essayer Aider avec une tarification à l’usage par API. On peut limiter la taille du contexte à environ 25K avec /clear, /add, /drop. On peut utiliser le modèle qu’on veut (par ex. Sonnet 4, Gemini 2.5 Pro). Pour des scripts simples, j’ai généralement pu finir pour moins d’un dollar, et même en construisant un très gros outil, prompts + code + une centaine de tests inclus, ça m’a coûté moins de 6 dollars. Une fois habitué à coder avec l’IA, je conseillerais alors de passer à Claude Code, plus puissant mais aussi plus cher si on ne l’utilise pas souvent

  • Avec un abonnement mensuel à 20 dollars, on peut déjà tester quelques petits projets et voir si ça vaut la peine d’envisager ensuite le plan à 100 dollars. Ou bien on peut simplement attendre encore quelques mois et se baser sur les retours d’autres personnes qui l’utilisent réellement au quotidien