Comment rédiger efficacement du code de qualité avec l’IA

• Dans un environnement de développement collaboratif avec l’IA, les humains doivent définir clairement l’orientation du projet et les décisions à prendre pour maintenir la qualité
• Une documentation précise est nécessaire pour que l’IA comme les autres développeurs comprennent clairement les exigences et les contraintes
• Mettre en place un système de débogage et un processus de revue de code renforce la fiabilité du code généré par l’IA et son processus de validation
• Le marquage des fonctions à risque de sécurité, l’isolement des tests et des règles de linting strictes permettent d’assurer la stabilité et la cohérence du code
• Le découpage du travail en unités et la réduction de la complexité permettent de garder le contrôle sur la génération de code par l’IA tout en maximisant l’efficacité

---

1. Établir une vision claire

• Les humains comprennent le monde, l’équipe et le comportement des utilisateurs, mais l’IA n’ayant pas d’expérience, elle a besoin d’instructions explicites
  • Dans un projet, toute décision non documentée finira par être prise par l’IA
• Il faut discuter à l’avance de l’architecture, des interfaces, des structures de données et des algorithmes, puis définir la manière de les tester
• Les décisions de long terme et difficiles à modifier doivent impérativement être gérées directement par des humains

2. Maintenir une documentation précise

• Pour que l’IA génère du code adapté à l’objectif, il est indispensable de lui transmettre des exigences détaillées
• Comme les autres développeurs doivent pouvoir fournir les mêmes informations à l’IA, il faut inclure dans le dépôt de code une documentation au format standardisé
  • Y consigner en détail les exigences, contraintes, architecture, standards de codage, design patterns, etc.
  • Utiliser des diagrammes UML, organigrammes et pseudocode pour représenter visuellement les structures complexes

3. Mettre en place un système de débogage qui aide l’IA

• Il faut prévoir un système de débogage efficace pour permettre à l’IA de vérifier rapidement le fonctionnement du code
  • Exemple : collecter les logs de tous les nœuds d’un système distribué afin de fournir des informations résumées comme « les données ont bien été envoyées à tous les nœuds »
• Cela permet de réduire le coût d’exécution des commandes et d’accélérer l’identification des problèmes

4. Indiquer le niveau de revue du code

• Il faut différencier l’intensité de la revue selon l’importance du code
  • Exemple : ajouter un commentaire //A après une fonction écrite par l’IA pour indiquer si elle a été examinée par un humain
• Ce système facilite l’identification et la gestion du code non revu

5. Rédiger des spécifications de haut niveau et tester soi-même

• Pour faire passer les tests, l’IA peut tricher avec des objets simulés ou des valeurs codées en dur
• Pour l’éviter, il faut rédiger soi-même des tests basés sur les propriétés (property-based testing)
  • Exemple : redémarrer le serveur et vérifier la cohérence des valeurs en base de données
• Le code de test doit être isolé dans une zone distincte afin que l’IA ne puisse pas le modifier

6. Séparer les tests d’interface

• Il faut faire en sorte que l’IA écrive les tests d’interface sans connaître le reste du contexte du code
  • Les tests restent ainsi objectifs, sans être influencés par l’IA qui a implémenté le code
• Ces tests doivent eux aussi être protégés pour empêcher toute modification arbitraire par l’IA

7. Des règles strictes de linting et de formatting

• Des règles cohérentes de style de code et de linting sont essentielles pour maintenir la qualité et détecter tôt les erreurs
• Elles permettent aussi bien à l’IA qu’aux humains de vérifier facilement la qualité du code

8. Utiliser des prompts d’agents de code selon le contexte

• Utiliser des fichiers de prompt propres au projet, comme CLAUDE.md, permet de réduire le coût de compréhension initial pour l’IA
• En y incluant les standards de codage, design patterns et exigences, on améliore la qualité et l’efficacité de la génération de code par l’IA

9. Identifier et marquer les fonctions à risque de sécurité

• Les fonctions sensibles du point de vue de la sécurité, comme l’authentification, les autorisations ou le traitement des données, doivent être explicitement signalées
  • Exemple : utiliser les commentaires //HIGH-RISK-UNREVIEWED et //HIGH-RISK-REVIEWED
• Si l’IA modifie ces fonctions, il faut configurer le système pour que leur statut de revue change automatiquement
• Les développeurs doivent toujours vérifier que ce statut est correct

10. Réduire au minimum la complexité du code

• La moindre ligne de code inutile occupe de la place dans la fenêtre de contexte de l’IA et augmente les coûts
• Il faut conserver une structure aussi simple que possible pour améliorer la compréhension, tant pour l’IA que pour les humains

11. Explorer le problème par l’expérimentation et les prototypes

• Il est possible d’expérimenter différentes solutions en tirant parti du faible coût de la génération de code par l’IA
• Créer plusieurs prototypes à partir d’une spécification minimale permet d’explorer l’approche optimale

12. Éviter la génération massive sans discernement

• Les tâches complexes doivent être découpées en petites unités pour que l’IA les traite étape par étape
  • Exemple : générer des fonctions ou des classes individuelles plutôt que l’ensemble du projet
• Il faut vérifier que chaque composant respecte les spécifications et,
  si l’on perd le contrôle de la complexité du code, il faut ramener le projet à son état initial

[GN⁺]

Avis Hacker News

• Je trouve toujours important d’écrire le code moi-même pour structurer ma pensée
  Le code est pour moi une sorte de contrainte qui m’oblige à affiner les détails
  J’ai l’impression qu’on n’atteint pas cette profondeur en se contentant d’écrire une spécification

  • Je pense pareil. Depuis mon enfance, le fait d’apprendre en construisant soi-même quelque chose a toujours été essentiel
    Confier ce processus à un LLM me donne l’impression d’un décrochage mental, comme un avion qui part en vrille
    Le stress de la résolution de problème diminue, mais la motivation à réfléchir et à créer disparaît
    Autour de moi, beaucoup aiment que l’IA écrive le code à leur place, mais je ne fais pas partie de ce groupe
  • Je ressens quelque chose de similaire.
    J’ai du mal à croire les gens qui disent qu’ils construisent un SaaS en faisant tourner 5 agents tout en buvant leur café
    Si l’on veut du code de bonne qualité, je pense qu’il faut plonger soi-même en profondeur dans le code
    Cela dit, l’IA m’a été assez utile pour des tâches répétitives et simples comme écrire des tests ou régler des problèmes de configuration
    Par exemple, j’ai relancé avec Claude un projet que j’avais abandonné il y a 5 ans, et en quelques heures j’avais l’impression d’avoir déjà avancé de moitié
  • Je continue à relire et tester le code moi-même
    Mais j’ai l’impression d’être revenu aujourd’hui à une approche centrée sur la spécification
    Grâce aux agents, on peut itérer très vite entre essais et abandons, ce qui permet de conserver un flux de développement itératif
    Je considère la spécification et les tests comme les vrais livrables, et je continue à les modifier pour clarifier ma pensée
  • Je suis totalement d’accord avec l’idée que « le code oblige à affiner les détails »
    Une spécification seule ne peut pas capturer toute la complexité du réel
    Le code produit par un LLM part souvent dans des directions verbeuses et étranges, donc il faut le garder sous contrôle
    En revanche, comme partenaire pour discuter et affiner des idées, un LLM est plutôt pas mal
  • Par le passé, on a souvent essayé de voir le software engineering comme une chaîne d’assemblage, alors qu’en réalité c’était surtout concevoir en construisant
    Maintenant que l’écriture de code est devenue moins chère et plus rapide, il faudrait peut-être au contraire renforcer la phase de conception formelle

• Je pense que ce qui a eu le plus d’impact sur la qualité de mon code, c’est la mise en place méthodique d’outils d’analyse statique
  Côté TypeScript, j’ai combiné tsc, eslint, sonarjs, knip, jscpd, dependency-cruiser, semgrep, puis tout intégré dans la commande pnpm check
  J’ai ajouté une exécution automatique via un hook pre-commit pour éviter les problèmes que le LLM laisse passer
  Grâce à ça, même quand le LLM cale, je peux facilement corriger à la main

  • J’ai moi aussi trouvé bien plus facile d’appliquer des règles de lint strictes
    Quand le style de code est cohérent, les revues deviennent bien plus simples, et on s’y perd moins même quand du code IA et du code humain sont mélangés
  • J’utilise une configuration similaire. Le hook pre-commit est indispensable
    Mais même si le lint et les tests passent, on peut toujours avoir du code qui ne fait pas ce qui était voulu
    Par exemple une API qui renvoie un tableau vide au lieu d’une 404 : syntaxiquement c’est correct, mais sémantiquement c’est faux
    Cette évaluation de la justesse comportementale reste encore la partie la plus difficile
  • Il m’est aussi arrivé que le LLM annonce à tort un résultat
  • Bonne configuration. Mais je me demande pourquoi il faut une limite de longueur de ligne. C’est à cause des opérateurs ternaires ?
  • Pour moi, le vrai problème est plutôt le manque de clarté du code et l’excès de programmation défensive
    Parfois, il faut donner la priorité à la maintenabilité plutôt qu’aux règles de lint

• Je fais un refactoring régulier chaque fois que j’ajoute des fonctionnalités
  Toutes les quelques features, je passe en revue toute la base de code et je la remets en ordre
  Je code depuis 40 ans, et pourtant je n’ai jamais été aussi satisfait de mon code qu’aujourd’hui

  • Avant, la culture dominante c’était plutôt « si ça marche, on déploie »
    Mais grâce aux LLM, le coût du refactoring est quasiment tombé à zéro
    Il n’y a désormais plus de raison de laisser du mauvais code en place
    La vraie valeur, c’est d’utiliser les outils qui augmentent l’efficacité pour améliorer la qualité
  • J’en ai tiré une leçon similaire
    J’ai créé un outil interne qui marque, à chaque commit, les lignes de code en bon (vert) / à refactorer (jaune) / à réécrire (rouge)
    C’est plus propre et plus systématique qu’un commentaire « TODO refactor », et je compte bientôt le publier en open source

• À l’heure actuelle, je pense que le développement piloté par les spécifications est l’approche la plus fiable pour travailler avec l’IA
  Je passe plus de temps à peaufiner les spécifications et à échanger des idées avec l’équipe et l’IA
  Si la spécification est incomplète, l’IA produit du code à côté de la plaque
  Quand la compréhension du domaine devient plus profonde, j’ai souvent l’impression qu’il vaut mieux relancer une implémentation depuis zéro

  • Ce genre de discussion me rappelle les rêves des années 90 autour de UML, 4GL, Rational
    À l’époque, il y avait cette vision selon laquelle « il suffit de définir les exigences et le système se construit tout seul »
    Au final, ça a échoué et l’agile a pris le dessus, mais aujourd’hui la technologie semble rendre ce rêve à nouveau possible

• La vraie valeur de l’IA réside dans la vitesse et la capacité à gérer l’ambiguïté
  Mais si l’on suit toutes les étapes de procédure, on finit par retomber sur une lenteur de type waterfall
  À choisir, je préfère écrire directement le code et utiliser l’IA comme relecteur de premier niveau
  Avancer par petites unités, avec validation rapide, reste une approche agile

  • Il y avait beaucoup d’idées utiles, même pour des développeurs expérimentés
    J’ai particulièrement apprécié la proposition de marquer les fonctions liées à la sécurité. Cela aide à conserver le contexte lors des changements ultérieurs du code
    « Découper en petites parties » est une base, mais les débutants passent souvent à côté
  • En réponse à « si on fait tout ça, on retourne au waterfall », quelqu’un a plaisanté : « la prochaine étape, ce sera donc la neurochirurgie en mode vibe coding »

• C’est amusant de voir les gens redécouvrir grâce à l’IA des bonnes pratiques de base
  En réalité, ce sont des choses qu’il aurait toujours fallu faire

  • Mais dans la pratique, c’était souvent difficile à respecter à cause de la pression de mise en production
    Maintenant que le temps de codage diminue, on dispose de plus de marge pour ce travail
    En plus, l’IA utilise réellement la documentation, donc bien documenter produit une valeur directe
    Avant, on écrivait des docs pour qu’elles soient ignorées ; les LLM, eux, lisent tout
  • En réalité, ces garde-fous ne sont vraiment indispensables qu’aux mauvais programmeurs (ou aux perroquets)

• Avant, j’écrivais des spécifications détaillées avant de coder, puis j’ai fini par comprendre qu’aller directement au code était plus rapide
  Mais est-on maintenant en train de revenir vers une logique centrée sur la spécification ?
  Si l’on écrit une spécification sans avoir complètement compris le problème, on finit de toute façon par apprendre en codant
  J’ai l’impression qu’on se situe désormais quelque part entre les deux

  • Quand on saute l’étape de la spécification, on finit souvent par produire un programme complètement erroné
    Mais aujourd’hui, grâce à l’IA, le coût d’un mauvais code est presque nul, ce qui donne l’impression que la valeur de la spécification diminue
  • Puisque l’IA peut produire du code à faible coût, il devient au contraire possible d’essayer d’abord sans spécification, d’apprendre, puis de reconcevoir ensuite
    C’est proche de la manière de programmer décrite par Joe Armstrong
    Et c’est désormais réaliste dans le monde actuel
  • L’idée selon laquelle il faut planifier, établir une spécification, puis écrire le code a toujours été vraie

• Quand j’occupais un poste de lead, je rédigeais des tickets extrêmement détaillés
  C’était utile pour les juniors, mais aussi pour moi-même afin de ne pas oublier les détails
  Pourtant, le management s’y opposait en disant que c’était une « perte de temps », et j’ai fini par perdre cette habitude
  Aujourd’hui, on me demande au contraire d’écrire des spécifications encore plus raffinées, encore plus vite

• Quand on utilise des agents IA, je me demande quel est le ratio entre Markdown et code, ainsi que la lisibilité du résultat
  Je me demande aussi si le temps de revue ne finit pas par dépasser celui qu’il aurait fallu pour écrire le code soi-même

• Il y a quelque chose d’ironique dans le fait que les développeurs défendent avec autant d’enthousiasme une IA qui pourrait les remplacer
  Ce tweet lié tourne ce phénomène en dérision

  • Il y a aussi l’idée d’Underground Resistance consistant à « polluer les données de l’IA pour la saboter »
  • Vu l’incapacité à corriger les problèmes de performance de Claude, on dirait qu’ils renforcent le marketing à l’approche de l’IPO
    Le message « si vous n’utilisez pas Claude, vous allez prendre du retard » en est peut-être la raison
  • Beaucoup de développeurs disent que « l’IA a amélioré leur productivité »,
    mais en pratique cela risque surtout de conduire à une baisse de la demande et de la rémunération des développeurs
    Le risque est encore plus fort pour ceux qui se contentent essentiellement d’assembler des packages NPM