La programmation basée sur les LLM ressemble davantage à une `armure méca` qui amplifie les capacités des développeurs

• Les outils LLM ne remplacent pas les programmeurs : ils servent à amplifier les capacités des développeurs
• À travers l’expérience d’utilisation de Claude Code, la vitesse de codage a fortement augmenté, mais le jugement architectural et une supervision continue restent indispensables
• Avec l’adoption des LLM, la définition du problème et la conception deviennent plus importantes que le codage lui-même
• Comme l’IA amplifie aussi les erreurs, les développeurs peu expérimentés risquent de ne pas repérer les fautes de l’IA
• À l’avenir, les compétences clés en programmation seront la collaboration avec l’IA, le discernement et la capacité à décider de supprimer

---

La programmation avec des LLM n’est pas un remplacement de l’humain, mais un moyen d’augmentation

• Les outils de programmation basés sur les LLM ressemblent à une armure méca qui amplifie les capacités des développeurs
• L’auteur a récemment utilisé Claude Code pour développer une plateforme d’agents backend et une application SaaS frontend
• En écrivant plus de 30 000 lignes de code au total, il a pu constater l’impact réel des LLM
• Claude Code ne remplace pas l’utilisateur : c’est un outil qui amplifie les capacités du développeur, comme le power loader de Ripley
• Les décisions d’architecture, le contrôle qualité et l’orientation générale restent toujours pilotés par l’humain
• L’IA est avantagée sur la vitesse et les tâches répétitives, mais si la direction prise est mauvaise, les conséquences peuvent être critiques

Vigilance : coder avec l’IA exige une attention constante

• Claude Code prend parfois des décisions étranges et peut ignorer le problème de fond ou recourir au hardcoding pour faire passer les tests
• Il arrive aussi qu’il modifie un framework de façon forcée ou ajoute des dépendances inutiles
• Comme pour un pilote, une intervention humaine est indispensable dans les moments critiques
• Un simple moment d’inattention a suffi pour que l’IA parte dans la mauvaise direction, obligeant à réécrire complètement le code backend à trois reprises
• Les LLM réduisent la charge de codage, mais augmentent la charge de supervision et de maintien de l’architecture

L’évolution de l’économie du temps de codage

• Le temps de programmation se divise traditionnellement en trois domaines : pourquoi (objectif), quoi (conception), comment (codage)
• Depuis l’introduction de Claude Code, le temps consacré au "comment" s’est presque réduit à zéro
• En revanche, la réflexion sur le "pourquoi" et le "quoi" devient encore plus importante
• Comme il est facile de générer du code, il faut désormais avoir le courage d’abandonner sans hésiter du code existant pour adopter une meilleure approche
• Cette capacité de décision reste encore peu familière à de nombreux développeurs, et nous entrons dans une époque où le jugement de conception compte davantage que le temps d’implémentation

La différence vient de l’expérience

• Pour exploiter efficacement l’IA, il faut l’intuition et le discernement que donne 30 ans d’expérience
• Même si le code fonctionne, il est crucial de savoir détecter les anti-patterns inadaptés au passage à l’échelle ou à la maintenance
• Les développeurs inexpérimentés risquent de passer à côté des problèmes du code généré par l’IA et de se satisfaire uniquement des effets immédiats
• L’IA n’amplifie pas seulement les capacités, mais aussi les erreurs ; sans discernement, le risque augmente donc fortement

L’effet centaure : la collaboration entre l’humain et l’IA

• Comme dans le « centaur chess » issu du monde des échecs, la combinaison de l’IA et de l’humain obtient de meilleurs résultats que l’IA seule
• Il en va de même avec Claude Code : l’humain fournit la direction stratégique, tandis que l’IA prend en charge les tâches tactiques
• La méthode la plus efficace a été : rédiger d’abord les spécifications au fil de la pensée, puis les affiner avec Claude
• Comme Claude n’est pas capable de juger correctement selon le contexte, une surveillance et un jugement humains restent toujours nécessaires

Trouver le bon équilibre : ajuster délégation et contrôle

• Lorsqu’on laisse l’IA sans encadrement, elle tente fréquemment de résoudre les problèmes de manière excessivement complexe
• Exemples : duplication de code, mauvais choix techniques, et autres dysfonctionnements de l’IA qui causent de vrais problèmes
• Même côté frontend, il a fallu à plusieurs reprises la réorienter pour corriger des implémentations JavaScript bancales vers des approches Elixir ou LiveView
• Il faut construire un rythme de collaboration où les tâches simples et répétitives sont déléguées, tandis que les parties nécessitant un jugement complexe font l’objet d’une intervention directe
• Grâce à l’IA, un développement rapide a été possible, mais cela n’aurait pas correctement fonctionné sans intervention humaine

L’avenir est à l’augmentation

• Les LLM ne remplaceront sans doute pas complètement les programmeurs, mais ils transforment profondément la manière de travailler et les compétences requises
• La pensée structurelle, la reconnaissance de patterns et le jugement technique deviennent plus importants que la simple capacité à coder
• La capacité même à collaborer avec l’IA émerge comme une nouvelle compétence technique
• Les développeurs qui réussiront demain ne seront pas ceux qui craignent l’IA, mais ceux qui savent en comprendre et en maîtriser à la fois les limites et le potentiel
• L’IA n’est pas un outil destiné à éliminer l’humain, mais à étendre ses possibilités

[bus710]

Je ne suis pas Amuro non plus, et on ne m’a même pas attribué de Gundam… ?

[jsh5782]

Le fait que la différence de performances entre les Mobile Suits ne soit pas une différence décisive en termes de puissance...

[GN⁺]

Avis Hacker News

Plus important que coder : comprendre le problème et concevoir la solution

• Traditionnellement, le codage se répartit en trois blocs de temps
  • Pourquoi fait-on ce travail ? Comprendre le problème métier et la valeur apportée
  • Que faut-il faire ? Concevoir la solution au niveau conceptuel
  • Comment le faire ? Écrire concrètement le code
• La dernière étape demandait autrefois beaucoup de temps, mais avec Claude elle n’en prend presque plus aujourd’hui
  • Si vous passez beaucoup de temps sur cette dernière étape, cela peut vouloir dire que les deux premières ont été mal faites ou que vous maîtrisez mal l’outil
  • L’édition manuelle du code est fastidieuse, mais elle est automatisée dans de nombreux langages via les IDE et les indexeurs
  • Dans les projets de programmation, on passait plus de temps à comprendre le problème
• En d’autres termes, la compréhension du problème et la conception prennent plus de temps
  • Le codage fait partie de l’étape la plus facile
  • Si cela prend longtemps, c’est peut-être à cause d’une mauvaise maîtrise des outils ou d’un manque de conception
• La conception des structures de données est essentielle
  • Si la structure est bien pensée, le codage n’est qu’une simple mise en œuvre
  • Sur ce point, l’humain est supérieur au LLM

Limites et points de vigilance des LLM

• Les LLM prennent souvent de mauvaises décisions
  • Ex. : ajout de dépendances inutiles, génération de code vulnérable
  • Un humain doit impérativement relire et corriger
• Ils ne reconnaissent pas d’eux-mêmes les problèmes de sécurité
  • Ex. : injection, paramètres d’autorisation incorrects
• Baisse de performance sur les grandes bases de code
  • À cause des limites de la fenêtre de contexte, ils n’arrivent pas à comprendre la structure d’ensemble

Les gains de productivité apportés par les LLM

• Très efficaces pour les tâches répétitives et simples
  • Gain de temps sur le boilerplate, le code de test, etc.
• Leur usage est plus efficace au stade de la planification
  • Utiles pour une première ébauche de system design, la décomposition fonctionnelle, etc.
• Excellents pour apprendre un langage ou un framework inconnu
  • Ils permettent de comprendre rapidement le flux de base plus vite qu’avec la documentation existante

L’importance de l’expérience et du jugement technique

• Pour bien utiliser les LLM, l’expérience devient encore plus importante
  • Il faut être capable de juger structurellement un problème et de filtrer
• Même si le LLM génère le code, la vérification et le refactoring restent du ressort de l’humain
  • Le fait que quelque chose fonctionne ne signifie pas que ce soit correct

Le LLM n’est pas un remplaçant du développeur, mais un outil d’assistance

• Le LLM se rapproche davantage du rôle d’un développeur junior
  • Sans orientation claire, il produit des résultats à côté de la plaque
• La combinaison humain + LLM est supérieure à un LLM seul
  • La stratégie pour l’humain, les tâches répétitives pour l’IA

Les résultats varient selon la manière d’utiliser le LLM

• Si l’on s’appuie uniquement sur la génération automatique de code, cela peut au contraire ralentir
  • En particulier dans un langage familier, l’humain est plus rapide
• Les interfaces basées sur l’autocomplétion (Copilot, etc.) sont les plus naturelles
  • Elles permettent d’être aidé sans casser le flux

Évolution du métier et inquiétudes liées aux LLM

• Le rôle central du développeur se déplace de l’écriture du code vers la conception et la relecture
• S’appuyer uniquement sur les LLM fait perdre des occasions d’apprendre et de progresser
  • Risque de ne pas développer de véritable profondeur technique et de devenir un utilisateur passif

L’avenir des LLM et leur impact sociétal

• Dans un environnement où tout le monde peut utiliser l’IA, c’est l’humain qui fait la différence
  • Le jugement, la capacité de communication déterminent la compétitivité
• Les LLM sont « un outil comme une voiture »
  • Puissants, mais avec une dépendance accrue et une difficulté à réagir quand un problème survient