Patterns d’ingénierie agentique

• Guide qui synthétise les méthodes de développement à l’ère des agents de codage comme Claude Code et Codex et présente de nouveaux patterns d’ingénierie pour collaborer avec des agents
• Explique, à travers différents patterns, comment faire évoluer les habitudes de développement et les workflows dans un environnement où le coût d’écriture du code a chuté brutalement
• Organise de manière structurée les domaines clés du développement centré sur les agents, comme les principes, les tests, la compréhension du code et la conception de prompts
• Chaque pattern prend la forme d’un document orienté pratique, avec des exemples de code réels, des méthodes de travail et des cas d’usage de prompts
• Une ressource de référence concrète pour aider les développeurs de l’ère des agents de codage à concevoir systématiquement un environnement de développement fondé sur les agents et à en maintenir la qualité

---

Vue d’ensemble d’Agentic Engineering Patterns

• Guide qui rassemble des méthodes d’ingénierie efficaces pour développer avec des agents de codage (Claude Code, OpenAI Codex, etc.)
• Voir aussi le billet de présentation de Writing about Agentic Engineering Patterns
  • Document structuré pour accueillir en continu plusieurs patterns (chapitres), à la manière des « Design Patterns » traditionnels
  • Le thème central porte sur l’évolution des workflows et des modes de décision des développeurs dans un contexte où le coût d’écriture du code a fortement baissé
  • Le contenu est proposé non pas comme un billet de blog, mais comme un guide actualisable, destiné à s’enrichir progressivement

1. Principles

• Writing code is cheap now

  • Avec l’arrivée des agents de codage IA, le coût de production du code initial est devenu presque négligeable
  • Autrefois, comme écrire du code coûtait cher, le développement était centré sur la conception et la planification ; désormais, il est possible de tester immédiatement une idée directement dans le code
  • Même si le coût de génération du code a baissé, produire du bon code (tests, maintenabilité, etc.) a toujours un coût

• Hoard things you know how to do

  • Un actif essentiel pour les développeurs est l’accumulation de connaissances sur ce qu’il est possible de faire
  • Le guide insiste sur l’habitude de conserver et capitaliser des exemples de résolution de problèmes variés et de petites expérimentations de code sous une forme réutilisable
  • Le code et les exemples ainsi accumulés peuvent servir de matériel d’entrée très puissant lorsqu’on demande à un agent de codage de créer de nouvelles fonctionnalités

• Anti-patterns: things to avoid

  • Même lorsqu’il est généré par un agent, partager du code ou soumettre une PR sans relecture est un anti-pattern à éviter
  • Les descriptions de PR rédigées par un agent doivent elles aussi être vérifiées et corrigées par un humain
  • Pour ne pas faire perdre de temps aux reviewers, il faut fournir les tests, la procédure de validation et les raisons des choix d’implémentation

2. Testing and QA

• Red/green TDD

  • Le développement piloté par les tests (TDD) est un pattern particulièrement efficace lorsqu’il est utilisé avec des agents de codage
  • Si l’on écrit les tests en premier, l’agent peut générer du code dans le sens attendu pour satisfaire ces tests
  • Même avec des prompts minimaux, cela aide à produire un code précis et fiable

• First run the tests

  • Quand on travaille avec des agents de codage, les tests automatisés ne sont pas une option mais un prérequis
  • Dans un environnement où le coût de rédaction des tests a diminué, l’agent peut générer et corriger rapidement ces tests
  • Tant que le code n’a pas réellement été exécuté, on ne peut pas garantir son bon fonctionnement, d’où l’importance des tests

3. Understanding code

• Linear walkthroughs

  • Pattern consistant à lire dans l’ordre, du début à la fin, le code ou le projet produit par l’agent afin d’en comprendre la structure
  • Même sur un projet simple, il est possible d’apprendre de nouvelles techniques et architectures en suivant le flux du code
  • Face à l’inquiétude selon laquelle la génération de code par IA ralentirait l’apprentissage, le guide montre que l’exploration du code peut elle-même devenir une opportunité d’apprentissage

• Interactive explanations

  • Une manière de comprendre un code ou un système consiste à demander des explications à l’agent au fil d’un dialogue
  • En répétant les questions, on peut comprendre progressivement le fonctionnement et la structure du code
  • Ce pattern étend la compréhension du code à une forme d’apprentissage interactive

4. Annotated prompts

• GIF optimization tool using WebAssembly and Gifsicle

  • Inclut un exemple de prompt pour créer un outil d’optimisation de GIF basé sur WebAssembly et Gifsicle
  • Présente une méthode d’implémentation d’un outil monopage incluant HTML, JavaScript et CSS
  • Explique comment exploiter un agent de codage à travers des prompts réels et des exemples de code

5. Appendix

• Prompts I use

  • Recueil d’exemples de prompts pour agents de codage réellement utilisés
  • Synthèse de patterns de prompts pratiques applicables à différents types de tâches
  • Propose des modèles concrets à utiliser pour collaborer avec des agents

[GN⁺]

Avis sur Hacker News

• On a l’impression qu’on va encore refaire la même chose
  Des concepts simples et raisonnables — par exemple « écrire les tests d’abord », « créer de petits modules combinables » — risquent d’être emballés dans des noms compliqués, puis de servir à bâtir une industrie du conseil
  Sauf que cette fois, l’objet en question est une « machine qui parle ». On serait donc dans un monde où il suffirait de lui parler

  • COBOL promettait quelque chose de similaire. On disait que c’était un langage facile à lire pour les humains et qu’on n’aurait plus besoin de programmeurs, mais au final, pour découper les problèmes et les résoudre, il fallait quand même penser comme un programmeur. Autrement dit, le fait qu’un langage soit plus humain ne fait pas disparaître les programmeurs
  • J’ai l’impression qu’on va revoir le cycle des booms de l’IA. Aujourd’hui, si on critique, on nous répond qu’on « n’a pas compris », mais bientôt les problèmes vont éclater. En particulier, on va se retrouver avec « tellement de code généré par l’IA que ni les humains ni les IA ne pourront le gérer ». À ce moment-là, on reverra surgir les patterns et anti-patterns, ainsi que les consultants qui prétendent les résoudre
  • Le fait que l’IA parle et comprenne l’anglais réduit la clarté de l’interface. C’est puissant comme une CLI, mais on ne sait pas clairement quelle approche est efficace. Documenter et partager « quoi demander et comment le demander pour obtenir de bons résultats » est donc important. À condition que cela ne dégénère pas encore une fois en industrie du coaching OOP
  • Oui, c’est exactement ce qui va se passer, et cette fois beaucoup plus vite. Le cycle de dix ans blogueur → conférencier → livre → consultant → organisme de certification va se retrouver compressé en quelques années
  • Je ne suis pas d’accord avec l’idée que le titre de l’article soit trop compliqué. En revanche, le vrai problème, c’est le malentendu selon lequel « il suffit de le demander en langage naturel ». En pratique, les résultats varient énormément d’une personne à l’autre. On en revient donc à la leçon suivante : « les bonnes habitudes de développement pour les humains sont aussi bonnes pour l’IA ». L’IA ressemble à un humain, mais ce n’en est pas un. Elle a donc besoin de davantage d’explications

• J’aimerais poser la question à Simon — « dans un monde où le code est devenu bon marché, comment faut-il faire la revue de code ? »
  Les membres de l’équipe abordent ça en mode « ça marche, donc c’est bon », sans comprendre la structure. Les revues deviennent de plus en plus volumineuses, et je deviens le goulet d’étranglement. J’ai aussi réfléchi à utiliser un relecteur IA par procuration, mais je n’aime pas l’idée de perdre la sensibilité humaine

  • C’est un sujet vraiment passionnant. Si la génération de code devient plus rapide, alors la revue devient le goulet d’étranglement. Si le code est bon marché, on pourrait baisser les exigences de revue, mais pour ma part je veux au contraire une meilleure qualité. En particulier, la revue de sécurité ne peut absolument pas être supprimée. Il faudra peut-être une approche structurée, comme les équipes sécurité des grandes organisations
  • Pour utiliser une revue basée sur des agents, le réglage du contexte est essentiel. Si on fait tourner une boucle planification → exécution → test/correction → revue/refactorisation → génération de guide QA, alors non seulement le code, mais aussi la documentation et les consignes de test évoluent ensemble
  • « Ça marche, donc c’est bon » n’est pas un problème technique, c’est un problème de culture organisationnelle. Certaines entreprises continuent à accorder beaucoup d’importance à un code facile à lire. Cela peut même devenir un avantage concurrentiel
  • J’investis dans l’automatisation de l’analyse statique et dynamique. Règles de lint personnalisées, vérification stricte des types, outils qualité comme le mutation testing : je les utilise activement. Les revues seules sont trop lentes et inefficaces ; l’essentiel, c’est l’automatisation du feedback précoce
  • Ce genre d’attitude change difficilement. Il vaudrait peut-être mieux rejoindre une équipe qui accorde de l’importance à la qualité logicielle

• J’utilise surtout l’IA pour le code boilerplate ou pour résoudre des problèmes de documentation
  J’ai aussi essayé des tâches de type agent, mais les résultats restent encore difficiles à juger fiables. Pourtant, certaines personnes disent qu’« elles n’écrivent presque plus de code ». Cet écart est intéressant

  • Dans beaucoup de cas, coder moi-même va plus vite que de passer par l’IA. Le processus qui consiste à planifier, lancer l’exécution puis vérifier le résultat est au contraire plus lent. En revanche, pour de gros refactorings, l’IA est nettement plus rapide
  • Ces derniers mois, les performances des agents ont explosé. On n’est plus au simple niveau de l’autocomplétion : on peut désormais aller jusqu’à l’implémentation complète d’une fonctionnalité
  • On peut peut-être l’expliquer par la différence entre les développeurs qui ressentent une sorte de « malaise (eww) » face au code écrit par l’IA, et ceux qui ne ressentent rien de tel
  • Au final, cela dépend clairement du type de tâche : pour certaines, l’IA convient très bien, pour d’autres non
  • Moi non plus, le premier résultat ne me plaît pas forcément, mais si on fait plusieurs tours de boucle de revue, la qualité monte clairement. Si on fait relire l’IA par une autre IA, ou si on clarifie les critères de test, c’est bien meilleur

• En ce moment, j’expérimente une boucle de codage orientée agent
  Par exemple, sur le projet fesh, l’objectif est de « compresser davantage les binaires Linux ». Comme c’est un problème avec des tests clairs, il convenait bien à une boucle IA
  Voici ce que j’ai appris :

  • Le test harness fait tout. Sans boucle de validation, on part dans la mauvaise direction
  • Il est important de laisser l’IA essayer des approches expérimentales
  • Il faut laisser un scratchpad .md d’une session à l’autre pour que l’apprentissage se poursuive
  • Les tests sont vraiment essentiels. L’IA échoue de façon étrange, donc il faut utiliser activement la génération automatique de tests
  • Sans tests, il est impossible de faire confiance au résultat de la boucle. Une procédure de validation déterministe est indispensable
  • Il m’a été utile de séparer le journal des décisions et le journal des rejets. En particulier, rejections.md avait plus de valeur. Il faut garder la trace de « pourquoi cette approche a été abandonnée » pour que l’IA ne répète pas les mêmes erreurs
  • C’est similaire en automatisation navigateur. Au-delà de la validation fonctionnelle, il faut ajouter une validation comportementale (est-ce que cela ressemble à un humain ?) pour que ce soit vraiment utile. Et les logs en .md améliorent fortement la qualité de la session suivante

• J’aurais aimé que la section sur les tests aborde le problème des « tests auto-réalisateurs » produits par les LLM
  Il arrive que les tests ne vérifient en réalité rien du tout, ou qu’ils passent simplement grâce à des valeurs codées en dur. Les humains doivent guider l’IA vers des habitudes de test rigoureuses

  • Je serais curieux de voir un exemple concret. On dirait que tu ne parles pas d’une simple erreur logique, mais d’un test qui a l’air correct en surface alors qu’il est en réalité vide de sens
  • De mauvais tests sont plus dangereux que l’absence de tests. Une fois la confiance rompue, c’est toute la confiance dans la suite de tests qui s’effondre
  • C’est pour cela que le mutation testing est important. Si le code est modifié et que les tests passent quand même, alors ce sont de mauvais tests
  • Il suffit de demander à l’IA de modifier volontairement une partie du code, puis de vérifier que les tests échouent. S’ils n’échouent pas, ce sont des tests inutiles
  • Bien sûr, il n’est déjà pas facile non plus d’amener les humains à écrire ce genre de tests

• À chaque nouvelle génération de LLM, on a l’impression que toutes les leçons précédentes sont invalidées
  Des structures complexes conçues pour contourner les limites d’anciens modèles, comme LangChain, sont devenues inutiles après GPT-3.5. Bientôt, il sera peut-être possible de tout faire avec un agent unique

  • C’est pour cela que j’essaie de formuler des patterns qui ne dépendent pas d’une version de modèle. Par exemple, le TDD red/green sera peut-être bientôt exécuté par le modèle lui-même, mais le concept reste utile
  • Au final, tout pourrait converger vers quelque chose comme ClaudeVM
    Voir l’article associé

• Il y a un point souvent absent des discussions sur l’agent engineering
  La plupart des enseignements sont présentés comme des vérités universelles, alors qu’en réalité ils dépendent de la taille de l’équipe, de la maturité de la base de code, du niveau de test et de la tolérance au risque. L’important, c’est d’indiquer clairement « dans quels cas ce pattern fonctionne »

  • C’est pour cela que je ne fais pas un livre, mais un site web qui organise ces patterns. Je compte le mettre à jour en continu en précisant leur périmètre d’application
  • En tant que consultant amené à travailler sur plusieurs bases de code, je constate que les performances de Claude Code varient de manière extrême selon la qualité de la base de code. Sur des projets avec typage fort et tests, cela fonctionne presque parfaitement, mais dans des environnements JavaScript permissifs, c’est beaucoup moins convaincant
  • Malgré tout, certains patterns sont universels. Par exemple, disposer d’une source de vérité indépendante (harness) est valable partout. Des outils comme showboat ou rodney aident à cela

• En ce moment, des « frameworks d’équipes d’agents » sortent par dizaines chaque jour
  C’est une période d’expérimentation chaotique, un peu comme les débuts de l’ingénierie logicielle. Mais au final, quelques patterns finiront par s’imposer comme standard.
  Dans notre équipe, ce qui a bien marché, c’est d’aborder cela comme une équipe humaine — on commence par rédiger une spec produit, on la peaufine avec l’IA, puis on la transmet à un flux d’agents aux rôles séparés

• Aujourd’hui, dans un cours de licence, j’ai parlé de l’évolution des architectures CPU et GPU
  Autrefois, grâce à la loi de Moore, le matériel résolvait tout, mais aujourd’hui, c’est le parallélisme qui est central.
  L’idée de Simon selon laquelle « le code est bon marché » relève d’un changement de paradigme comparable.
  De la même manière que le code efficace a complètement changé à l’ère du matériel parallèle, le processus de développement lui-même va changer à l’ère de l’IA. Ceux qui le comprendront les premiers pourraient obtenir un gain de 10 à 100 fois

• Dans notre équipe, la chose la plus pratique a été une boucle avec validation humaine à intervalles réguliers
  Les agents entièrement autonomes passent les tests, mais ils cassent souvent des invariants implicites.
  Nous faisons donc intervenir un humain juste avant les décisions irréversibles.
  Mais faire comprendre à l’IA ce qui est irréversible constitue encore un autre défi.
  Au-delà de documents comme CLAUDE.md, nous cherchons une méthode systématique pour transmettre les règles implicites de la base de code