Le rôle des compétences des développeurs dans le codage agentique

• À mesure que les assistants de codage agentiques gagnent en compétences, les réactions sont très variées, certains allant jusqu’à affirmer que « d’ici un an, les développeurs ne seront plus nécessaires »
• D’autres expriment des inquiétudes sur la qualité du code généré par l’IA et sur la manière de préparer les développeurs juniors à cet environnement en mutation
• Ces derniers mois, l’auteur a utilisé des assistants de codage agentiques comme Cursor, Windsurf et Cline, et les a trouvés très efficaces pour modifier une base de code existante
• Il a été très impressionné par leur intégration à l’IDE : exécution des tests et correction automatique des erreurs, détection et correction des erreurs de lint/compilation, recherche web, et même prévisualisation dans le navigateur
• L’expérience de collaboration entre le développeur et l’IA est très marquante et contribue à une résolution rapide des problèmes ainsi qu’à l’implémentation de fonctionnalités

• Cependant, une intervention, des corrections et une orientation continues de la part du développeur restaient nécessaires
• Dans bien des cas, cela n’aboutissait même pas à un commit réel, et l’IA reste insuffisante pour écrire de façon autonome du code pour des tâches non triviales
• Les compétences et l’expérience des développeurs demeurent donc essentielles et devront continuer à être cultivées à l’avenir

Les moments où l’intervention directe du développeur a été nécessaire

• Les outils d’IA ont toujours montré des faiblesses dans certains domaines, ce qui s’est vérifié de manière répétée
• Certaines peuvent être partiellement atténuées avec des prompts supplémentaires ou des règles personnalisées, mais un contrôle complet reste impossible
  • Les LLM ne suivent souvent pas exactement les instructions du prompt
  • Plus une session de codage s’allonge, plus la cohérence des résultats diminue
• Les cas présentés ci-dessous sont donc des problèmes qui peuvent largement survenir indépendamment du prompt ou de la configuration
• Les erreurs de l’IA sont classées en trois catégories selon leur rayon d’impact
  • a. Ralentissement de la vitesse de développement et du temps jusqu’au commit
    • L’IA finit par ralentir au lieu d’accélérer
    • Parfois moins efficace qu’un codage sans assistance
  • b. Frictions dans le flux de travail de l’équipe
    • Conflits ou problèmes de collaboration au sein d’une même iteration
  • c. Dégradation de la maintenabilité du code à long terme
    • Rien ne semble problématique au départ, mais les difficultés apparaissent lors des changements ou extensions futurs
• Plus le rayon d’impact est grand, plus la boucle de feedback nécessaire pour que l’équipe identifie et corrige le problème s’allonge

Rayon d’impact : délai jusqu’au commit

• Cette catégorie regroupe les cas où l’IA a davantage gêné qu’aidé
• Comme il s’agit de la forme d’échec la plus visible, ce n’est pas le problème le plus grave
  • Dans la plupart des cas, le développeur peut repérer et bloquer le problème avant l’étape du commit

• Code non fonctionnel

  • Le code généré par l’IA ne fonctionne tout simplement pas
  • Le développeur doit le corriger lui-même ou mettre fin à la session IA et résoudre le problème manuellement
  • Un développeur expérimenté peut identifier rapidement ce qui cloche et agir en conséquence

• Mauvais diagnostic du problème

  • L’IA identifie mal la cause du problème et tente une solution dans une mauvaise direction
  • Grâce à son expérience passée, le développeur a pu ramener l’IA sur la bonne voie

    Exemple : une erreur de build Docker interprétée à tort comme un problème de configuration d’architecture, conduisant à modifier cette configuration
    La vraie cause était la copie de node_modules construits pour une mauvaise architecture
    Comme c’était un problème déjà rencontré souvent, il a pu être identifié et corrigé rapidement

Rayon d’impact : flux de travail de l’équipe au sein d’une iteration

• Cette catégorie concerne les cas où un manque de revue ou d’intervention du développeur provoque des frictions au sein de l’équipe pendant l’iteration
• Grâce à ses expériences passées dans différentes équipes, l’auteur a pu anticiper et ajuster ces problèmes avant le commit
• Les développeurs débutants peuvent eux aussi tirer ces leçons en avançant par essais et erreurs avec l’IA
• Mais si l’IA accélère fortement la vitesse de codage, l’équipe peut ne pas être capable d’absorber ces problèmes

• Travail initial excessif

  • L’IA a tendance à vouloir traiter largement une fonctionnalité entière d’un coup plutôt que d’avancer par implémentation progressive
  • Si les choix techniques sont inadaptés ou que les exigences fonctionnelles sont mal comprises, une grande quantité de travail peut être gaspillée

    Exemple : lors d’une migration du stack frontend, tentative de conversion de tous les composants UI en une seule fois
    Il aurait fallu commencer par un seul composant intégré au backend, puis avancer progressivement

• Résolution aveugle sans analyse de la cause

  • L’IA cherche à corriger des erreurs visibles en surface sans analyser la cause racine du problème
  • Le coéquipier qui reprendra ensuite le sujet devra réanalyser le problème sans le contexte, ce qui crée une charge supplémentaire

    Exemple : lors d’une erreur mémoire pendant un build Docker, augmentation du réglage mémoire au lieu d’en rechercher la cause

• Complexification du workflow développeur

  • Les modes de build/exécution générés par l’IA dégradent l’expérience développeur
  • Si c’est commité tel quel, cela nuit aussi au workflow des autres membres de l’équipe

    Exemple : séparation des commandes de lancement du frontend et du backend
    Exemple : absence de hot reload
    Exemple : configuration de build complexe qui embrouille autant les développeurs que l’IA
    Exemple : incapacité à détecter en amont les erreurs Docker, avec traitement tardif de l’erreur en fin de build

• Exigences mal comprises ou incomplètes

  • Si les exigences fonctionnelles ne sont pas données clairement, l’IA peut mal les interpréter et implémenter la fonctionnalité dans une mauvaise direction
  • Une intervention précoce est idéale, mais avec une IA autonome ou un développeur peu réfléchi, le coût des corrections ultérieures augmente
  • Ces implémentations erronées sont parfois découvertes plus tard dans l’avancement de la story, ce qui entraîne beaucoup de retouches et un coût de communication important

Rayon d’impact : dégradation de la maintenabilité à long terme

• C’est le rayon d’impact le plus discret et le plus dangereux
  • Au départ, le code fonctionne sans problème apparent, mais il devient ensuite difficile à modifier et à faire évoluer
• Ces problèmes ne sont souvent découverts qu’après plusieurs semaines ou plusieurs mois
• C’est surtout dans cette zone que les plus de 20 ans d’expérience de l’auteur ont joué le rôle le plus important

• Code de test verbeux et redondant

  • L’IA est bonne pour générer des tests, mais les problèmes suivants surviennent fréquemment :
    • création de nouvelles fonctions de test au lieu de les intégrer aux tests existants
    • ajout d’un trop grand nombre d’assertions, y compris sur des parties déjà couvertes
  • Point que les développeurs débutants risquent de mal comprendre : plus de tests ≠ meilleurs tests
  • Plus il y a de redondance, plus la maintenance devient difficile, et plus le risque de pannes massives des tests augmente lors des changements de code
  • L’auteur a tenté d’atténuer cela avec des commandes personnalisées, mais le problème reste fréquent

• Manque de réutilisabilité

  • Le code écrit par l’IA manque souvent de modularité, ce qui le rend difficile à réutiliser

    Exemple : l’IA ne reconnaît pas un composant UI déjà existant et en implémente un doublon
    Exemple : abus des styles inline au lieu d’utiliser des classes CSS

• Code inutilement complexe ou verbeux

  • L’IA génère souvent plus de code que nécessaire, ce qui oblige à retirer manuellement les parties superflues
  • Cela augmente le coût de maintenance et accroît la probabilité d’erreurs lors des modifications

    Exemple : lors d’un changement CSS, il faut supprimer un grand nombre de styles redondants un par un
    Exemple : création d’un composant web inutilement complexe pour afficher des données JSON
    Exemple : lors d’un refactoring, l’IA ne reconnaît pas une chaîne d’injection de dépendances existante,
    et transmet de nouveau une valeur déjà injectée via un paramètre supplémentaire, compliquant la conception

    • forme value = service_a.get_value(); ServiceB(service_a, value=value)

Conclusion : l’IA peut-elle écrire tout le code à notre place ?

• Au vu de l’expérience acquise jusqu’ici, il est irréaliste d’imaginer que l’IA écrira de manière autonome 90 % de l’ensemble du code d’ici un an
• En revanche, dans un rôle d’assistance à l’écriture de code, elle peut atteindre 90 % d’assistance dans certaines équipes et certaines bases de code
• Dans les faits, l’auteur reçoit environ 80 % d’aide de l’IA sur un projet de complexité moyenne d’environ 15K LOC

Comment éviter les erreurs de l’IA

• Ce que les développeurs individuels peuvent faire

  • Toujours relire avec soin le code généré par l’IA
    • Il est rare qu’il n’y ait rien à corriger
  • Interrompre immédiatement une session IA qui devient confuse
    • Modifier le prompt, ou basculer carrément en manuel (ce que l’auteur appelle aussi « codage artisanal »)
  • Se méfier des solutions “plausibles” produites comme par miracle en très peu de temps
    • Elles peuvent cacher un coût de maintenance à long terme
  • Pratiquer le pair programming
    • Quatre yeux et deux cerveaux permettent de mieux juger

• Stratégies de réponse à l’échelle de l’équipe et de l’organisation

  • Utiliser activement les outils existants de surveillance de la qualité du code
    • Ex. : Sonarqube, Codescene
    • Avec les outils d’IA, il faut surveiller encore plus attentivement la duplication de code, les code smells, etc.
  • Mettre en place des pre-commit hooks et une revue de code intégrée à l’IDE
    • Renforcer la stratégie de shift-left pour détecter les problèmes plus tôt dans le développement
  • Réaffirmer les bonnes habitudes de qualité de code
    • Partager lors des rétros hebdomadaires les cas de problèmes causés par du code IA (« journal des dérives »)
  • Exploiter activement des règles personnalisées
    • La plupart des outils d’IA permettent de définir un ensemble de règles transmis avec le prompt
    • L’équipe peut améliorer ce ruleset ensemble afin de réduire les erreurs de l’IA
    • Mais plus la session dure, plus la probabilité que les règles soient ignorées augmente
  • Construire une culture d’équipe fondée sur la confiance et la communication
    • L’adoption de l’IA est un changement nouveau, et il faut reconnaître que tout le monde est débutant
    • La pression du type « puisqu’il y a l’IA, allez plus vite » augmente les risques sur la qualité
    • Une équipe avec sécurité psychologique favorise davantage le partage des problèmes et l’apprentissage

[bus710]

Les personnes qui utilisent cet outil seront de toute façon des développeurs, quelles que soient leurs compétences... Faire de la pub comme si les développeurs n’allaient plus être nécessaires à l’avenir, ça me semble un peu étrange.

[prunusnira]

Je ne sais pas encore comment ça évoluera à l’avenir, mais pour l’instant, j’ai l’impression que ce n’est pas vraiment au point pour un usage grand public... J’ai récemment essayé Cursor, et il n’arrivait même pas à gérer correctement les chemins d’import de fichiers de base. Cela dit, j’ai quand même trouvé assez impressionnant le fait qu’il puisse anticiper dans une certaine mesure ce que je voulais créer.

[daddy]

Quand une erreur mémoire survient pendant un build Docker, au lieu de se demander dès le départ pourquoi autant de mémoire était utilisée, on a augmenté les paramètres mémoire
-> C’est... parce qu’on a déjà fait comme ça dans d’innombrables cas.
-> L’IA actuelle, c’est nous dans le passé

[GN⁺]

Commentaire Hacker News

• J’utilise Cursor pour la plupart de mes développements ces temps-ci. Cet article correspond très bien à mon expérience

  • J’ai l’impression que les agents IA se sont arrêtés vers 2021. Si on installe un nouveau package, Claude revient à des packages ou des implémentations obsolètes qui étaient populaires il y a 4 ans. Corriger cela est extrêmement frustrant. Fournir des instructions claires peut atténuer le problème, mais ne le résout pas
  • L’imprévisibilité de ces erreurs est particulièrement difficile. Il y a quelques mois, j’ai utilisé Claude pour créer une application web utile en « one shot ». Elle était complète et étonnamment sophistiquée. Si je l’avais faite seul, cela m’aurait pris des semaines ou plusieurs week-ends. Mais quand je lui ai demandé de mettre à jour le favicon avec les fichiers fournis, il a tourné en rond pendant une heure sans rien produire d’utile (j’ai fini par le régler moi-même en quelques minutes). Il y a quelques jours, j’ai essayé de recréer une application web d’une portée similaire. Après environ 4 heures à gérer l’agent, j’étais prêt à jeter tout le code
  • Cette approche me donne le courage de poursuivre des projets que je n’aurais pas tenté faute de temps, d’expertise ou de motivation. Réduire les frictions est enthousiasmant, mais créer quelque chose de réellement utile reste difficile. Construire un MVP sophistiqué demande encore un effort considérable
  • Je continue à penser au lièvre et à la tortue. Faire confiance à un agent IA est tentant, car au début on a l’impression d’avancer bien plus vite. Mais au final, il reste souvent l’impression qu’on aurait obtenu des progrès plus solides en avançant lentement et avec soin. Quand je construis manuellement, il est rare que je doive revenir en arrière ou abandonner toute l’approche. Avec une approche pilotée par l’IA, on peut aller 10 fois plus vite, mais finir par jeter environ 70 % du travail en cours de route
  • À cause de cette expérience, j’ai du mal à imaginer que l’IA écrira de manière autonome 90 % du code d’ici un an. Elle pourra sans doute aider à écrire 90 % du code
  • L’environnement actuel ressemble au cycle de hype autour de la voiture autonome. Il y a eu beaucoup de promesses ambitieuses et de vrais progrès, mais je ne vois pas un monde, dans les 5 prochaines années, où l’IA écrira seule des logiciels réellement utiles

• Voici comment j’utilise l’IA : comme une aide à l’écriture dans l’IDE, qui me répond comme un canard en plastique extrêmement élégant et sophistiqué

  • Je discute souvent de fragments de code précis. En général, ils sont fournis avec très peu de contexte, puis affinés jusqu’à ce que la fonctionnalité marche correctement, avant d’être intégrés dans un contexte plus large (ou bien je m’occupe moi-même de cette partie)
  • Je ne l’utilise pas ainsi : comme un agent censé atteindre seul des objectifs larges
  • Pourquoi : parce qu’il faut investir beaucoup trop de temps et d’efforts pour garantir que la sortie d’un système agentique corresponde réellement à ce qu’on cherche à accomplir. Pour toutes les excellentes raisons expliquées dans cet article
  • Paradoxalement, utiliser l’IA comme une aide à l’écriture très compétente accélère considérablement mon workflow. Donc, dans une certaine mesure, une IA moins agentique me rend plus critique, y compris sur le temps supplémentaire qu’il faudrait investir pour s’adapter aux singularités de l’IA agentique

• Je ne comprends pas du tout

  • Je ne comprends pas pourquoi des développeurs expérimentés s’enthousiasment à ce point pour s’enchaîner à une expérience aussi manifestement médiocre et insatisfaisante
  • J’aime écrire du code et résoudre des problèmes. C’est pour ça que j’ai choisi le développement logiciel comme métier

• Exemple : lors d’une erreur mémoire pendant un build Docker, au lieu de demander dès le départ pourquoi autant de mémoire était utilisée, l’IA a simplement augmenté les paramètres mémoire

  • L’IA est vraiment comme nous

• Les compétences développeur restent indispensables — si vous ne savez pas conduire, vous ne pouvez pas piloter. Mais qu’en est-il de l’énergie du développeur ? Avant l’IA, je pouvais coder environ 2 heures par jour (du vrai temps d’écriture de code). Mais avec Claude Code, je peux facilement coder 5 heures d’affilée sans pause. C’est comme passer d’un vélo à un vélo électrique. L’IA me fait penser à la métaphore de Steve Jobs sur le vélo pour l’esprit — elle ne me remplace pas, mais maintenant je peux aller beaucoup plus loin, beaucoup plus vite

• Ce diagramme est incroyablement parlant — notre équipe coche tous les éléments qui y figurent. Et pourtant, nous n’utilisons toujours pas l’IA ! Imaginez quand nous finirons par l’utiliser...

  • « exigences mal comprises » et « implémentation inutilement complexe » sont pratiquement nos mascottes. Nous démêlons lentement ce chaos grâce à de meilleures conversations initiales et à des revues itératives. Mais les habitudes disparaissent difficilement. Y a-t-il des gens qui arrivent à éviter ces pièges même sans l’aide de l’IA ?

• Ce qui me paraît évident à moi ne semble pas l’être : utiliser l’IA autour de soi

  • Il faut souvent construire et maintenir des outils : outils de développement, introspection, logging, transformation, etc. J’ai eu beaucoup de chance en utilisant des agents pour les créer et les modifier. Par exemple, des outils qui collectent des données et agrègent des logs à partir d’un système de planification personnalisé
  • Il y a énormément de boilerplate généré hors du chemin critique pour construire ces outils. La plupart du temps, je n’ai pas envie de faire ça

• Il faut beaucoup piloter l’IA, mais je reste optimiste : de meilleurs prompts mèneront à de meilleurs agents

  • Prenons l’exemple cité dans l’article : la réutilisation du code. Quand j’écris du code, j’ai inconsciemment un inventaire mental du code déjà existant. Inconsciemment, je me demande : « cette nouvelle tâche ressemble-t-elle beaucoup à du code déjà existant, fonctionnel et testé ? » Je n’ai pas examiné en détail les prompts initiaux donnés à l’agent de code, mais mon intuition est qu’il serait utile d’ajouter un prompt qui demande à l’agent de garder un inventaire de ce qui existe dans la codebase et, lorsqu’il planifie un nouveau lot de code, de comparer les exigences de la nouvelle tâche avec ce qui est déjà présent
  • Oui, cela ajoute beaucoup de cycles de calcul au processus de planification. Mais il faut être honnête : « c’est le prix à payer pour que l’agent écrive du code ». Une meilleure planification > une meilleure capacité à résoudre les problèmes

• Je veux commencer par dire que les outils d’IA sont toujours mauvais sur les points que j’ai listés

  • Il semble qu’il manque un « not » ici. Pourquoi dirait-on d’emblée qu’ils sont toujours mauvais ? L’inverse aurait plus de sens
  • Il y a aussi une faute de grammaire : « effected » au lieu de « affected »

• Martin Fowler loue maintenant de l’espace sur son site web ?