- Les agents de codage par IA augmentent spectaculairement la vitesse d’écriture du code, mais la partie la plus importante du développement reste la compréhension et la résolution de problèmes
- Il est possible de produire rapidement du code avec des LLM, mais le manque de vision d’ensemble entraîne davantage de temps consacré au post-traitement et à la compréhension
- Cela crée un écart entre les attentes de productivité et l’efficacité réelle, et pousse les développeurs à passer du temps sur des tâches répétitives et pesantes comme les tests, le refactoring et la documentation plutôt que sur le travail créatif qu’ils recherchent
- Comme avec l’ancien « dilemme du tech lead », concentrer les tâches complexes sur l’IA ou les seniors pour obtenir des résultats à court terme peut provoquer une dégradation durable des capacités de l’équipe et mener à une crise
- Il faut considérer les LLM comme un junior engineer très puissant et appliquer à la collaboration avec l’IA des processus de développement éprouvés afin de bâtir une structure de livraison logicielle durable
Identifier le problème : plus important que coder lui-même
- Le développement logiciel est avant tout un travail centré sur la résolution de problèmes
- Le codage réel ne constitue que la dernière partie de toute la réflexion et des arbitrages d’un développeur
- En plus du code, les développeurs travaillent sur la compréhension du domaine, le découpage des exigences, l’abstraction, la prise en compte des effets de bord, les tests progressifs et la correction de bugs
- Flux de développement classique : réfléchir suffisamment avant d’écrire du code
- À l’ère du codage par IA : bascule vers un modèle le code d’abord, la compréhension ensuite
Le basculement du codage par IA : un paradigme où le code est généré en premier
- Des agents de codage par IA comme Claude Code génèrent rapidement du code, mais sans saisir complètement le contexte global du système
- Les étapes humaines de revue, test et intégration restent indispensables, et comprendre a posteriori le code produit par l’IA demande beaucoup de temps
- Le marketing met en avant l’accélération de la vitesse de codage, mais le gain réel de productivité en matière de livraison de logiciels fonctionnels reste limité
- Les développeurs consacrent davantage de temps à des tâches répétitives et difficiles autour des résultats produits par l’IA, comme les tests, l’élimination des doublons, la documentation et la gestion de l’infrastructure
- On observe une baisse du plaisir réel de coder et une hausse des tâches répétitives
L’ancien dilemme des responsables techniques
- Lorsqu’un ingénieur endosse un rôle de tech lead, il porte la responsabilité de la livraison technique de l’équipe
- Quand l’expérience se concentre sur une seule personne dans l’équipe, cela crée un déséquilibre de productivité
- Il existe une tension entre deux stratégies : la répartition équitable (axée sur la progression des membres de l’équipe) et la concentration des tâches (axée sur la rapidité d’exécution)
- La concentration des tâches apporte des gains à court terme, mais crée des risques à long terme pour l’équipe en raison d’une concentration de l’expérience (absence de relais, burnout, difficulté à faire face au support)
- Une culture d’équipe saine exige une manière de tenir l’équilibre entre progression et efficacité
Le cœur d’un bon leadership : l’équilibre entre processus et progression
- Il faut appliquer divers principes de développement et frameworks afin que tout le collectif s’approprie le savoir-faire des ingénieurs expérimentés
- Exemples : Extreme Programming, code review, déploiement progressif, conception modulaire, test-driven development, pair programming, documentation, intégration continue
- Objectif ultime : minimiser les retouches, maximiser la collaboration et favoriser la progression individuelle
Collaborer avec les agents IA : un nouveau rôle de leader d’équipe
- Les agents de codage récents fondés sur des LLM ressemblent à un développeur junior extrêmement rapide
- Contrairement à un junior classique, les LLM se distinguent clairement par l’absence de capacité d’apprentissage et l’absence de limite de vitesse
- L’IA continue de privilégier l’augmentation de la vitesse plutôt que l’amélioration de la qualité, tout en manquant du contexte humain et de la compréhension du domaine
- Deux modèles de collaboration :
- Ingénierie pilotée par l’IA : travail d’équipe plus lent, mais efficace et durable
- Vibe coding : focalisé sur des résultats rapides, mais accumulant peu à peu un chaos irrécupérable
- Cela rappelle les angles morts traditionnels de la croissance du code dans la Silicon Valley : après les gains de court terme, on finit par heurter un mur de limite de croissance
Des moyens concrets pour survivre au piège du codage par IA
- Les LLM ignorent leur propre contexte et produisent du code à la chaîne sans discernement
- Les ingénieurs doivent fournir à l’IA une structure claire, des standards et des processus pour transformer une sortie brute en véritable service exploitable
- Il faut un nouveau playbook appliquant de près les bonnes pratiques du cycle de développement traditionnel à l’environnement de collaboration avec l’IA
- Principales façons d’utiliser l’IA à chaque étape :
- Définition des spécifications : analyser les cas limites, rester concentré sur le périmètre cible
- Documentation : constituer des guides réutilisables et des éléments de preuve
- Conception modulaire : améliorer la compréhension en limitant le contexte
- Test-driven development : générer les cas de test avant l’implémentation, éviter les régressions
- Standards de codage : préserver le style et la qualité
- Monitoring : analyser automatiquement les logs et en tirer des insights
Conclusion
- La livraison logicielle ne se résume pas à l’écriture de code, et il est indispensable de mettre en place une structure de collaboration efficace entre l’IA et l’humain
- En considérant les LLM comme des développeurs junior ultra-rapides et en leur appliquant des processus de développement éprouvés, il devient possible de fournir un logiciel de haute qualité et capable de passer à l’échelle
2 commentaires
Avis Hacker News
J’aimerais voir des arguments anti-IA qui ne reposent pas simplement sur l’idée que « la technologie rend les gens paresseux ». Toute personne qui a sérieusement essayé de produire du code avec un LLM sent bien que la boucle planification-structuration-tests-rétrospective reste extrêmement importante. Si on le laisse tourner sans vigilance, tout se casse très vite. Quand cette boucle est bien appliquée, je peux consacrer beaucoup de temps à tester la conception d’architecture que j’aime et l’expérience du résultat. Comme les LLM gèrent rapidement les parties faciles, ce qu’il nous reste à traiter au final, ce sont les tâches moins intéressantes et peu valorisées. Dans les domaines où l’IA met l’expertise en valeur, l’écart de point de vue entre ceux qui aiment le travail lui-même et ceux qui aiment l’expérience de réfléchir apparaît très nettement. Ceux qui aiment réfléchir peuvent, grâce à l’IA, se concentrer presque entièrement sur cet aspect. En revanche, pour ceux qui aiment taper eux-mêmes et manipuler directement les choses, l’IA enlève plutôt la partie qu’ils préfèrent
Concernant la génération de code par IA, je pense que la critique la plus importante n’est pas tant que la technologie rend les gens paresseux, mais qu’elle prive d’une compréhension profonde du code généré par l’IA. Le cœur du métier d’ingénieur logiciel n’est pas de générer du code, mais de concevoir l’ensemble du système. Ce qui compte ici, c’est le modèle mental de fonctionnement du code et l’expertise métier ; le code n’est qu’un résultat dérivé de ce modèle mental. Dans un projet d’une certaine taille, il est difficile de connaître parfaitement un code que l’on n’a pas écrit soi-même. Et si l’on ne construit pas ce modèle mental, d’autres problèmes suivent. Les agents de codage basés sur des LLM ont des limites en raisonnement au niveau syntaxique, ce qui les rend peu robustes à l’échelle
Pour donner mon avis, j’utilise parfois des outils d’IA comme Cline, mais je code de plus en plus en tapant directement moi-même. La raison, c’est que dans la plupart des cas, on remplace simplement le codage par l’écriture de prompts. Si le temps de prompt et d’inférence est plus court que le temps qu’il me faudrait pour coder à la main, j’utilise l’IA, mais en général cela ne vaut que quand le goulot d’étranglement relève d’un refactoring. Pour la plupart des tâches, si je le fais moi-même, cela prend 10 minutes ; avec l’IA, j’écris le prompt, je l’exécute, et cela prend 8 minutes. Si tout marche parfaitement du premier coup, je gagne 2 minutes, mais s’il faut corriger ou re-prompt, cela finit plutôt à 10-12 minutes, avec en plus des crédits IA consommés : pire scénario. À force de faire ce calcul, j’en suis arrivé à la conclusion que le travail manuel est plus sûr, tant pour la qualité du code que pour le temps passé
Sur l’idée que la technologie rend les gens négligents, je dirais qu’en général la technologie pousse souvent les gens à être plus prudents. Le problème, c’est que cette technologie d’IA a de fortes chances d’inciter l’utilisateur à l’imprudence. Ce qui m’intéresse, ce n’est pas la partie amusante du codage ; je préfère la conception elle-même, l’architecture. Si je pouvais refléter directement mon intention dans le code, j’utiliserais cette voie. Mais une interface de chatbot transmet l’intention de manière indirecte et imparfaite ; lorsqu’on l’utilise pour construire du code à haut niveau, mon modèle mental et ma compréhension réelle du code divergent rapidement, laissant des fondations fragiles. Je pourrais bien sûr relire minutieusement ligne par ligne, mais cela va à l’encontre du but de l’outil. Le codage par IA, avec son impression de « 10 fois plus vite », encourage l’écart entre l’implémentation détaillée et la compréhension d’ensemble. En pratique, réfléchir moins aux aspects structurels est justement l’un des principaux bénéfices mis en avant pour vendre le codage par IA, mais cet écart de compréhension finit par causer des problèmes. Une bonne automatisation est fiable et prévisible, de sorte qu’il suffit de comprendre les invariants de plus haut niveau ; le code produit via chatbot ne donne pas ce type de garantie et crée au contraire une situation où il faut tout vérifier manuellement. Ici, la sécurité et la fiabilité paraissent donc encore plus difficiles à obtenir
Je vois trop souvent l’argument « concentrez-vous sur la partie réflexion », au point de le trouver usé. Le problème, c’est qu’on peut se demander si quelqu’un qui n’a pas plusieurs années de pratique réelle peut mener une activité profonde uniquement par la pensée. Au final, sans expérience concrète, même la réflexion risque de devenir de plus en plus superficielle
Mon point de vue, c’est que comme déboguer est plus difficile qu’écrire, il vaut mieux écrire moi-même le code plutôt que déboguer du code que je n’ai pas écrit
Chaque fois que je lis ce genre de discussion, je me demande si l’auteur utilise vraiment les mêmes outils que moi. Avec Claude Code, je peux faire produire à peu près tout, du simple boilerplate aux algorithmes complexes, même dans de très grandes bases de code particulièrement confuses. Bien sûr, ce n’est pas correct à 100 %, mais c’est très proche. En plus, l’outil propose souvent des algorithmes auxquels je n’avais pas pensé. Ce type d’outil me fait gagner au moins 10 fois mon temps
Cet article n’est pas mauvais, mais j’y vois deux présupposés trompeurs. D’abord, même pour un développeur expérimenté qui utilise un LLM, il reste indispensable d’explorer suffisamment, de réfléchir en amont et de concevoir. En réalité, pour bien exploiter un LLM, il faut réfléchir davantage que d’habitude, comparer différentes solutions d’architecture et dessiner la structure globale. Avant, je ne documentais pas ce processus, alors qu’aujourd’hui je le consigne dans des documents de conception. Ensuite, il y a l’idée qu’un LLM serait comme un développeur junior qui ne progresse pas ; les deux n’ont pourtant rien à voir. Un jeune développeur humain est une personne, un LLM est un outil. On dit souvent qu’en travaillant avec un junior, on accumule une valeur dans le temps, contrairement au LLM, mais ce n’est pas exact non plus. Même si le LLM n’apprend pas, moi, j’apprends à bien mieux le dompter et à l’utiliser plus efficacement. Nous en sommes au début de l’application sérieuse des LLM aux produits ; il est donc normal qu’on voie une valeur de progression composite
Je suis d’accord avec « même si le LLM n’apprend pas, moi, j’apprends », mais j’aimerais quand même qu’un LLM apprenne réellement de ses interactions avec l’utilisateur. Ce que je veux, c’est pouvoir sauvegarder/charger le contenu d’une session dans un fichier afin que le LLM comprenne sans aucune perte tout le contexte appris précédemment. Certaines interfaces frontend permettent déjà de sauvegarder/restaurer des sessions, mais l’important, c’est a) que ce « réapprentissage » n’affecte pas la
context windowactuelle du LLM — idéalement, j’aimerais même que ce concept disparaisse —, et b) que cela fonctionne sans perte aucune. Des méthodes comme la reprise après résumé ou le RAG existent déjà, mais elles ont toutes des limites fondamentales, qu’il s’agisse de pertes d’information ou du fait que la restauration ne peut se faire qu’en déclenchant l’interaction en cours. Par exemple, si j’ai expliqué hier une fonction à un LLM puis sauvegardé la session, je voudrais qu’après restauration aujourd’hui, même si je pose une question sans aucun lien direct, le LLM réponde en prenant encore tout l’ancien contexte en compte. Et il faudrait aussi pouvoir repartir sur une base vierge (clean slate) explicitement quand on le souhaiteC’est vrai. Dans la productivité globale en logiciel, le temps de réflexion pèse bien plus lourd que le temps réellement passé à écrire du code ; donc même si les LLM accélèrent la partie codage, cela ne bouleverse pas dramatiquement la productivité totale ni la demande en main-d’œuvre
Commencer par un prompt du type DO NOT WRITE ANY CODE YET est aussi ma méthode par défaut. C’est une façon de comprendre d’abord ce que le LLM compte faire et de garder le contrôle. Je trouve la conception elle-même — logique, résolution de problèmes, intégration système — bien plus amusante que l’écriture du code
Il existe des fonctions comme le mode Ask de Copilot ou les modes Plan/Chat de GPT-5 Codex, qui permettent de planifier sans modifier les fichiers de code. J’ai utilisé Codex pendant quelques jours et, avec des instructions suffisamment précises, c’est excellent
Moi aussi, je préfère généralement demander au LLM son plan d’exécution détaillé d’abord, avec des formulations du genre « dis-moi d’abord ton plan »
Cet article affirme un gain de productivité de 10 % en ne citant que du matériel marketing de Microsoft, alors qu’une étude de Harvard a au contraire relevé une baisse réelle de productivité de 10 %. Je préférerais des articles qui citent d’abord des résultats de recherche indépendants, plutôt que la communication d’une entreprise donnée
Parmi les points essentiels que cet article ne transmet pas complètement, il y a l’idée exprimée par Casey Muratori : « si vous programmez avec un état d’esprit centré sur l’apprentissage, alors l’IA devient plutôt sans intérêt ». Personnellement, j’ai l’impression que les générateurs de code par IA ne sont vraiment utiles que pour du code jetable, à usage unique. Dans les domaines où je veux apprendre sérieusement, j’ai constaté que ne pas confier la génération de code à l’IA maximise l’apprentissage. Il y a certainement des personnes pour qui l’« ingénierie pilotée par l’IA » est réellement pertinente, mais pour moi, au moins, écrire moi-même les blocs de code à la main est plus amusant et me permet au final de mieux réussir le résultat. Vidéo liée, 5 minutes
En utilisant Claude Code, je passe bien plus de temps à réfléchir. Je n’avais jamais eu auparavant à décrire une fonctionnalité voulue en 400 à 600 mots ; aujourd’hui, je structure bien davantage mes idées. Ces efforts de réflexion donnent des résultats plus rapides et meilleurs, mais en même temps ma compréhension du code est un peu moins bonne qu’avant. En revanche, je ne peux pas être d’accord avec l’idée qu’un développeur expérimenté réfléchit moins lorsqu’il utilise Claude Code. À mon avis, beaucoup de gens utilisent probablement les agents de manière inefficace, presque uniquement avec des prompts, mais je ne pense pas que ce soit la faute de l’agent
Quand je lis ce genre de discussions, j’ai l’impression que nous sommes encore dans une phase de transition ambiguë. D’ici l’année prochaine, ce type de débat risque de paraître comme un excès de réflexion. Cela me rappelle l’époque où, avant et après la généralisation d’Internet, on voyait beaucoup de doutes du type « effet de mode passager » ou « mauvais investissement »
Ce que ces articles ratent souvent, c’est ceci
J’aimerais lire un article qui se contente de classer de manière systématique les avantages, inconvénients et arbitrages des assistants de code IA. Il faut une discussion sans jugement moral de valeur (bien/mal). Je reconnais que lorsque la « compétence en code » fait partie de son identité, il est particulièrement difficile d’aborder cela froidement
Chaque jour, je m’encourage en me disant : « tiens encore 30 ans et tu pourras prendre ta retraite ». Dix ans dans le machine learning, et je suis fatigué de l’ordinateur comme du travail. J’ai juste envie de me rouler dans l’herbe
Le graphique « réflexion & codage vs réflexion & correction » est intéressant. Récemment, en utilisant Codex, je m’attendais clairement à ce que l’IA me pousse à beaucoup corriger mon code. En réalité, quand la cause du problème n’a rien à voir avec le code, cela consomme un temps énorme. Récemment, j’ai passé très longtemps à fouiller uniquement le code à cause d’un problème d’authentification, avant de découvrir que la cause venait en fait d’un défaut de configuration ipv6 de la VM
Je comprends tout à fait. Quand on fait du codage avec l’IA, il y a tellement de travail de post-traitement que c’est très difficile de l’intégrer à un vrai business et d’en assurer la maintenance.
Même en avançant dans une logique de développement en binôme, en multipliant autant que possible les allers-retours, comme certaines parties du code n’ont pas été écrites directement par soi-même, il arrive souvent qu’elles s’évaporent de la tête.
Je pense qu’il est indispensable de poser des limites.