- L’auteur n’utilise pas les outils d’IA pour coder, principalement parce qu’ils ne le rendent pas plus rapide
- Il estime que le temps nécessaire pour relire et comprendre le code généré par l’IA peut être plus long que celui requis pour l’écrire soi-même
- Comme la qualité du code et la responsabilité restent à la charge du développeur, utiliser du code IA sans relecture est risqué
- En réponse à l’idée qu’il faudrait voir l’IA comme un stagiaire, il critique cette analogie en disant que l’IA ressemble plutôt à un stagiaire atteint d’amnésie puisqu’elle n’apprend pas
- En expliquant la différence entre les contributions open source et le code IA, il souligne que l’interaction humaine apporte de nouvelles idées, ce qui lui donne de la valeur
Introduction
- Beaucoup de gens lui demandent s’il utilise des outils de codage en IA générative et ce qu’il en pense
- Dans cet article, il se limite à son expérience technique personnelle, en dehors des positions pour ou contre
- Il explique, d’un point de vue technique, pourquoi l’IA ne l’aide pas dans son travail de développement
L’IA n’est pas plus rapide
- Même avec des outils de codage en IA générative, sa vitesse de travail n’augmente pas
- Même si l’IA écrit du code, la responsabilité du code lui revient, et il doit relire l’ensemble avec soin et le comprendre complètement avant de l’intégrer au projet
- La revue de code demande autant de temps et de concentration que l’écriture elle-même, et il existe même un adage du secteur selon lequel « lire du code est plus difficile que l’écrire »
- Faire confiance au code produit par l’IA comme à une « boîte noire » est un choix très irresponsable. En cas de défaut, la responsabilité juridique et financière incombe aussi au programmeur
- Sans baisse de qualité ni augmentation du risque, il est impossible d’obtenir grâce à l’IA un gain de productivité ou de revenus
L’IA n’est pas un outil de levier
- Certaines personnes affirment que les outils de codage IA multiplient l’efficacité, mais cela ne relève à ses yeux que d’une impression subjective
- Certains utilisateurs gagnent du temps en utilisant le code généré par l’IA sans relecture, ou avec une relecture partielle, mais comme il ne peut pas sauter cette étape, cela ne l’aide pas
- Il n’adhère pas non plus à l’idée que l’IA serait efficace pour apprendre un nouveau langage ou une nouvelle technologie. Le processus d’apprentissage lui-même fait partie du plaisir de programmer
- En pratique, il apprend directement diverses technologies comme Rust, Go et TypeScript, et ne délègue pas cette expérience à l’IA
- C’est parce que la responsabilité de tout le code lui revient en définitive
Le code IA est différent du code humain
- Il est souvent confronté à la question suivante : « Le code d’une contribution open source n’est pas non plus écrit par moi ; pourquoi le traiter différemment du code IA ? »
- En réalité, il consacre aussi du temps à relire soigneusement les PR open source. Mais la collaboration avec d’autres personnes apporte de nouvelles idées et de la motivation
- Certains affirment que faire tourner plusieurs agents IA pour recevoir des PR qui corrigent des bugs est un game changer, mais comme le goulet d’étranglement de la revue de code reste humain, cela ralentit au contraire le processus
- Avec la généralisation des outils IA, des PR de faible qualité sont fréquemment générées. Le code IA a souvent quelque chose de subtilement étranger, et lorsqu’on pose des questions à l’auteur de la PR, il arrive souvent qu’il ne réponde pas
- La responsabilité dans la contribution de code et la communication au sein de la communauté open source constituent une différence essentielle du code humain
La différence entre l’IA et un stagiaire
- Certains comparent l’IA à un stagiaire, mais les deux sont fondamentalement différents
- Le code produit au début par un stagiaire demande beaucoup de relecture et de temps, mais il progresse rapidement grâce au feedback
- L’investissement dans sa progression finit par en faire un collègue important à qui l’on peut confier des tâches de façon autonome
- Les outils d’IA oublient leurs connaissances à chaque nouvelle tâche et repartent de zéro ; ils ne peuvent ni progresser ni accumuler du savoir-faire
- Cela revient à un stagiaire qui ne s’améliore jamais, et qui ne peut donc pas contribuer à la productivité
Conclusion
- L’auteur veut montrer clairement, à travers ce texte, les problèmes techniques posés par l’adoption d’outils de codage en IA générative
- Dans le codage avec l’IA, il n’existe pas de « repas gratuit »
- Les affirmations selon lesquelles l’IA permet d’aller plus vite ou d’être plus productif viennent soit d’un abaissement des exigences de qualité avec une prise de risque supplémentaire, soit de l’intérêt des vendeurs d’IA
- Les programmeurs doivent toujours garder à l’esprit qu’ils sont les responsables finaux du code
5 commentaires
Je me suis complètement installé sur le mode agent de copilot (claud) + codex (3 modèles en parallèle : o3/4o/codex-mini via MCP), mais je pense que l’efficacité varie énormément selon le profil de la personne qui l’utilise et celui du projet.
De mon côté, je lance des tâches en parallèle sur 5 à 6 workspaces et je vérifie au fur et à mesure dans l’ordre où elles se terminent ; comme le modèle peut même aller inspecter et valider l’intérieur du code open source, je trouve ça plutôt efficace. Si je lance des tâches pendant la pause déjeuner, une ou deux sont souvent déjà terminées ensuite. Il arrive aussi que ça tourne toute la nuit, mais comme le rate limit de copilot est une boîte noire...
Même pour des tâches qui prennent du temps aux humains à cause des nombreux changements de contexte, comme des kernels haute performance, la simplification de toute la call stack ou l’amélioration de la lisibilité, il y arrive si on lui donne un bon prompt et un objectif clair (puisqu’il peut garder en mémoire plus de code qu’un humain). Du coup, relire les patchs sur ce type de code est assez simple... Et pour ceux qui ont déjà subi des incidents causés par une mauvaise utilisation d’API ou par un bug dans un projet open source lui-même, le fait de faire valider ça de manière rigoureuse par un Agent est aussi plutôt bon pour la santé mentale...
En revanche, le développeur qui l’utilise doit absolument être capable de comprendre les patchs. Et il faut aussi savoir formuler un prompt. Il faut avoir acquis l’expérience nécessaire pour identifier rapidement le problème, le formaliser et le soumettre : c’est seulement à partir de là que ça peut commencer. Un peu comme on ne peut pas développer des kernels haute performance sans formules. Déterminer si le problème se situe au niveau du chip/OS, au niveau de l’application, ou du côté d’une ressource distante, ça reste encore, à mon avis, un rôle de senior.
Après avoir utilisé dans une certaine mesure des outils comme Copilot, ChatGPT et Cursor, je considère qu’ils conviennent bien au rôle de modèles ou de snippets dans les outils de développement, mais pas vraiment à celui d’agent ou de collaborateur.
J’utilise Cursor.
Dans le mode chat, je préfère
askàagent, car je veux malgré tout pouvoir relire puis appliquer à mon code, et dans l’ensemble je partage les mêmes inconvénients que ceux mentionnés dans l’article.Cela dit, je compte continuer à utiliser l’IA générative, car elle produit souvent des idées ou du code auxquels je n’aurais pas pensé, et j’estime donc qu’elle a largement de la valeur comme référence.
Cela correspond assez à mon ressenti, d’après mon expérience personnelle avec l’usage des outils de codage génératif.
Avis Hacker News
Certaines personnes se posent des questions chaque fois qu’elles apprennent un nouveau langage ou une nouvelle technologie ; auparavant, elles faisaient une recherche Google ou postaient sur Stack Overflow puis attendaient une réponse. Aujourd’hui, elles demandent directement à ChatGPT ou Gemini, obtiennent une réponse bien plus vite, et leur productivité s’en trouve fortement améliorée. Je veux souligner que le simple fait d’obtenir rapidement des réponses accélère déjà le processus d’apprentissage.
Si ChatGPT et Gemini peuvent proposer des réponses correctes, c’est parce qu’ils ont appris à partir de connaissances déjà présentes sur le web, notamment sur Stack Overflow. Si tout le monde ne fait plus que poser ses questions à l’IA, les sources publiques de savoir fiables risquent de s’épuiser. Cela ressemble à un retour à l’époque des encyclopédies, quand l’information était collectée et vendue à grand coût. Par ailleurs, ce que critique l’auteur, ce sont les outils d’IA qui écrivent directement du code, et il faut les distinguer des outils qui répondent à des questions.
Il m’est arrivé autrefois de faire planter un programme en utilisant une API peu familière. J’ai collé la stack trace dans Gemini, qui m’a immédiatement donné une piste sur la cause, et j’ai résolu le problème en ne modifiant que deux lignes. Rien qu’avec ce genre d’expérience, on perçoit concrètement la valeur de l’IA. Son grand avantage est d’éviter de perdre longtemps du temps sur des erreurs bêtes dans des domaines qu’on ne maîtrise pas encore.
La recherche met de plus en plus en avant le spam de blogs ; il est plus formateur de repartir des fondamentaux avec une bonne documentation officielle ou des guides utilisateurs bien faits. En lisant une bonne doc d’API, on finit souvent par assimiler naturellement l’architecture globale ou des fonctionnalités supplémentaires. Les exemples de blog ou les tutoriels peuvent résoudre le problème immédiat, mais n’aident pas vraiment à progresser en profondeur. Ils reviennent à faire les devoirs à votre place, et je ne pense donc pas que ChatGPT favorise un véritable auto-apprentissage.
Sur les problèmes difficiles, il faut impérativement vérifier les résultats de l’IA. Si j’ai désactivé l’autocomplétion par IA, c’est parce qu’en pratique le gain d’efficacité n’était pas si grand, et qu’elle introduisait au contraire beaucoup de corrections inutiles. Curieusement, même un modèle local entièrement hors ligne peut déjà fournir des références assez utiles. Les résultats de Gemini intégré à Google ne sont pas très bons non plus. Ce qui m’inquiète surtout, c’est que si les gens ne s’informent plus qu’avec l’IA, de véritables dépôts de connaissance comme Stack Overflow risquent de disparaître.
Pour les petits outils de boilerplate, l’IA est parfaite. Pour des choses simples comme des extensions de navigateur ou des scripts Tampermonkey, on peut presque se lancer immédiatement sans lire la documentation. Pour l’autocomplétion sur du code peu complexe ou de petites modifications, l’IA est aussi très utile. Elle permet de traiter rapidement de petits projets qu’on n’aurait peut-être même pas commencés autrement.
L’avantage potentiel d’écrire soi-même le code, c’est qu’on ancre dans son cerveau un modèle mental solide du problème. Plus tard, cet apprentissage « inconscient » joue énormément lorsqu’il faut résoudre un problème ou intégrer une nouvelle fonctionnalité. C’est en accumulant l’expérience de l’avoir fait soi-même qu’on progresse vraiment. Dans les organisations que j’ai observées, l’introduction des LLM n’a pas entraîné de véritable multiplication de la productivité. Je me demande si on ne confond pas simplement le fait de moins faire travailler son cerveau avec un vrai gain d’efficacité.
Je trouve que cela résume très bien ce phénomène : les gens s’habituent à résoudre les problèmes en dépensant moins d’énergie mentale, et cette impression est ressentie comme de la productivité. Une expérience de Google Research sur l’effet des LLM sur la productivité en 2024 a montré que le groupe utilisant un LLM mettait en réalité plus de temps que celui qui apprenait via un livre, et que seuls les débutants, pas les personnes déjà familières du sujet, voyaient leur score légèrement progresser. Pourtant, beaucoup de participants avaient l’impression d’être plus rapides et plus précis, et les chercheurs ont interprété cela comme un effet de « réduction de la charge cognitive ». Lien vers l’article : https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
Si on dépense moins d’énergie mentale et qu’on peut travailler plus longtemps, ne peut-on pas au final absorber plus de charge de travail ? Même aujourd’hui, 3 à 4 heures restent la limite pour les tâches les plus exigeantes. L’idée est que si l’on peut courir un marathon au rythme de la marche, la production totale peut augmenter.
Je suis d’accord avec l’idée que le codage traditionnel et le codage avec IA sont deux compétences distinctes. Moi aussi, je suis très sceptique vis-à-vis de l’idée que l’IA remplacerait le développement. En revanche, je pense que le « codage avec IA » lui-même, avec la gestion des prompts ou le maintien du contexte, a une courbe d’apprentissage importante, et que beaucoup sous-estiment sa valeur à cet endroit précis. Un peu comme le dessin à la main et la photographie, qui peuvent poursuivre des objectifs fondamentalement différents. Ma manière préférée de travailler est la suivante : « l’IA s’occupe des tâches pénibles, et moi je garde la main sur l’architecture globale et la coordination ».
Le codage basé sur les LLM ressemble moins à une simple autocomplétion qu’à une forme de sous-traitance itérative : définition de la tâche, retour, nouvelle itération, puis encore retour. La différence se joue sur la vitesse de traitement (avantage LLM) et la fiabilité (avantage humain), mais à long terme cette frontière risque de s’estomper. Le point important pour moi, c’est que je suis fondamentalement quelqu’un qui veut manipuler directement les détails du travail. Si j’ai choisi d’apprendre l’infrastructure et la programmation, c’est parce que j’aime creuser ces sujets. C’est pourquoi j’évite les rôles de gestion et préfère continuer à fabriquer moi-même, même en gagnant moins. Je m’y intéresserai peut-être à nouveau quand l’AGI atteindra le niveau d’un collègue. Il est aussi probable que l’appellation même d’IA paraisse beaucoup moins spéciale à l’avenir.
Même si la courbe d’apprentissage du codage avec IA est plus importante qu’on ne le pense, ce n’est pas comparable au piano, qui demande des années d’investissement. Les codeurs IA les plus expérimentés aujourd’hui ont à peine trois ans de pratique, et les modèles changent sans cesse, si bien qu’une partie de l’expérience acquise ne s’applique déjà plus aux générations actuelles. L’absence d’une structure d’apprentissage auprès d’un maître est aussi une limite.
La compétence en codage avec IA a-t-elle vraiment une valeur à long terme ? Je doute de la transférabilité des compétences liées aux outils actuels vers les générations futures. Même si l’efficacité augmente à court terme, il faut garder à l’esprit que ces savoir-faire peuvent devenir inutiles dès que les modèles ou les outils changent.
À mon avis, quelques minutes ou une heure suffisent pour apprendre à coder avec l’IA. Par analogie, ce n’est pas un domaine dans lequel on s’immerge livre après livre comme GDB ou UNIX. De même qu’on ne confond pas dessin et photographie, qui n’ont ni les mêmes principes ni les mêmes objectifs, le codage avec IA est une activité complètement différente du codage classique.
Je ne partage pas cette assurance consistant à dire que si quelqu’un préfère coder lui-même, c’est seulement parce qu’il n’est pas assez compétent en codage avec IA. Rien qu’avec le ROI que j’ai déjà observé via de petits paiements et des essais gratuits, j’ai suffisamment d’éléments pour juger.
En pratique, une culture apparaît où, au lieu d’utiliser l’IA pour relire le code ou vérifier le résultat, on pousse directement en PR le code généré par l’IA et on laisse la revue à d’autres. Dans ce contexte, l’IA générative n’est pas seulement utile : elle a aussi l’effet pervers de servir à refiler le travail.
J’ai vécu la même chose. Quand les managers manquent de compétence, ils ne savent pas distinguer qui crée réellement de la valeur. De mon côté, je tire réellement beaucoup de valeur des agents de codage, mais je pense qu’une organisation peu compétente qui récompense des livrables bâclés pose un problème grave.
Si l’auteur d’une PR continue de soumettre tel quel le résultat de l’IA, alors l’accumulation de retours devrait conduire le responsable d’équipe à soulever explicitement le problème.
En tant qu’utilisateur fréquent de Claude Code, je suis 100 % d’accord avec l’idée que, lorsqu’on examine du code écrit par quelqu’un d’autre, l’écart de temps avec le fait de l’écrire soi-même est presque nul. Les LLM sont utilisables, mais plus on leur cède le contrôle, plus il faut de temps avant d’arriver réellement à une release. Ils ont aidé à soulager mes symptômes de RSI, mais le gain de temps est souvent plus exagéré qu’on ne l’imagine.
On m’a demandé s’il fallait absolument relire le code ; en général, je ne fais surtout que des spot reviews des résultats de l’IA, je laisse l’IA rédiger les documents de spécification, puis je fais moi-même une revue finale approfondie et des tests soignés. D’ailleurs, je ne relis pas non plus de bout en bout, dès le départ, le code de la plupart des bibliothèques open source.
Il y a ici un présupposé : « le code que j’ai écrit moi-même n’a pas besoin d’être examiné depuis un autre point de vue ». En réalité, le moi futur est aussi un lecteur potentiel du code. Le codage avec IA force ce changement d’état d’esprit : définir des critères d’acceptation clairs, puis valider via des tests et des règles cohérentes. Au final, cela pousse vers une culture de développement plus robuste et mieux documentée.
Pour le débogage de bugs avec Claude Code, si on commence par écrire les tests*, l’IA corrige souvent le problème en quelques minutes. Depuis l’ajout d’une nouvelle fonction de recherche, même les tâches complexes peuvent être traitées en 5 minutes ; sur ce point, le gain de temps est très clairement perceptible.
Comme solution aux symptômes de RSI, je recommande aussi de toujours garder les bras au chaud.
Quelqu’un s’interroge : « Je n’ai pas envie de tout traiter via une interface conversationnelle ; existe-t-il des exemples d’UI hybrides ? »
Les outils de codage en IA générative n’accélèrent que les parties faciles du travail, et rendent au contraire les parties difficiles encore plus difficiles. En réalité, le temps passé à coder en lui-même n’est pas si important ; donc même si cette partie allait 100 fois plus vite, la productivité globale ne changerait pas tant que ça. C’est pourquoi je n’ai pas spécialement envie d’y consacrer du temps.
Si l’on est déjà un ingénieur qui maîtrise parfaitement une stack et un domaine de problème donnés, on n’a besoin d’aucun outil ni d’aucun apprentissage supplémentaire. Mais ce raisonnement n’a pas beaucoup de sens en pratique. Au final, le choix des outils relève d’une optimisation individuelle.
Je demande à l’IA d’écrire des algorithmes, d’expliquer l’origine d’un code, d’effectuer des appels d’API, d’implémenter certaines fonctions, etc. Pas forcément un programme complet, mais je l’utilise de plus en plus en combinaison avec le débogueur.
Une question posée sur le ton de la plaisanterie : et si tu étais plombier ?
Quand l’auteur dit que « relire le code écrit par quelqu’un d’autre peut prendre autant de temps, voire plus, que d’écrire soi-même », cela me parle aussi, moi qui ai de l’expérience dans des revues de code très minutieuses comme les audits de sécurité. Mais si l’IA se spécialise dans des tâches routinières très simples, on pourra peut-être se contenter d’une vérification globale, un peu comme un vérificateur eBPF, sans avoir besoin d’examiner le code en détail. S’il y a un sujet trop complexe, je rejette simplement la PR. Pour du code simple et répétitif, il est moins nécessaire qu’un humain fasse une relecture minutieuse.
Mais je me demande si c’est vraiment une méthode efficace. S’il faut ouvrir des dizaines de PR pour n’en accepter qu’une seule, autant faire confiance au code d’un collègue. Une structure qui gaspille du temps, de l’argent et des ressources environnementales n’est pas souhaitable.
Si c’est vraiment une « fonction Go répétitive », on peut se demander si ce code méritait d’être écrit. S’il s’agit d’un code inefficace, peu réutilisable, alors qu’une ou deux lignes d’une bibliothèque courante suffisent, je ne vois pas l’intérêt de le faire générer par IA.
L’IA générative est utile pour les personnes qui lisent le code plus vite qu’elles ne l’écrivent ; à l’inverse, pour celles qui écrivent plus vite qu’elles ne lisent, elle est peu utile.
Quelqu’un soulève la question de savoir pourquoi il faudrait contrôler différemment le code écrit par l’IA par rapport à celui écrit par un humain.
Pour les tâches répétitives et simples, les liaisons de templates de l’IDE et l’autocomplétion des variables suffisent largement, avec en plus l’avantage d’être gratuites.
Dans la comparaison entre les stagiaires et les assistants de codage IA, le stagiaire apprend réellement le code, le métier et l’historique du système, alors qu’avec l’IA il faut réexpliquer sans cesse le contexte. Cette limite demeure.
Certains estiment qu’en stockant le contexte important dans des fichiers mdc, le prochain responsable pourra lui aussi s’y référer, ce qui améliore au contraire la documentation et la continuité des connaissances.
Pour certains LLM, c’est précisément ce qui fait gonfler les system prompts jusqu’à 14k.
Un stagiaire, lui, s’en soucie souvent vraiment.
On peut aussi tout simplement placer le contexte métier important dans le system prompt.
Les modèles d’IA actuels apprennent essentiellement des schémas présents dans les données existantes. Ils combinent des modèles de réussite, mais ne sont pas structurés pour faire émerger des solutions radicalement nouvelles à partir des fondements. Face à un problème, ils cherchent d’abord la réponse dans l’expérience la plus ressemblante, plutôt que d’aborder la question depuis les principes premiers. Les experts humains, eux, sont doués pour ce raisonnement à partir des first principles, que l’IA maîtrise mal. L’IA privilégie la similarité et propose donc des solutions formatées ; ses limites sont particulièrement nettes dans les domaines qui exigent de l’innovation ou dans les problèmes où les conventions habituelles ne fonctionnent pas. Même sur le context poisoning, les humains réagissent beaucoup plus efficacement.
Je n’attends pas grand-chose de l’IA dans la génération de code, mais sur les tâches répétitives et ennuyeuses de boilerplate, elle est N fois plus rapide — subjectivement, un écart énorme. Exemple concret : j’ai demandé à ChatGPT un exemple de structure de modale basée sur React Context, et il m’a immédiatement sorti toute la chaîne hooks, provider, etc. Cela m’a fait gagner environ 30 minutes ; pour ce genre de travail répétitif, 20 dollars par mois sont largement rentabilisés.
Dans ce genre de cas, on peut aussi souvent repartir d’un exemple dans la documentation d’une bibliothèque, et en 5 minutes on peut implémenter soi-même l’essentiel du strict nécessaire. Mais le code généré propose généralement une solution globale adaptée à la situation du moment, ce qui devient au contraire peu pratique ensuite pour des améliorations structurelles progressives ou du refactoring.
Moi aussi, j’utilise surtout l’IA pour le boilerplate ou des scripts ad hoc. Pour les problèmes complexes du monde réel, il est encore difficile de lui confier entièrement le travail. En particulier pour les problèmes qui exigent de plonger profondément dans le système, il vaut mieux qu’un humain s’en charge directement, car les insights obtenus pendant le processus sont importants. J’ai le sentiment que plus le projet est grand et plus les éléments sont imbriqués, plus les limites de l’IA deviennent visibles.