Comment améliorer ses compétences en programmation avec l’IA

• J’aimerais utiliser des outils de codage par IA pour réduire des tâches de conversion qui prenaient 1 à 2 heures à un simple niveau de revue en 15 à 20 minutes
• Mais, pour l’instant, la qualité du code produit par l’IA n’atteint même pas 90 % de celle du code écrit directement, donc cela ne semble pas vraiment utile en pratique
• Je voudrais donc savoir comment utiliser l’IA pour améliorer à la fois la productivité et la qualité du code

Recueil de conseils pratiques pour améliorer l’efficacité et la qualité de la programmation avec l’IA

1. Concentrer l’IA uniquement sur les tâches répétables

• L’IA est la plus efficace lorsqu’il s’agit de répéter plusieurs fois des tâches de forme similaire
• Une première fois, implémenter soi-même avec la meilleure qualité possible, puis utiliser cela comme exemple de référence
• Ensuite, confier à l’IA les tâches suivant le même modèle pour les traiter à grande échelle
• Pour les tâches qui exigent réflexion et jugement, le gain attendu chute fortement

2. Toujours commencer par un plan avant de coder

• Ne pas générer du code immédiatement, mais rédiger d’abord un plan de résolution
• À l’étape de planification, faire apparaître toutes les zones floues et toutes les questions
• Si le plan n’est pas satisfaisant, ne pas passer à l’étape d’exécution
• La qualité du résultat dépend moins du prompt que de la clarté du document de planification

3. Découper le travail en unités extrêmement petites

• Formuler les demandes à l’échelle d’un fichier, d’un composant ou de quelques fonctions
• Les requêtes comme « refactoriser l’ensemble » ou « améliorer de façon idiomatique » ont de fortes chances d’échouer
• La conception de la structure reste du ressort de l’humain, et seule l’implémentation répétitive est confiée à l’IA

4. Ne pas accumuler trop de contexte et le réinitialiser souvent

• Plus la conversation s’allonge, plus le respect des règles et la qualité chutent rapidement
• Une session ne doit traiter qu’une seule tâche
• Si l’orientation change, repartir dans une nouvelle session
• Pour les travaux de longue durée, conserver l’état dans un document (plan.md, etc.) puis le réinjecter

5. Garder les documents de règles courts et mécaniques

• Maintenir CLAUDE.md / AGENTS.md entre 500 et 1000 tokens
• Privilégier des règles concrètes et vérifiables plutôt que des consignes déclaratives
• Ne consigner au minimum que les erreurs fréquentes
• Pour le reste, s’appuyer sur le code et les vérifications automatiques

6. Utiliser les tests, le linter et le build comme boucle de feedback

• Au lieu de dire « fais-le bien », indiquer clairement les conditions de validation
• Fixer comme objectifs : tests réussis, build réussi, 0 erreur du linter
• Sans boucle de feedback, l’IA ne converge pas d’elle-même
• Des tests qui valident le comportement existant réduisent fortement la difficulté du refactoring

7. Ne pas corriger pendant l’exécution : revoir le plan puis relancer

• Si le résultat ne convient pas, éviter d’enchaîner les demandes de correction du code
• Modifier le document de planification, puis relancer dans une nouvelle session
• Si l’on change de direction en phase d’exécution, la qualité se dégrade rapidement

8. Faire apprendre le style à partir d’exemples

• Les consignes abstraites du type « bon code » n’ont presque aucun effet
• Fournir ensemble des exemples Before / After
• Présenter clairement les bons et les mauvais exemples
• Étendre les règles en s’appuyant sur les exemples

9. Ne pas renoncer à la compréhension et clarifier la frontière des responsabilités

• Le code généré par l’IA doit toujours être compris et relu par un humain
• Interdire son usage sans revue, sauf pour les prototypes et le code à faible risque
• Pour le code lié à la sécurité, à l’exploitation et à la maintenance de long terme, la compréhension est un prérequis de qualité

10. Vérifier d’abord si la tâche est adaptée à l’IA

• Les tâches sans réponse unique et avec une forte part de jugement esthétique ou structurel sont défavorables à l’IA
• Le refactoring UI, dont le résultat visuel est difficile à valider automatiquement, est particulièrement délicat
• Si nécessaire :
  • Étape 1 : transformation mécanique visant à préserver le comportement
  • Étape 2 : refactoring qualité réalisé par un humain

11. Partir d’une attente de « 10 % d’amélioration »

• Ne pas attendre du 10x dès le départ
• Une stratégie d’accumulation de petites améliorations est plus efficace à long terme
• L’essentiel est de ne pas renoncer à la conception ni aux critères de qualité

[GN⁺]

Avis Hacker News

• Boris de l’équipe Claude Code ici. Je partage quelques conseils

  1. Si Claude se trompe souvent ou ne comprend pas certaines parties, il est utile de les noter dans CLAUDE.md. Claude lit ce fichier automatiquement
  2. Utilisez activement le mode Plan (Shift+Tab deux fois) : établir un plan d’abord puis exécuter permet d’obtenir des résultats 2 à 3 fois meilleurs sur les tâches difficiles
  3. Il est utile de fournir une méthode de vérification du travail. Par exemple, avec Svelte, on peut utiliser le serveur MCP Puppeteer pour lui faire vérifier le résultat dans le navigateur
  4. Je recommande le modèle Opus 4.5. On sent clairement un cran au-dessus de Sonnet 4.5
     J’espère que cela aidera
  • Moi aussi, j’ai constaté un gros gain de productivité grâce au mode Plan. Mais dans les versions récentes, un bug fait que le mode Plan continue de se référer uniquement au premier plan de la session, ce qui a cassé mon workflow. Je me demande si je l’utilise d’une manière anormale
  • Après avoir corrigé Claude pendant une tâche, il est utile d’exécuter un prompt de self-reflection. Ce processus reflète automatiquement dans CLAUDE.md les éléments que vous avez réorganisés manuellement
  • Je suis d’accord avec ces conseils. Le feedback loop du point (3) est particulièrement essentiel. Il faut permettre au modèle de corriger lui-même puis de vérifier le résultat. Lui faire laisser des fichiers de logs ou élaborer un plan en pseudocode permet aussi de résoudre rapidement des problèmes complexes
  • Opus 4.5 est un vrai game changer. Il m’a énormément aidé pour refactorer un ancien projet React. L’effet est important si le prompt est précis et que CLAUDE.md est bien configuré
  • CLAUDE.md fonctionne bien jusqu’à 4 ou 5 fois, puis il oublie les consignes. Par exemple, même si on lui demande de m’appeler « Mr. bcherny », il l’oublie vite
  • Comparé à Google Jules, Claude Code donnait beaucoup plus l’impression d’un développeur professionnel. En revanche, Claude Code Web n’a pas de fonction de projet ; on m’a donc répondu d’utiliser le fichier .clinerules, mais j’aimerais comprendre la différence avec CLAUDE.md
  • Une fonction utile de CLAUDE.md, c’est @import. En mettant @ devant un nom de fichier, on peut forcer son inclusion dans le contexte. En revanche, en abuser devient inefficace

• Utiliser la saisie vocale permet au modèle de mieux comprendre l’intention. Je dicte des prompts d’environ 500 mots. La pensée s’enchaîne plus naturellement en parlant qu’en tapant.
  Si on dit « fais un plan et pose des questions s’il y en a », Claude pose réellement des questions. Lui demander d’imiter le style du code existant est aussi efficace

  • Moi aussi, j’ai construit presque tout laboratory.love à la voix. J’utilise souvent un raccourci avec la phrase « analyse le problème et les exigences avant d’écrire du code, et demande ce qui est ambigu »
  • Parler vite ne veut pas dire parler sans réfléchir. Au contraire, le problème peut être de parler avec trop peu de réflexion
  • C’est un peu gênant de parler à une IA quand quelqu’un écoute, mais moi aussi j’entre les longues phrases à la voix
  • Je suis curieux de savoir quel service de reconnaissance vocale vous utilisez

• Il faut inclure une condition de boucle (loop condition) dans le prompt. Par exemple : « répète jusqu’à ce que yarn test passe ».
  Un LLM reste au fond un agent qui exécute des outils en boucle, donc il faut le traiter ainsi
  Référence : Prompting the Agent Loop

• Je recommande ma configuration nori-profiles.
  Après 4 mois d’expérimentation, les performances de Claude Code se sont nettement améliorées.
  Article lié : Averaging 10 PRs a Day with Claude

  • Je me demande quelles différences il y a par rapport aux skills de Claude Code

• Dans mon entreprise, nous gérons une grande base de code en Golang. J’ai essayé plusieurs outils comme Cursor, Claude Code, Gemini CLI, etc., mais la plupart sont débordés par le volume de code.
  En revanche, aider était bien plus facile à contrôler et plus précis. L’ajout de fichiers est manuel, mais c’est correct presque à 100 %.
  Avec les derniers Claude Sonnet ou Gemini 2.5 Pro, c’est ce qu’il y a de plus précis

  • Le fait qu’aider ne soit pas un agent totalement autonome est justement un avantage. On gère le contexte manuellement, donc il ne modifie pas les mauvais fichiers. C’est aussi avantageux en économies de tokens et en vitesse

• Quand je travaille avec Cursor, je commence par faire refactorer une route pour lui faire générer un fichier de règles. Ensuite, sur les autres routes, il suffit de dire « refactor »

  • N’ayez pas peur des longs prompts. C’est exactement ce qu’on appelle le context engineering. L’historique de conversation enrichit lui-même le contexte.
    Il vaut mieux garder en tête l’espace de contexte restant et, si nécessaire, faire un context clear assez tôt

• Il est important de voir l’agent comme un coéquipier. Il faut observer les forces et les faiblesses de chacun et ajuster la manière de collaborer.
  Je concentre la puissance de l’agent sur les problèmes vérifiables ou le code expérimental.
  Je ne connais pas bien Svelte, mais il semble judicieux d’orienter la réécriture via des tests jetables en style TDD.
  Parfois, le mieux est d’abandonner un ancien mauvais contexte et de repartir de zéro dans un nouveau workspace

  • Ce serait bien de partager un résumé de ce texte sur le « style cognitif et le travail d’équipe »

• Je vois les LLM comme un moteur de recherche (searcher). Si l’on pose des questions petites et concrètes, la recherche est plus facile, et plus on s’éloigne des données d’entraînement, plus le risque d’erreur augmente.

  1. Ouvrir le projet dans Zed
  2. Connecter Gemini CLI, Qwen code ou Claude
  3. Demander de modifier les fichiers puis tester
  4. Si ça ne marche pas, essayer avec Grok ou Gemini 3 Chat
  5. Si ça ne marche toujours pas, résoudre manuellement
     Pour un nouveau projet, un prompt one-shot peut aussi suffire
  • Mais un prompt trop petit crée un problème de sous-spécification (underspecification). Cela réduit seulement le coût de calcul, au détriment de la qualité

• Mon toolkit Claude Code favori est superpowers

  1. Je commence par une session de brainstorming pour décrire la fonctionnalité
  2. Claude rédige un document de design et un plan d’implémentation qu’il enregistre sur le disque
  3. Dans une nouvelle fenêtre Claude, j’exécute la commande Execute Plan pour une exécution étape par étape avec commit
  4. Tous les trois étapes, je lui fais faire une revue autonome pour améliorer la qualité du code
     Je l’utilise depuis deux semaines et cela n’a presque jamais échoué

• Mes principes de programmation avec l’IA sont simples

  1. Le one-shot échoue
  2. Je découpe le travail en unités vérifiables
  3. J’organise le plan global dans un fichier Markdown
  4. À chaque étape, j’exécute dans une nouvelle session, puis je relis et je commit
     L’essentiel, c’est « Less is more ». Plus la fenêtre de contexte est fraîche, mieux c’est, et 500 à 750 mots est l’idéal. Chaque étape doit être vérifiable

• Pour les tâches liées à Java, Claude change constamment de direction ou fait des propositions contradictoires. J’ai l’impression que ChatGPT est bien meilleur

  • Cela peut s’améliorer avec des instructions plus spécifiques dans le prompt
  • Je me demande si vous avez essayé la version Claude Code

• Si vous voulez du code idiomatique, il faut d’abord définir en détail le style que vous attendez. Je découpe de petits exemples bons/mauvais, puis je les donne au mode Plan d’Opus 4.5 pour élaborer un plan avant exécution. Si ce n’est pas parfait du premier coup, je modifie le document de plan et je réessaie. Essayer de le guider dans le moindre détail comme un développeur junior est au contraire inefficace

  • Une autre personne a partagé son expérience : « de nos jours, les modèles n’ont pas forcément besoin qu’on redémarre la session », et le refactoring inline reste suffisamment stable à lui seul