Mon workflow de génération de code avec les LLM

• tl;dr : je fais un brainstorming du spec, j’établis un plan, puis j’exécute avec du codegen par LLM. Une boucle d’itération individuelle. Et là, la magie opère
• J’utilise des LLM pour créer rapidement divers petits produits. C’est amusant et utile
• Mais si l’on adopte une mauvaise approche, on peut perdre énormément de temps
• Beaucoup de développeurs ont des approches assez similaires, et voici mon workflow

  « En ce moment ça marche bien, mais dans deux semaines ça pourrait ne plus marcher ou marcher deux fois mieux »

• Il y a 2 façons de développer
  • Code greenfield : démarrer un nouveau projet
  • Code legacy modernisé : améliorer ou étendre une base de code existante

Greenfield : repartir de zéro

• C’est un processus bien adapté aux situations où l’on « part de zéro »
• Le flux consiste à brainstormer l’idée, la documenter, établir un petit plan étape par étape, puis utiliser des outils de génération de code pour l’implémenter
• Étape 1 : préciser l’idée
  • En expliquant l’idée à un LLM comme ChatGPT, on l’amène à poser des questions une par une pour l’affiner jusqu’à obtenir un spec concret
  • À la fin, on produit un spec détaillé (spec.md) présenté comme un document que l’on peut transmettre à un développeur
  • Si nécessaire, on peut aussi utiliser des outils comme Deep Research pour obtenir des éléments de référence sur l’idée
• Étape 2 : planification
  • À partir du spec, on demande à un modèle plus puissant en « compréhension / raisonnement » de générer un blueprint détaillé par étapes
  • Que l’on fasse du TDD ou non, on crée de petites unités de travail pour chaque étape et on les organise dans l’ordre
  • Ce processus permet de générer prompt_plan.md et todo.md
    • prompt_plan.md contient la conception des prompts nécessaires au codegen, et todo.md contient une checklist
  • Cette phase de planification prend souvent une quinzaine de minutes et reste facile à consulter ensuite
• Étape 3 : exécution
  • On utilise divers outils d’aide et de génération de code comme Aider, Cursor ou Claude pour écrire le code réel
  • Claude et Aider sont des exemples représentatifs
  • Approche Claude
    • On configure d’abord la structure du projet (boilerplate, etc.), puis on entre les prompts étape par étape dans Claude
    • On copie-colle ensuite le code généré dans l’IDE et on lance les tests
    • En cas de problème, on envoie la base de code actuelle à Claude avec un outil comme repomix pour déboguer
    • Workflow
      • Setup du repo (boilerplate, uv init, cargo init, etc.)
      • Coller le prompt dans Claude
      • Copier-coller depuis claude.ai vers l’IDE
      • Exécuter le code, lancer les tests, etc.
      • …
      • Si ça fonctionne, passer au prompt suivant
      • Si ça ne fonctionne pas, envoyer la base de code à Claude via Repomix pour déboguer
      • Répéter l’opération encore et encore (rinse repeat)
  • Approche Aider
    • Dans Aider aussi, on traite prompt_plan.md dans l’ordre
    • L’outil peut exécuter automatiquement les tests, repérer des erreurs et aider à les corriger
    • Si besoin, on résout les problèmes via du débogage interactif
      • Setup du repo (boilerplate, uv init, cargo init, etc.)
      • Lancer Aider
      • Coller le prompt dans Aider
      • Regarder Aider danser ♪┏(・o･)┛♪
      • Aider peut exécuter les tests ou lancer l’app pour vérification
      • Si ça fonctionne, passer au prompt suivant
      • Si ça ne fonctionne pas, corriger en faisant du Q&R avec Aider
      • Répéter l’opération encore et encore (rinse repeat)
• Résultat
  • Cette méthode permet d’implémenter en peu de temps des scripts, des apps Expo, des CLI Rust et d’autres projets
  • Si vous avez des projets, petits ou grands, que vous repoussez, je vous recommande d’essayer
  • L’avantage est de pouvoir tester rapidement tout en apprenant de nouveaux langages ou technologies

Non-greenfield : travail incrémental / itératif sur du code existant

• C’est une méthode utilisée pour appliquer de petites tâches répétées à une base de code déjà existante
• Plutôt qu’un grand plan d’ensemble, on fonctionne par échanges de demandes concrètes et de résultats, tâche par tâche
• Récupérer le contexte
  • On peut utiliser des outils comme repomix pour résumer la base de code et l’envoyer au LLM
  • Avec mise ou des outils similaires, on gère la configuration récurrente et on enregistre le résumé dans un fichier output.txt
  • Si la base de code est trop volumineuse, on peut ajuster pour ne résumer que les parties nécessaires
• Exemple de workflow
  • Avec une commande comme mise run LLM:generate_missing_tests, on demande au LLM d’identifier les zones où les tests manquent
  • On applique ensuite les suggestions (issues) avec Claude ou Aider, puis on reteste le résultat
  • C’est ainsi que l’on améliore progressivement une base de code existante

Exemples de prompts clés

• Code review
  « En tant que développeur senior, fais une review approfondie du code. Inclus les numéros de ligne et le contexte. Pas de review superficielle : examine le tout en profondeur »
  « You are a senior developer. Your job is to do a thorough code review of this code. You should write it up and output markdown. Include line numbers, and contextual info. Your code review will be passed to another teammate, so be thorough. Think deeply before writing the code review. Review every part, and don't hallucinate.“
• Génération d’issue GitHub
  « En tant que développeur senior, examine le code et rédige les principaux problèmes au format d’issues GitHub »
  « You are a senior developer. Your job is to review this code, and write out the top issues that you see with the code. It could be bugs, design choices, or code cleanliness issues. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“
• Tests manquants
  « En tant que développeur senior, examine le code et indique de façon précise quels tests manquent ou quels tests devraient exister »
  « You are a senior developer. Your job is to review this code, and write out a list of missing test cases, and code tests that should exist. You should be specific, and be very good. Do Not Hallucinate. Think quietly to yourself, then act - write the issues. The issues will be given to a developer to executed on, so they should be in a format that is compatible with github issues“

Ski ᨒ↟ 𖠰ᨒ↟ 𖠰

• Quand on écrit du code très vite avec des LLM, il arrive qu’à un moment la complexité ou le contexte s’emmêlent et deviennent confus
• Revenir aux documents de la phase de planification (par exemple ceux du processus greenfield) ou rédiger les tests de façon systématique peut aider
• À mesure que l’on avance vite, il est aussi important de faire une pause ou de prendre un moment pour remettre ses idées au clair

Je suis très seul (｡•́︿•̀｡)

• La plupart des workflows basés sur les LLM sont aujourd’hui optimisés pour un « mode solo »
• Dès qu’on essaie de coder à plusieurs en équipe, les conflits et problèmes de merge deviennent plus complexes
• J’aimerais voir émerger des environnements collaboratifs de type « multijoueur » où plusieurs personnes pourraient utiliser un LLM en même temps

Temps

• Les LLM ont fortement amélioré mon efficacité d’écriture de code, mais il reste un certain « downtime » dû au temps d’attente du traitement des tokens
• J’utilise ce temps pour imaginer d’autres idées de projets, écouter de la musique ou discuter
• J’ai le sentiment que ma productivité personnelle a énormément augmenté par rapport à avant

Haterade ╭∩╮( •̀_•́ )╭∩╮

• Beaucoup d’amis ont une attitude du genre « ces foutus LLM, c’est totalement inutile », et je ne me préoccupe pas tant que ça de ce point de vue
• Bien sûr, je ne partage pas non plus entièrement cette position, mais il est vrai qu’un regard sceptique reste nécessaire
• Il y a une infinité de raisons de détester l’IA, et ce qui m’inquiète le plus, ce sont la consommation d’énergie et l’impact environnemental
• Malgré tout… « le code doit couler ». Voilà… soupir
• Si vous voulez en savoir plus sans forcément devenir un programmeur cyborg, mon conseil est : « ne changez pas d’avis, mais lisez plutôt Co-Intelligence: Living and Working with AI d’Ethan Mollick »
  • Ce livre explique très bien les bénéfices des LLM sans les exagérations du style capitaliste techno-anarchique
  • Personnellement, il m’a beaucoup aidé, et j’ai pu avoir des discussions bien plus profondes avec les amis qui l’avaient lu
  • Je le recommande vivement

[devs5]

Le livre d’Ethan Mollick, « Co-Intelligence: Living and Working with AI », semble devoir être publié en mars sous le titre « Dual Brain ».

[kipsong133]

Je ne connaissais pas Repomix. Jusqu’ici, je faisais du copier-coller à chaque fois… snif

[chugue85]

Merci !

[ahwjdekf]

Est-ce que l’IA peut aussi se faire engueuler à la place des autres développeurs ?

[aer0700]

Pour l’instant, j’utilise encore les LLM un peu comme un Google amélioré ou un Stack Overflow bienveillant, mais je devrais sans doute réfléchir à de meilleures façons d’en tirer parti.
La question de comment je construis les choses est bien sûr importante, mais il me semble aussi essentiel de réfléchir avec l’IA à pourquoi cela fonctionne. Les LLM sont utiles quand on cherche d’anciennes documentations techniques ou des standards.

[GN⁺]

Discussion sur Hacker News

• Les LLM sont des outils capables de prototyper rapidement de nouveaux projets. En revanche, lorsqu’il s’agit de modifier du code existant ou des projets matures, ils manquent souvent de contexte, ce qui tend à accroître la complexité ou à ajouter des frameworks inutiles. Les LLM ne remplacent pas la compréhension du code.

• Dans la collaboration avec les LLM, il est important de construire le contexte par le questionnement. C’est plus efficace que de tenter de créer directement ce contexte.

• Dernièrement, certains essaient le mob programming avec des LLM. Un LLM se charge de l’implémentation, tandis qu’un autre critique le résultat et propose des améliorations.

• Il est préférable de ne pas ajouter de framework très prescriptif à un projet. Cela augmente la taille du contexte que le modèle doit assimiler. Par exemple, au lieu d’utiliser Plasmo, on confie au LLM la configuration d’une extension de navigateur.

• J’aimerais entendre les retours de personnes qui ont commencé avec le chat de Cursor puis ont évolué vers un meilleur workflow. Je me demande si le temps investi dans la planification a été utile, si cela a réduit les hallucinations et, globalement, si cela a permis de gagner du temps.

• Cet article explique comment bien utiliser les LLM. Beaucoup de gens manquent de pratique pour communiquer efficacement avec les modèles de langage. L’auteur a maîtrisé cette communication avec les LLM, et ce workflow maximise l’efficacité.

• Pour maximiser l’efficacité d’un workflow avec des LLM, il faut une frappe rapide, un bon jugement et une bonne connaissance des forces et faiblesses de chaque modèle.

• Les outils de programmation avec des LLM sont amusants, mais pour vérifier s’ils sont réellement utiles, il faut se fixer des objectifs concrets et des échéances. Les LLM ont de fortes chances d’échouer dans ces conditions.

• Beaucoup de programmeurs débutants oublient la partie spécification et plan d’exécution de la programmation. Pour réussir à utiliser les LLM, il faut leur faire produire une spécification et un plan d’exécution.

• Je ne comprends pas l’enthousiasme autour de Claude. J’ai constaté beaucoup d’hallucinations en posant des questions sur Apache Spark. J’aimerais comprendre en quoi Claude serait meilleur que les autres modèles.

• Pour un développeur solo, cela peut aller, mais dans une équipe, faire analyser la même base de code par plusieurs instances de LLM n’est ni économique ni sans risque. Je me demande s’il existe un produit capable de fournir un contexte centralisé pour une équipe.