L’IA est en train de me rendre stupide
(jpain.io)- Écrire avec l’IA est une tentation puissante pour rédiger des articles, du code et de la documentation, mais cela alimente l’inquiétude de voir diminuer sa capacité à écrire et à réfléchir par soi-même
- En relisant les résultats produits par l’IA, on a l’impression que « ça fait juste IA », et qu’ils ne reflètent ni sa propre voix ni ses intentions
- Depuis un à deux ans, l’auteur s’est fortement reposé sur l’IA pour coder, au point de n’écrire presque plus que des prompts, ce qui nourrit le sentiment de perdre la capacité d’écrire du code soi-même
- Il essaie désormais de réapprendre à coder à la main, estimant qu’après l’IA aussi, on aura toujours besoin de personnes capables de lire et d’écrire du code
- L’envie même de coller un texte dans Claude pour le vérifier relève du doute de soi, et l’IA devient ainsi quelque chose qu’il faut affronter comme une anxiété sur laquelle elle prospère
L’angoisse que l’usage de l’IA affaiblisse les capacités d’écriture et de programmation
- Écrire avec l’IA est extrêmement tentant pour rédiger des articles, du code et de la documentation, mais cela donne le sentiment de réduire sa capacité à écrire directement par soi-même
- Autrefois, sans se considérer excellent en écriture ou en développement logiciel, l’auteur pensait avoir un certain niveau, mais plus il utilise l’IA, plus il a l’impression que ses compétences se dégradent
- En relisant ce qui a été écrit avec l’IA, cela donne l’impression que « ça fait juste IA » ; le résultat ne correspond ni à sa façon de parler ni à son intention, et n’exprime pas correctement ce qu’il veut dire
- Cette inquiétude nourrit le doute de soi et le syndrome de l’imposteur, au point de se demander s’il est encore réellement capable de produire lui-même un résultat
Pourquoi réapprendre à coder à la main
- Depuis un à deux ans, l’auteur a utilisé l’IA de manière quasi exclusive pour coder, en n’écrivant presque plus que des prompts, avec le sentiment de ne plus avoir tapé lui-même la moindre ligne de code
- Il a ainsi l’impression d’avoir oublié en grande partie comment coder, et la perte de cette activité qui était autrefois au centre de sa vie lui paraît triste et déprimante
- Il est maintenant en train de réapprendre par lui-même à coder à la main
- Il estime que, même avec l’IA, les compétences en développement logiciel ne disparaîtront pas complètement
- On aura toujours besoin de personnes capables de lire et d’écrire du code
- Leur nombre pourra diminuer, mais ces profils resteront nécessaires
- Il espère que l’IA pourra peut-être inverser la tendance des 20 à 30 dernières années de demande excédentaire pour les développeurs logiciels
- Comme l’explique Robert Martin (Uncle Bob) dans ses conférences, avant que l’informatique ne devienne un métier, la programmation était pratiquée par des spécialistes comme des physiciens, des mathématiciens ou des universitaires
- Avec l’explosion de la demande en développeurs logiciels, il estime que le niveau d’expertise s’est dilué
- Même lorsqu’il écrit un texte sans IA, il craint qu’il y ait quelque chose d’étrange ou des éléments manquants, et ressent l’impulsion de le coller dans Claude pour vérification
- Cette impulsion elle-même est ce doute de soi dont l’IA se nourrit, et reste un adversaire contre lequel il faut lutter
1 commentaires
Avis sur Hacker News
Je ne suis pas vraiment d’accord avec cette thèse. Chaque fois que j’écris du code avec l’IA, je me bats avec cette sensation désagréable de devoir repasser sur tout ce qu’elle a fait et le compléter ou le corriger avec mon propre code
Il y a bien le shoot de dopamine qui vient du vibe coding et du fait d’obtenir une app fonctionnelle en quelques minutes, mais ce malaise compense largement, et je ne pense pas qu’il disparaisse de sitôt
Cela dit, c’est sans doute parce que j’ai de l’expérience ; si j’avais été développeur junior ou intermédiaire, j’aurais très bien pu tomber dedans moi aussi. Sans les cicatrices accumulées au début de ma carrière à force de me faire reprendre en code review par des mentors compétents, je n’aurais probablement pas eu ce réflexe
Ce que produit Claude doit être relu très attentivement ; sinon, la base de code ne fait que grossir et tendra vers 100 % de dette technique
Je relis tout ce que Claude produit, et dans 90 à 95 % des cas, ça finit en « wow, ça marche. Mais il y a beaucoup trop de code. Allez, maintenant on va passer 3 heures main dans la main à le réduire jusqu’à ce qu’il n’y ait plus rien à enlever »
Il faut trouver une meilleure manière de collaborer avec les agents. Si l’humain relit les parties importantes et « sous-traite » le reste, on peut arriver plus vite à du code et à une conception qui se comportent comme si on les avait programmés soi-même
Moi aussi, je relis environ 90 % du code écrit par les agents, mais c’est quand même bien plus agréable d’écrire ou de dicter quelques prompts que de taper des dizaines de milliers de caractères et de naviguer sans arrêt entre les fichiers. Je suis peut-être simplement fatigué de taper
En revanche, pour les corvées longues et ennuyeuses, je conçois une architecture claire, puis je confie l’implémentation à l’IA. Il faut quand même repasser derrière ensuite pour vérifier qu’elle n’a pas fabriqué n’importe quoi
Exemple récent : dans un jeu que je fais avec Godot, Codex a essayé de réimplémenter depuis zéro un comportement déjà fourni par Area2D
Dès qu’on demande quelque chose de significatif à l’IA, on se retrouve avec un terrain miné de pièges et de choix bizarres. Peut-être qu’avec des centaines de dollars de tokens ce serait différent, mais à 10 dollars par mois, ça ne vaut pas la peine de se payer ce genre de casse-tête
Et puis mon projet est un hobby, et coder reste amusant. Je ne confie à l’IA que les parties pénibles comme la sauvegarde/chargement, le parsing de fichiers de données ou les menus de configuration, et je la tiens à distance dès qu’un jugement humain est nécessaire
J’aimerais croire que, moi, j’aurais utilisé les agents pour creuser davantage et apprendre plus vite. À l’époque, il fallait bricoler des solutions à partir de Stack Overflow, de plusieurs canaux IRC, de Reddit, etc., et ce n’était pas simple
Mais à la fac, j’ai aussi copié des devoirs sans vraiment vérifier les réponses, donc je n’en suis pas sûr. Cela dit, je ne programmais pas seulement pour décrocher mon diplôme ; ça m’intéressait vraiment, donc ça aurait peut-être été différent
Quoi qu’il en soit, je suis content d’avoir déjà accumulé beaucoup d’expérience et d’échecs avant l’arrivée de l’ère des LLM
Le code que j’écris moi-même est meilleur à chaque fois que celui de Claude ou GPT
Une fois, j’ai extrait les spécifications d’un projet déjà écrit, puis j’ai demandé à un LLM de le réimplémenter uniquement à partir de ces specs avant de comparer les deux versions : la version LLM était un vomi absolu
En tant que développeur, tout ça ressemble dans une certaine mesure à une forme de sécurité de l’emploi
J’utilise les LLM depuis un moment, je trouve ça plutôt bien, et j’aime m’en servir. J’ai vibe-codé quelques apps, et voir une idée prendre vie immédiatement donne une vraie poussée de dopamine
Mais d’après mon expérience, si on leur fait confiance aveuglément, on finit forcément par se faire mordre. Même sur mes projets vibe-codés, ils continuent d’ajouter des « fonctionnalités » que je n’ai jamais demandées
Sur un projet perso, ça ne me dérange pas tant que le résultat final ressemble à ce que j’attendais, mais les entreprises ne seront probablement pas aussi souples. Et les clients n’aimeront sans doute pas non plus voir des fonctionnalités changer ou s’ajouter à chaque correctif ou mise à jour
Si je résume la situation actuelle : beaucoup d’entreprises vont dans cette direction, et sans vraie ingénierie, l’IA peut écrire davantage de code tout en modifiant l’app de façon non intentionnelle
À cause de la peur de l’IA et de la baisse des embauches, il y aura moins de jeunes ingénieurs qui entreront sur le marché
Une fois qu’on atteindra un seuil critique d’usage de l’IA, d’énormes changements vont s’accumuler, et les gens chargés de les « prompter » risquent d’être dépassés
Il y aura plus de fonctionnalités à garder en tête. Comme on ne peut pas faire confiance à 100 % aux LLM, les développeurs devront toujours savoir exactement ce que fait l’application
Au final, cela créera beaucoup de bugs, et les développeurs se plaindront d’avoir besoin de renfort. Puis les embauches reprendront
En ce moment, la position la plus difficile est celle des nouveaux développeurs, et la meilleure semble être celle des gens déjà en place sur le marché
Elles ne faisaient presque rien pour préparer la réussite, embauchaient aveuglément l’option la moins chère, lui jetaient des exigences floues, puis assuraient très peu de revue technique ou de supervision continue
La dynamique ressemblait à ce que tu décris. Au début, ça paraissait être un succès, parce qu’un prototype montait vite avec le code le plus sale imaginable ; mais avec le temps, la dette technique et les mauvaises décisions devenaient des freins de plus en plus lourds, jusqu’à ralentir le projet, puis le bloquer ou le tuer
Cette fois sera peut-être différente, mais une grande partie de mon début de carrière a consisté à remettre d’aplomb des projets de ce genre. J’aimerais que les développeurs qui arrivent aujourd’hui aient eux aussi droit à ce type d’opportunités
D’abord, le gain d’efficacité est énorme. Plus grand que n’importe quel outil à n’importe quel prix. Le produit principal de notre entreprise est une web app, et depuis quelques années nous réécrivons ce produit
En un après-midi, j’ai pu créer un nouveau projet avec la stack voulue et vibe-coder en quelques heures une MVP de ce produit sur lequel nous travaillons depuis longtemps
Ce n’était pas parfait, mais j’ai demandé les fonctionnalités une par une avec de petits prompts, chacune prenant 5 à 10 minutes. Le résultat avait l’air assez pro et, selon n’importe quel critère raisonnable, c’était « suffisamment bien »
Avec un peu plus de temps, j’aurais probablement pu lancer et maintenir seul quelque chose qu’une petite équipe avait mis des années à construire. Malheureusement, on n’est pas face à un simple outil de gain d’efficacité, mais plutôt à une « alternative bon marché à une équipe entière »
Et il y a aussi la surchauffe IA des CEO non techniques. Notre CEO et nos dirigeants ont totalement adopté la panoplie d’outils d’agents de Claude, et ils fabriquent chaque jour des mockups, des apps et des chaînes d’outils
On voit bien qu’ils sont devenus accros, et ils ressentent directement les bénéfices. Ce n’est pas encore arrivé, mais je ne serais pas surpris que le CEO licencie la majeure partie de l’équipe de développement et vibe-code toute l’app avec seulement quelques développeurs chevronnés
Pour l’instant, ils disent « l’IA n’est pas un remplaçant, c’est un multiplicateur ! », tout en ajoutant dans la même phrase : « si ça nous permet de ne pas embaucher pendant les prochaines années, c’est gagné ! »
On m’a posé de front la question de savoir pourquoi on ne pourrait pas vibe-coder l’ensemble de l’app, et je n’avais pas vraiment de réponse. J’ai bien quelques arguments plausibles du genre « on ne saura pas comment maintenir l’app », mais Claude est capable d’en faire beaucoup, même dans les mains d’un seul développeur
On dit aussi que « l’IA peut modifier l’app de manière non intentionnelle et introduire des bugs », mais avec la bonne observabilité, des tests et quelques prompts supplémentaires, on peut souvent corriger ça en quelques minutes ou quelques heures
Honnêtement, je ne suis plus sûr qu’il soit encore rationnel pour une entreprise de conserver une équipe de développement complète. On peut lancer tellement de projets et d’initiatives de plus que le backlog diminue vite, et le débit individuel de chaque développeur devient absurde
Les CEO non techniques ne s’intéressent ni à la dette technique, ni à la dette cognitive, ni aux mauvaises pratiques de conception logicielle, ni à l’apprentissage du code, ni au fait de garder des développeurs affûtés, ni au plaisir de résoudre des problèmes, ni à l’élégance d’un bon algorithme ou d’une bonne architecture
Ce qu’ils veulent, c’est un produit qui fonctionne à peu près, apporte de la valeur, mérite qu’on paie pour lui, et soit mis sur le marché avec l’investissement le plus faible possible. Et malheureusement, l’IA coche presque toutes ces cases
J’espère que l’énorme quantité de nouveau software créé fera monter la demande, mais j’ai peur que cela ne suffise pas à compenser l’énorme hausse de capacité de production apportée par l’IA
J’ai réservé du temps le mois prochain pour apprendre TypeScript. Je n’ai pas l’intention d’exclure totalement l’IA de ce processus
Mon plan est de lire un livre du début à la fin, puis d’écrire du code. Je crois avoir entendu Mitchell Hashimoto recommander cette méthode dans un podcast
Comme dans le billet d’origine, j’ai passé beaucoup de temps à faire du prompt coding, donc j’ai hâte et en même temps ça me fait peur
Ne pas écrire du code à la main ne peut pas te rendre moins intelligent. Si c’était possible, il faudrait devenir plus bête chaque fois qu’on part en vacances
Parler avec un chatbot ne détruit pas les connexions neuronales de ton cerveau
Ce qui se passe réellement, c’est que tu mets temporairement au repos une compétence hautement technique. N’importe qui sur Terre « oublie » une partie d’une compétence s’il ne l’utilise pas pendant un moment
Mais l’information n’a pas disparu : elle a simplement été reléguée derrière des informations jugées plus pertinentes. Une petite révision, et ça revient
Même avant l’IA, il m’arrivait de passer plusieurs mois sans écrire un programme complet dans telle ou telle langue. J’oubliais même des choses simples, comme la façon de commencer une définition de fonction
Mais je ne l’avais pas vraiment oubliée ; il suffisait de jeter un œil à une fonction existante pour que me reviennent aussi toutes les autres syntaxes possibles autour de la définition de fonction. Pas de quoi paniquer, ton cerveau fonctionne normalement
À l’école, on parle beaucoup des risques de l’IA, mais les mêmes risques s’appliquent à n’importe quel environnement d’apprentissage
J’ai récemment commencé un nouveau travail, et l’IA rend mon onboarding beaucoup plus difficile. J’avance beaucoup plus lentement dans la prise de poste que mes collègues qui l’utilisent moins
Je code dans un langage que je connais mal, donc la tentation du vibe coding est d’autant plus forte. Malgré tout, j’ai encore assez de niveau pour reconnaître quand Claude répond n’importe quoi ou se montre inutilement verbeux
Mais plus je passe de temps à demander à Claude d’écrire du code, moins j’ai l’impression de développer les compétences que ce poste exige de moi. Même quand j’ouvre une PR, je ne me sens pas bien parce que je n’ai pas la confiance nécessaire dans mon propre travail
Honnêtement, il y a aussi autre chose : je demande à Claude d’aller chercher dans Slack et dans la documentation des réponses à des questions que je devrais poser à des humains
L’IA nourrit mon anxiété sociale et me tente à éviter des contacts humains pourtant utiles à la compréhension, et même nécessaires à des interactions sociales de base
Ça peut ressembler à une manière d’esquiver mes responsabilités, mais il faut souligner qu’une technologie donnée peut être particulièrement addictive pour certains profils et les enfermer dans des boucles de comportement négatives
Si je repousse ma dépendance à l’IA maintenant, je pense que plus tard j’aurai développé assez de compétences pour déléguer à l’IA les tâches répétitives et les résultats faciles à vérifier. C’est difficile, mais nécessaire
Comme ça, tu peux apprendre en cours de route. Pas besoin de l’utiliser comme un moteur de recherche : demande simplement ce que tu dois savoir à cet instant, et la chaîne de tokens remuera pour te sortir quelque chose d’utile, surtout si tu débutes dans le langage
De cette manière, tu peux mettre en pratique ton idée de commencer par développer tes compétences, puis de déléguer ensuite
C’est comme ça que je fais, et pour moi c’est un bon équilibre. Faire écrire par Claude du code qu’on n’est pas capable d’évaluer me paraît complètement fou, mais j’ai l’impression que cette opinion est minoritaire
En dehors du vibe coding, c’est en fait l’un des rares vrais cas d’usage que j’ai rencontrés personnellement
Je n’utilise pas l’IA pour remplacer la réflexion, mais pour m’éviter d’écrire du code répétitif et ennuyeux. Une fois le prototype implémenté, l’IA est suffisamment compétente pour écrire le code
J’écris moi-même le prototype brut de preuve de concept, sans commentaires, avec des variables codées en dur, ce genre de choses. Ensuite, l’IA le polit pour en faire quelque chose de niveau produit
Cela me permet de diriger une équipe d’agents plutôt que de gérer des personnes dont l’éthique de travail, le niveau, ou la capacité à maintenir une haute qualité de code varient énormément
L’IA est aussi souvent assez bonne pour respecter les patterns existants d’une base de code ou pour se conformer aux bonnes pratiques du secteur
Avec l’IA, je n’écris plus autant qu’avant dans un langage de programmation. Que ce soit l’anglais ou la langue dans laquelle on parle au LLM, ce sera désormais le langage principal
En ce moment, je passe l’essentiel de mes journées à corriger les imperfections produites par des robots générateurs de code
Après, je ne suis pas en train de peaufiner un prototype : je maintiens, fais évoluer et modernise un produit critique vieux de plus de huit ans
Honnêtement, dans un projet donné, ça représente quelle part de code répétitif pénible ?
Il faut des prompts très soignés, donc il faut bien comprendre le framework et le langage sous-jacents. Sinon, l’ensemble devient un chaos épouvantable
Et je ne vois même pas bien comment gérer plusieurs agents. En général, ils finissent assez vite. On n’a même pas le temps de faire autre chose entre deux exécutions. On reste dans un état permanent de « encore une minute et c’est fini »
Et une fois terminé, il faut évaluer la sortie. Du coup, même pendant le « travail », on n’arrive pas à penser en profondeur. Le schéma ressemble aux réseaux sociaux : attention continue, récompense quasi immédiate
Résultat, la capacité de concentration se dégrade en permanence, et sérieusement
Le problème, c’est que ce plan s’évapore en quelques heures, puis il faut analyser la sortie et itérer pour filtrer toutes les absurdités
Gérer les sorties de plusieurs agents, c’est un changement de contexte permanent. Bon courage sur le long terme
Si on laisse les agents courir librement et produire n’importe quoi, la sortie sera presque à coup sûr un chaos total. Point final
Sur mon projet actuel, je code tous les jours en Java, Ruby et JavaScript. Je gaspille beaucoup de tokens à vérifier des différences entre langages qu’un simple Google suffisait autrefois à confirmer
Je confonds sans arrêt des choses comme la différence entre les opérateurs null-safe en Ruby et en JavaScript, ou les instructions continue/break en Ruby et en Java
Claude serait probablement déçu si je lui disais que la tâche la plus complexe que je lui demande consiste à refactorer d’anciennes boucles Java vers des streams plus modernes. Ce type de code peut être quasiment impossible à écrire de tête pour un humain
Bonus si on crée soi-même un collector ou si on utilise des coins un peu plus obscurs de la bibliothèque standard
Il y a aussi des contre-exemples. En mode /plan, le fait de faire des allers-retours d’idées avec l’IA, de corriger ses mauvaises hypothèses et de la voir expliciter clairement mes lacunes de connaissance quand c’est nécessaire me semble intellectuellement très stimulant et me donne l’impression de devenir un meilleur ingénieur
Le plus important, c’est d’aborder l’IA de façon socratique, de réfléchir soigneusement à tout ce qu’elle propose, et de ne pas se laisser hypnotiser par son ton assuré et sa logique parfaitement structurée
Moi, j’ai l’expérience exactement inverse. C’est probablement parce que, dans mon domaine, le code/le logiciel n’est pas le produit, mais un outil
J’apprends beaucoup plus vite et beaucoup plus de choses. Par exemple, en ce moment je travaille avec du matériel de spectroscopie comme le Raman ou la RMN, et j’ai demandé à Claude d’écrire du code pour interfacer les appareils au niveau matériel
Au lieu de fouiller les datasheets et d’écrire une masse de wrapper code, Claude s’en est chargé
Discuter avec Claude de différentes techniques, les implémenter, les tester, tout ça me fait avancer bien plus vite. Avant, cette boucle aurait pris 5 à 10 fois plus de temps
Comme je n’ai pas à dépenser d’effort mental sur du code insignifiant juste pour voir un résultat, j’apprends beaucoup plus sur ces appareils, ces techniques et ces données
Je travaille comme développeur depuis plus de dix ans. Je suis heureux d’avoir enfin l’impression d’entrer dans un monde où le code peut vraiment rester un outil, au lieu d’être constamment traité comme le produit
Je ne pense pas que beaucoup de gens auront le privilège de pouvoir encore prendre le temps d’écrire du code à la main
Quand on regarde le code qu’on écrit vraiment, dans mon cas, ce n’est presque jamais quelque chose de nouveau ou de cool, mais plutôt le sempiternel « créer un backend pour X », corriger un bug simple, ou faire des tâches triviales pour des programmeurs intermédiaires à seniors
Les tâches les plus difficiles sont généralement les décisions d’architecture au-dessus du code, et je réfléchis aussi à la manière de construire des systèmes qui empêchent les LLM de partir en vrille quand ils implémentent une fonctionnalité
Ce que je veux dire, c’est qu’aujourd’hui, écrire du code à la main est peut-être encore acceptable, mais qu’à l’avenir les actionnaires ou la hiérarchie voudront qu’on livre des fonctionnalités et corrige des bugs plus vite grâce aux LLM
Si tu n’arrives pas à suivre cette cadence, ta performance sera jugée faible. Au bout du compte, ce qui compte, ce n’est pas ce que nous voulons, mais ce que veulent les actionnaires
Bien sûr, si tu n’es pas épuisé, tu peux toujours écrire du code à la main pendant ton temps libre. Je ne veux pas passer pour un pessimiste, mais je pense que ça va devenir assez réel très vite