Apprendre à l’IA à penser comme un ingénieur senior

• Une méthodologie qui pousse les outils de codage IA à planifier avant d’écrire du code permet d’éviter les mauvaises implémentations et d’accélérer le développement
• Huit stratégies de planification sont appliquées selon le niveau de difficulté, chaque stratégie reposant sur des agents spécifiques qui mènent des recherches en parallèle avant que le développeur ne tranche et ne prenne les décisions
• Chaque stratégie inclut la reproduction de bugs, la recherche de best practices, l’analyse du codebase existant, l’étude de l’historique git, etc., avec une accumulation automatique des préférences et des schémas appris par les agents
• Le système, publié en open source, peut être installé dans Claude Code, ou bien on peut commencer par une seule fonctionnalité et apprendre progressivement à l’IA la manière de raisonner du développeur

---

Développement centré sur la planification par l’IA

• Présentation d’une approche qui demande à l’IA d’élaborer un plan avant d’écrire du code
  • Cette méthode, plutôt que de simplement produire du code, accélère l’implémentation des fonctionnalités et réduit les erreurs
• Exemple avec le développement de la fonctionnalité « email bankruptcy » de l’application de gestion des e-mails Cora
  • Lors de l’implémentation d’une fonction capable de trier 53 000 e-mails sans perdre les messages importants, des agents IA de recherche ont effectué une analyse préalable
  • Ils ont identifié à l’avance la limite de 2 000 éléments de Gmail, les timeouts système et les problèmes de temps d’attente côté utilisateur, évitant ainsi une mauvaise implémentation

Huit stratégies de planification

Stratégie 1 : reproduire et documenter les bugs

• Objectif : reproduire le bug avant correction et générer un guide étape par étape
• Quand l’utiliser : Fidelity 1 à 2, surtout pour les corrections de bugs
• Juste après le lancement de la fonctionnalité d’email bankruptcy, un problème a laissé 19 utilisateurs bloqués dans un état d’échec de traitement
  • En parcourant les logs AppSignal pour diagnostiquer le problème, il est apparu que les erreurs de rate limiting de Gmail étaient ignorées en production
  • Lorsqu’un lot échouait, l’ensemble de la tâche s’arrêtait, mais comme l’utilisateur n’était pas averti, il ne voyait qu’un spinner de chargement infini
• La reproduction a révélé la nécessité de traiter par lots et de pouvoir reprendre les tâches, montrant qu’un simple retry ne suffisait pas
• Effet cumulatif : ajout, dans la checklist de l’agent @kieran-rails-reviewer, d’un point vérifiant « pour les tâches en arrière-plan qui appellent des API externes : gestion du rate limiting, retries, et absence d’état partiel abandonné »

Stratégie 2 : étudier les best practices

• Objectif : rechercher sur le web comment des problèmes similaires ont été résolus
• Quand l’utiliser : à tous les niveaux de difficulté, en particulier face à des schémas peu familiers
• Lors d’une mise à niveau d’une gem en retard de deux versions, l’agent recherche « chemin de migration de la version X à Y », « breaking changes entre versions » et « problèmes de migration courants »
  • Il trouve le guide officiel de migration ainsi que trois billets de blog d’ingénieurs ayant effectué la même mise à niveau
  • Trois minutes de recherche évitent plusieurs heures de debug par essais-erreurs
• Utilisable aussi pour des décisions non techniques : « best practices des paliers tarifaires SaaS », « copy de conversion pour campagne d’e-mails drip », « stratégie de retry pour tâches en arrière-plan », etc.
• Effet cumulatif : lorsqu’un schéma utile est trouvé, il est automatiquement enregistré dans des fichiers docs/*.md, puis consulté avant toute nouvelle recherche web sur un sujet similaire

Stratégie 3 : enquêter dans le codebase

• Objectif : repérer des schémas similaires dans le code existant
• Quand l’utiliser : pour tout travail susceptible de dupliquer une fonctionnalité existante
• Avant d’ajouter de l’event tracking à une nouvelle fonctionnalité, l’agent cherche dans le codebase : « comment l’event tracking est-il géré aujourd’hui ? », « quels sont les schémas d’appel analytics ? », « où les événements sont-ils envoyés ? »
  • Il découvre un système de tracking existant, avec même des méthodes utilitaires (que l’auteur avait oubliées)
  • Si l’IA ne se réfère pas au codebase, elle essaie de repartir de zéro
• Au lieu de créer un nouveau système de tracking, la solution consiste à étendre le schéma existant, évitant la création d’un second système incompatible
• Effet cumulatif : création d’un agent « @event-tracking-expert », exécuté automatiquement dans tous les plans de fonctionnalités nécessitant du tracking

Stratégie 4 : lire le code source des bibliothèques

• Objectif : lire directement le code source des packages et gems installés
• Quand l’utiliser : avec des bibliothèques qui évoluent vite ou sont peu documentées
• La gem RubyLLM ajoute continuellement de nouveaux modèles, paramètres et fonctionnalités, mais la documentation a du retard
  • L’agent analyse le code source de RubyLLM : « quelles options de modèles sont disponibles ? », « quels paramètres peuvent être passés ? », « quelles fonctionnalités récentes ne sont pas documentées ? »
  • Il fournit par exemple : « le support du streaming a été ajouté en version 1.9 mais n’a pas été documenté », ainsi que les noms de paramètres et des exemples d’usage issus de la suite de tests
• Effet cumulatif : à chaque mise à jour d’une dépendance, les connaissances sont mises à jour elles aussi, ce qui évite de travailler avec des informations obsolètes

Stratégie 5 : étudier l’historique git

• Objectif : comprendre l’intention derrière des décisions passées via l’analyse de l’historique des commits
• Quand l’utiliser : pour un refactoring, reprendre un travail, ou lorsqu’il faut comprendre le « pourquoi »
• En découvrant l’usage d’une ancienne version de EmailClassifier, une recherche dans l’historique git est lancée avant toute tentative de mise à niveau : « pourquoi utilisons-nous la v1 ? », « a-t-on déjà essayé de passer à la v2 ? »
  • Elle révèle une PR d’un autre membre de l’équipe datant de trois mois plus tôt : la mise à niveau vers la v2 envoyait les e-mails de la boîte de réception vers les archives, et ceux des archives vers la boîte de réception
  • La discussion de la PR contenait l’explication détaillée et la trace d’un rollback volontaire
• Effet cumulatif : la mémoire institutionnelle est préservée et devient consultable, ce qui permet aux nouveaux membres de l’équipe d’hériter de la logique des décisions passées

Stratégie 6 : clarifier les besoins par le prototypage

• Objectif : clarifier les exigences via un prototypage rapide dans un environnement séparé
• Quand l’utiliser : Fidelity 3, incertitude UX, travail exploratoire
• Lors de la refonte de l’interface Email Brief, cinq prototypes de layout différents ont été réalisés dans Claude, cinq minutes chacun
  • Le fait de pouvoir cliquer dessus a permis d’identifier les points de friction et de montrer la meilleure version à certains utilisateurs
  • Retour d’un utilisateur : « le layout est écrasant et je ne sais pas comment archiver un e-mail »
• Cette information a été intégrée aux exigences du vrai plan : « le bouton d’archive doit impérativement être placé dans le coin supérieur gauche — la mémoire musculaire des utilisateurs attend cet emplacement à cause de Gmail »
• Effet cumulatif : le prototypage transforme l’incertitude en spécifications concrètes et documente les réactions des utilisateurs

Stratégie 7 : synthétiser avec plusieurs options

• Objectif : regrouper toute la recherche dans un seul plan incluant les trade-offs
• Quand l’utiliser : à la fin de la phase de recherche, avant l’implémentation
• Après l’exécution des stratégies 1 à 6, l’agent synthétise : « à partir de cette recherche, propose trois façons de résoudre le problème. Pour chaque approche : complexité d’implémentation, impact sur les performances, charge de maintenance, et compatibilité avec les schémas existants »
• Exemple de synchronisation de boîte de réception Gmail :
  • Option A — utiliser le système de synchronisation existant : implémentation rapide, mais duplication de code et moins bonne séparation des responsabilités
  • Option B — synchronisation en temps réel : architecture plus propre, mais plus lente et potentiellement moins fiable
  • Option C — construire un système de cache miroir : meilleure solution à long terme, séparation la plus nette, mais charge initiale de travail la plus élevée
• Après comparaison, une décision informée peut être prise en 30 secondes
• Effet cumulatif : les choix révèlent les préférences ; si une préférence « compatibilité d’abord » est indiquée, le système donnera plus de poids à la compatibilité lors de décisions similaires à l’avenir

Stratégie 8 : revue par des agents de style

• Objectif : soumettre le plan finalisé à des reviewers spécialisés chargés de vérifier sa conformité aux préférences du développeur
• Quand l’utiliser : à l’étape finale du plan, avant l’implémentation
• Trois agents de revue s’exécutent automatiquement :
  • Agent de simplification : signale les excès d’engineering, par exemple « cette fonctionnalité a-t-elle vraiment besoin de trois tables de base de données ? Un seul tableau avec un champ de type ne suffirait-il pas ? »
  • Agent de sécurité : vérifie les vulnérabilités courantes, par exemple « ce plan autorise directement des entrées utilisateur dans des requêtes base de données — il faut ajouter une sanitization des entrées »
  • Agent de style Kieran : applique des préférences personnelles, par exemple « tu utilises des jointures complexes ; Kieran préfère des requêtes simples, envisage une dénormalisation »
• Effet cumulatif : les agents accumulent au fil du temps les goûts du développeur ; si l’on marque « n’aime pas ça » ou « bien vu », le système apprend

Pour commencer

Ce que vous pouvez essayer dès aujourd’hui

• Le système de planification a été publié en open source sur le Github Marketplace de Every
• Une fois installé dans Claude Code, il permet d’utiliser immédiatement la commande slash /plan ainsi que les agents de recherche
• Le plugin peut être utilisé dans Claude Code ou Droid

Une manière simple de démarrer

• Choisissez une fonctionnalité Fidelity 2 que vous développez cette semaine : une tâche couvrant plusieurs fichiers et avec un périmètre clair (ajout d’une nouvelle vue, mise en place d’un système de feedback, refactoring d’un composant)
• Avant de demander à Claude Code ou Cursor de construire quoi que ce soit, consacrez 15 à 20 minutes de recherche :
  1. Best practices : comment d’autres s’y prennent-ils ? Recherchez billets de blog, Stack Overflow et documentation sur le web
  2. Vos propres schémas : comment vous y êtes-vous pris jusqu’ici ? Cherchez des fonctionnalités similaires dans votre codebase existant
  3. Capacités des bibliothèques : que prennent réellement en charge les outils que vous utilisez ? Faites lire la documentation ou le code source par l’IA
• Demandez ensuite à l’IA de synthétiser cette recherche dans un plan contenant :
  1. Le problème à résoudre (une phrase claire)
  2. Deux ou trois approches de solution (avec des avantages et inconvénients honnêtes pour chacune)
  3. Les schémas de code existants à respecter
  4. Les edge cases ou considérations de sécurité
• Relisez le plan et observez votre réaction : si vous pensez « c’est trop compliqué » ou « il y a déjà une meilleure manière », ne vous contentez pas de corriger le plan — capturez aussi pourquoi vous le pensez et consignez-le
• Livrez la fonctionnalité à partir du plan, puis comparez l’implémentation finale au plan initial : où y a-t-il eu des écarts ? Pourquoi ? Qu’est-ce qui aurait rendu le plan meilleur ?
• Investissez 10 minutes pour formaliser un apprentissage : ajoutez-le dans un fichier CLAUDE.md, sous forme d’une règle comme « pour les tâches de type X, penser à vérifier Y » ou « préférer l’approche A à B à cause de C »
• Une fois les apprentissages accumulés, créez des agents de recherche spécialisés ou des commandes dédiées : « Event Tracking Expert » (connaît vos schémas), « Security Checker » (signale les erreurs courantes)
• Répétez la semaine suivante, relisez les notes, vérifiez si le deuxième plan est meilleur que le premier, et au bout de quelques mois, construisez un système qui connaît la façon de penser du développeur