L’émergence de l’« enfer du vibe coding » qui remplace l’« enfer des tutoriels »

• Dans l’environnement récent de l’apprentissage du code, l’« enfer du vibe coding » est en train d’émerger comme nouveau problème à la place de « l’enfer des tutoriels »
• Si l’enfer des tutoriels désignait l’état dans lequel on « ne peut rien construire sans tutoriel », l’enfer du vibe coding désigne l’état dans lequel on « ne peut pas coder sans IA et ne comprend pas comment fonctionne le code généré par l’IA »
• L’usage excessif des outils d’IA fait baisser la motivation d’apprentissage, et une situation paradoxale apparaît où les personnes ayant la plus faible littératie en IA utilisent davantage l’IA
• Les outils d’IA, bien utilisés, peuvent grandement aider l’apprentissage, mais un usage consistant seulement à « obtenir la réponse » entrave la construction d’une compréhension solide
• L’essentiel est de réfléchir soi-même et de chercher à résoudre les problèmes par ses propres moyens pendant l’apprentissage ; il est important d’adopter une posture qui accumule de l’expérience de résolution de problèmes sans tutoriels ni assistance IA

---

Contexte du problème : de l’enfer des tutoriels à l’enfer du vibe coding

• En 2019, le principal problème de l’enseignement du code était l’« enfer des tutoriels »
  • On réussissait à suivre les tutoriels, mais on ne pouvait rien construire seul
  • On passait plus de temps à regarder des vidéos sur la programmation qu’à réellement programmer, sans comprendre les concepts clés
  • Au final, on accumulait seulement des connaissances superficielles, sans comprendre les mécanismes internes, au point de ne pas pouvoir écrire du code par soi-même dans des situations réelles
• Pour y remédier, Boot.dev s’est concentré sur trois points
  • Un cursus approfondi : souligner la nécessité d’apprendre les bases de la CS en dehors du cadre universitaire traditionnel
  • Une approche centrée sur la pratique : écrire soi-même du code à chaque apprentissage de concept
  • Renforcer le texte enrichi plutôt que la vidéo : la vidéo comporte un risque de consommation passive
• En 2019, les longues formations YouTube qui cumulaient des millions de vues peinent aujourd’hui à atteindre même 50 000 vues
  • Des chaînes comme FreeCodeCamp, Traversy Media ou Web Dev Simplified illustrent cette tendance
• Pourtant, les données Google Trends sur « learn to code » montrent un intérêt toujours élevé
• Environ 1 300 nouveaux utilisateurs s’inscrivent chaque jour sur Boot.dev, et au cours des 18 derniers mois les plaintes concernant l’enfer des tutoriels ont diminué, mais une nouvelle forme de difficulté est apparue

Définition de l’enfer du vibe coding

• Caractéristiques de l’enfer des tutoriels
  • « Je ne peux rien construire sans tutoriel »
  • « Je ne comprends pas la documentation, donc j’ai besoin de vidéos »
  • « Même pour une tâche simple, j’ai besoin d’un framework complexe »
• Caractéristiques de l’enfer du vibe coding
  • « Je ne peux rien faire sans l’aide de Cursor »
  • « J’ai créé un super tower defense game. Voici le lien : http://localhost:3000 »
  • « Je ne sais pas pourquoi Claude a ajouté 6,379 lignes pour faire du lazy-load d’images »
• Aujourd’hui, les apprenants autodidactes construisent beaucoup de choses, mais des projets qui ne leur permettent pas de développer un modèle mental du fonctionnement des logiciels
• Ils luttent contre les hallucinations de l’IA, se débattent avec des bots focalisés uniquement sur le passage des tests, et font aveuglément confiance au code généré par l’IA plutôt que de résoudre de vrais problèmes

L’avenir et la réalité de l’IA pour le code

• Je suis plutôt optimiste sur le fait qu’à court terme, l’IA ne remplacera pas complètement les développeurs
  • Cela fait trois ans qu’on entend « encore 6 mois avant que l’IA prenne les emplois », et pourtant on continue toujours à recruter des développeurs
• GPT-5 est sorti, mais n’a apporté qu’une amélioration progressive par rapport à GPT-4, ce qui est interprété comme un signe que l’AGI n’arrivera pas de sitôt
• J’utilise des outils d’IA tous les jours, mais je ne suis pas certain de leur impact réel sur la productivité
  • On ne sait pas clairement si l’IA nous rend plus productifs ou plus paresseux
• Résultat de recherche de 2025 : les développeurs supposaient que l’IA augmenterait leur productivité de 20 à 25 %, mais en réalité ils ont été 19 % plus lents
  • Un résultat décevant au regard de 7 000 milliards de dollars investis

Le risque d’une baisse de motivation avec l’IA

• La culture de l’usage de l’IA peut avoir un effet négatif sur la motivation des apprenants
• Ce qui inquiète le plus dans l’engouement (ou la bulle ?) autour de l’IA, c’est l’émergence d’une génération qui se dit : « Pourquoi apprendre ? L’IA sait déjà tout »
• Si l’IA ne remplace pas réellement tous les emplois de cols blancs, on risque de connaître non seulement une bulle boursière, mais aussi une pénurie de main-d’œuvre qualifiée
• Les investisseurs sans bagage technique se méprennent en pensant que « l’IA a déjà complètement remplacé le code », tandis que les développeurs seniors n’ont toujours pas trouvé de manière réellement utile d’intégrer les outils d’IA à leur travail quotidien
• Il est préoccupant de constater que plus la littératie en IA est faible, plus l’usage de l’IA tend à être élevé
  • Cela agit comme le piège ultime du Dunning-Kruger : les personnes les moins compétentes croient au contraire très bien comprendre
  • Les apprenants concluent que le développement personnel n’a plus de sens puisque « l’IA sait déjà »

L’IA est-elle bénéfique pour l’apprentissage ?

• L’intérêt social pour l’apprentissage du code reste élevé
• L’IA peut être bénéfique pour l’apprentissage, mais il existe deux problèmes structurels

• Premier problème : la flatterie (sycophant)

  • Les chatbots d’IA ont tendance à approuver excessivement l’opinion de la personne qui pose la question
  • Si l’on discute de « ROAS », avec les mêmes données, ils peuvent aboutir à des conclusions exactement opposées selon l’angle de la question, tout en répondant avec assurance sur un ton d’expert
  • Cela prive l’apprenant de l’occasion de faire l’expérience de la vérification, de l’esprit critique et de la correction des erreurs
    • Si l’on demande à un expert, c’est pour qu’il nous dise quand nous avons tort
    • IRC ou Stack Overflow le faisaient bien (peut-être même trop bien)
    • Les chatbots à base de LLM ont une forte tendance à ne pas corriger les malentendus fondamentaux des apprenants
    • Aujourd’hui, les étudiants ont des conversations confortables avec des LLM et entendent ce qu’ils veulent entendre plutôt que ce dont ils ont besoin

• Deuxième problème : les apprenants veulent de vraies « opinions »

  • L’IA présente des positions trop équilibrées
    • « Certaines personnes pensent X et d’autres pensent Y »
    • Il devient plus difficile pour l’apprenant de décider avec quel point de vue il est d’accord
  • On a essayé de la pousser à jouer le rôle d’un « capitaliste » ou d’un « révolutionnaire marxiste », mais les résultats n’étaient pas satisfaisants
  • Les apprenants veulent entendre des opinions et des commentaires issus d’une expérience réelle
    • Pourquoi DHH a supprimé TypeScript de Turbo
    • Ce que TypeScript résout pour les développeurs JavaScript selon Anders Hejlsberg
    • Ce sont de vraies opinions, où les biais et le contexte de chaque auteur apparaissent clairement, qui permettent de former des modèles mentaux nuancés
  • Les réponses neutres et prudentes typiques des LLM gênent l’intériorisation réelle des connaissances

Quand l’IA aide vraiment à apprendre

• Bien utilisée, l’IA est un outil formidable pour apprendre
• Il n’a jamais été aussi facile d’apprendre à coder
• Le cas de Boots sur Boot.dev (outil d’assistance pédagogique IA)
  • Les étudiants utilisent presque 4 fois plus le chat avec le tuteur IA (Boots) que la consultation de la solution de l’instructeur (la réponse idéale)
  • Contrairement à un chatbot généraliste, Boots aide l’apprentissage de la manière suivante
    • Il est pré-prompté pour ne pas donner directement la réponse
    • Il utilise une méthode socratique pour pousser l’étudiant à réfléchir plus profondément au problème
    • Il peut accéder à la solution de l’enseignant, ce qui réduit fortement le risque d’halluciner sur la bonne réponse
    • Il a une personnalité ludique (un ours magicien)

Comment sortir de l’enfer du vibe coding

• En conclusion, qu’il s’agisse de l’enfer des tutoriels ou de l’enfer du vibe coding, l’expérience consistant à “ne pas déléguer aux autres et à faire soi-même” est essentielle
  • Enfer des tutoriels : éteindre la vidéo et écrire du code soi-même
  • Enfer du vibe coding : désactiver l’autocomplétion IA comme Copilot et accumuler soi-même de l’expérience de résolution de problèmes
• À éviter :
  • L’autocomplétion IA dans l’éditeur
  • Le traitement d’un projet via le mode agent et des outils d’automatisation IA
• Ce qu’on peut utiliser :
  • Des chatbots qui répondent aux questions, expliquent les concepts et fournissent des exemples
  • Des system prompts qui poussent à poser des questions selon une méthode socratique pour encourager une réflexion plus profonde
  • Des system prompts qui demandent de citer les sources et de lier la documentation lorsqu’une affirmation est avancée, afin d’améliorer la fiabilité de l’information

Principes clés

• Apprendre doit nécessairement être inconfortable
  • L’enfer des tutoriels permet d’éviter cet inconfort en regardant quelqu’un d’autre coder
  • L’enfer du vibe coding permet d’éviter cet inconfort en laissant l’IA écrire le code
• Le véritable apprentissage se produit quand on bloque, qu’on se frustre et surtout qu’on est forcé de résoudre des problèmes
  • C’est ainsi que le réseau neuronal humain se reconfigure
• Si l’on pousse trop loin l’idée que « l’apprentissage doit être difficile », cela peut devenir une excuse pour une mauvaise conception pédagogique
  • L’auteur ne défend pas cette position
  • Même si un concept est expliqué de la meilleure façon possible, l’étudiant doit encore se confronter à lui et l’utiliser lui-même dans un nouveau contexte pour le comprendre réellement
• Le véritable apprentissage s’accomplit en se heurtant directement aux difficultés, en se frustrant et en finissant par les dépasser par ses propres moyens

[aer0700]

C’est un contexte un peu différent, mais si l’enfer des tutoriels se produit, c’est aussi parce que les tutoriels de framework ne sont pas utilisés comme des supports de formation de base en informatique.
Un débutant qui a suivi le tutoriel Django et créé une application de sondage ne peut pas, à lui seul, créer un blog, parce que le tutoriel Django est un texte destiné à expliquer Django à des personnes qui savent déjà ce qu’est HTTP, ce que sont les templates, ce qu’est WS, ce qu’est une base de données, etc. ; ce n’est pas un texte qui explique le web. Un très grand nombre de contextes sont omis dans le tutoriel Django, et je pense que c’est peut-être l’une des causes de l’enfer des tutoriels.
Réécrire le tutoriel Django pour qu’il s’adresse à quelqu’un qui programme pour la toute première fois aujourd’hui serait aussi un exercice intéressant. En commençant par expliquer d’abord la structure de HTTP, puis en montrant comment Django gère chacun de ces éléments, par exemple.

[gudrb963]

C’est vraiment un excellent avis !

[GN⁺]

Avis sur Hacker News

• L’expression « Tutorial Hell » me parle énormément : on regarde un cours de 6 heures et on code en suivant, mais dès qu’on doit créer quelque chose depuis zéro, on est complètement bloqué. C’est ça, le tutorial hell typique. C’est pour ça que, historiquement, l’apprentissage en compagnonnage était la méthode la plus efficace : le junior suit le senior, et un maître artisan supervise l’ensemble, tout en gérant et en guidant le projet. Il est regrettable que notre communauté de développeurs n’ait pas fonctionné comme une guilde pendant si longtemps. À mon avis, on n’aurait déjà plus dû fonctionner ainsi depuis la fin des années 1980. S’il y avait eu des guildes, le nombre même de développeurs aurait probablement été bien plus faible, et l’évolution de l’industrie aurait pu être très différente.

  • Même les développeurs expérimentés trouvent difficile de démarrer un projet ex nihilo. En général, on travaille sur une base de code existante, et même lorsqu’il faut créer une nouvelle app, on part d’un template ou d’un copier-coller. Il est rare de construire quelque chose de vraiment totalement nouveau depuis rien. De la même façon qu’un électricien ne câble pas toujours un bâtiment neuf, un développeur en entreprise a rarement à tout mettre en place absolument depuis le début. Le compagnonnage ne change pas fondamentalement cette structure.

  • D’après mon expérience, les bonnes universités forment les étudiants avec des exercices progressifs et concrets. On commence par des structures de données, des algorithmes simples ou des puzzles, puis on en vient à créer un OS, une base de données, des structures de données persistantes, un compilateur, un CPU, une simulation, voire un modèle de machine learning. On passe d’une simple fonction à la construction directe de quelque chose de plus en plus grand, et j’en suis vraiment reconnaissant. Voir aussi ce lien connexe.

  • J’utilise les LLM pour apprendre à coder comme dans une relation maître-apprenti. Le LLM n’avance que quand je le lui demande ; il explique et guide, mais c’est moi qui écris. C’est bien mieux que de chercher sans fin de nouveaux cours ou tutoriels. En réalité, le tutorial hell est un phénomène créé par des gens qui se prennent pour des enseignants. Tous ces livres et cours n’arrivent finalement pas à vraiment enseigner quelque chose d’utile. Je pense que le modèle actuel d’enseignement du code est complètement erroné. Aujourd’hui, je préfère utiliser les LLM pour résumer la documentation récente d’un nouveau langage ou d’une nouvelle bibliothèque, ou alors établir moi-même un plan d’apprentissage. En revanche, le fait de ne pas être certain qu’un LLM hallucine ou non me gêne un peu.

  • J’ai quitté l’école très tôt à cause de l’ennui et d’une pédagogie poussiéreuse, puis je me suis lancé directement sur le terrain comme apprenti ingénieur logiciel, et le cursus scolaire ne m’a été d’aucune utilité. À la fin des années 1990, c’était une suite ininterrompue d’erreurs et d’essais ; moi, mon maître et même le maître de mon maître apprenions tous en nous heurtant directement aux problèmes. On fabriquait des routeurs ISDN avec Linux, on montait des serveurs web, on touchait à HTML, Perl et PHP, et on vivait une vraie expérience de DevOps et d’ingénierie, même si ces mots n’existaient pas encore. Il y avait très peu de documentation ; on repoussait les limites avec de la créativité et de l’audace. Il y a quelque chose de similaire avec le vibe coding à l’ère de l’IA, même si la pression est bien plus forte aujourd’hui, mais ce sont de très bons souvenirs.

  • Dans la tech, le gatekeeping autour du métier est vu négativement. Cela vient en partie de l’arrogance du secteur, et aussi de la volonté du capital d’élargir le vivier de main-d’œuvre pour faire baisser les salaires. À cause de cela, les vrais standards professionnels ont disparu, et des entretiens humiliants de type LeetCode sont devenus des barrières d’entrée sans rapport avec le métier lui-même.

• En tant que personne qui utilise Zed Pro et GPT tous les jours pour coder, je pense que l’évolution de ces outils met surtout en lumière les inefficacités de la programmation moderne. Le web moderne est à la fois incroyable et terrible. Si la bureaucratie consiste à être enlacé dans des règles complexes, alors le développement moderne en est un excellent exemple. Si même les tâches les plus simples nécessitent les indications d’outils d’automatisation probabilistes, c’est quand même un peu triste. Avant, je disais aux plus jeunes que l’important n’était pas de connaître un langage précis, mais d’avoir la capacité d’en apprendre constamment de nouveaux. Certaines tendances durent, mais au final il faut toujours apprendre de nouveaux outils et langages. Je ne sais pas si c’est l’âge, mais à un moment j’ai eu l’impression que cette complexité débordait. Autrefois, la programmation paraissait trop proche de l’électrotechnique ou des maths ; aujourd’hui, on a accumulé un autre type de complexité.

  • Je ressens ça moi aussi. Comme dans un film de SF, j’ai déjà voulu un environnement informatique où l’on pourrait dire « redirige l’énergie vers l’avant ! » et où les composants ou systèmes seraient immédiatement interchangeables et réutilisables. Mais en pratique, remplacer la caméra d’un téléphone Android par celle d’un iPhone relève presque de l’impossible.

  • Je ne suis pas sûr de bien saisir ce que tu veux dire, mais l’usage du mot bureaucratie me semble étrange. En réalité, la compétence clé, c’est surtout savoir chercher : si quelqu’un sait tout retrouver, il peut pratiquement tout faire. Les outils d’automatisation ne sont pas fondamentalement différents d’un livre ou d’un professeur. Si certaines personnes manquent de cette capacité, c’est simplement une constante humaine, pas une raison de reprocher aux outils de s’être améliorés.

  • Le vrai problème, c’est qu’écrire, rechercher et lire de la documentation est extrêmement difficile. C’est ce qui rend l’apprentissage pénible, mais grâce à l’IA, apprendre est devenu plus facile. Par exemple, elle comprend étonnamment bien des choses comme Unreal Engine.

  • Tous les problèmes qu’on traîne relèvent de la complexité accidentelle dont parle Brooks dans No Silver Bullet. Les LLM aident à traverser cette complexité et même à faire tomber les silos de connaissance accumulés selon les langages et les frameworks.

  • Si cette industrie aussi spéculative continue encore un peu, il se pourrait même qu’on arrive à un monde où la programmation elle-même disparaît.

• Maintenant que tout le monde peut écrire du code, la quantité de code produite à l’échelle de l’organisation a été multipliée par dix, mais le nombre de reviewers n’a pas bougé, donc on n’arrive plus à suivre. Si on ne peut même pas utiliser de LLM pour faire un sanity check du code, alors comment est-on censés s’en sortir ? Hier encore, un non-spécialiste a produit avec Codex un algorithme d’optimisation, puis on m’a demandé de l’améliorer. Le problème, c’est que le code était totalement catastrophique : recherche naïve sur des milliers de combinaisons d’entiers, contraintes mal respectées, et au final des résultats peu fiables. J’ai passé toute la journée à examiner ce code, puis j’ai dû faire une présentation aux dirigeants pour expliquer que, fondamentalement, tout cela ne servait à rien.

  • La réponse au « sanity check du code par LLM », ce sont les tests unitaires. Les LLM génèrent aussi très bien du code de test et du code testable quand on le leur demande. Si les tests appellent réellement le code et vérifient bien les cas limites, c’est bien plus rapide qu’une review de code. On peut aussi y inclure des tests de performance. À l’avenir, on travaillera probablement surtout à partir de déclarations et de tests, et la manière dont les fonctions sont implémentées en interne deviendra de moins en moins importante. C’est un changement de perspective majeur.

  • Il suffit de regarder ce qui s’est passé avec la programmation Excel : au début, tout le monde s’en moque, puis quand ça explose, on dépense soudain des dizaines de milliers d’euros pour réparer les dégâts avant que l’entreprise ne coule.

  • Sur le point « le nombre de reviewers est le même », les LLM peuvent aussi aider à la revue de code. Même GPT-5 est assez bon pour détecter des erreurs locales comme les off-by-one ou des return manquants. En revanche, il a encore des limites sur les problèmes qui demandent une compréhension plus globale de l’architecture. À l’avenir, on pourrait sans doute fine-tuner régulièrement un LLM sur une grande base de code pour l’utiliser comme reviewer de premier niveau sur tous les changements.

  • Les problèmes de OR (optimisation combinatoire) viennent souvent du fait que les codeurs improvisés ne réalisent pas qu’ils ont mis les pieds dans un domaine algorithmique intrinsèquement particulier. Même quand on le leur signale, ils ont souvent du mal à comprendre la théorie mathématique et continuent à vouloir s’en sortir à leur manière.

  • Dans ce genre de situation, faire des présentations techniques aux dirigeants pour leur faire comprendre correctement l’état réel des choses est peut-être, en pratique, la seule manière de réagir.

• Je pensais encore voir revenir l’idée selon laquelle l’IA ruine les développeurs juniors et qu’on va donc manquer de remplaçants pour les seniors. Cet article en parle indirectement, et je suis globalement d’accord, mais la partie sur la complaisance m’a particulièrement marqué. Avant, je pensais que des interfaces comme ChatGPT aidaient à apprendre, mais l’exemple du ROAS sur YouTube m’a frappé. Si, selon la manière dont la question est posée, l’élève peut déformer à volonté la conclusion du professeur, alors une infinité de développeurs débutants vont inévitablement être orientés dans la mauvaise direction. Je ne sais même pas si tout le prompting appliqué à AI « Boot » est suffisant. Au final, même à l’ère de l’IA, il faut toujours que « quelqu’un » rejette régulièrement mes PR pour que je progresse. Et ce « quelqu’un », pour l’instant, ne peut pas être une IA.

  • D’après mon expérience, même quand je demande une critique sévère, l’IA garde quand même une tendance à vouloir me faire plaisir. Anciennes ou nouvelles versions de GPT, c’est pareil. Il y a quelque chose de vaguement dérangeant. Au final, cet outil reste surtout utile à ceux qui savent déjà comment ils veulent être aidés et qui sont conscients des problèmes spécifiques aux LLM.

  • Pour éviter ce phénomène de complaisance, je pose toujours la même question deux fois avec un biais opposé. Mais je n’ai aucun moyen de savoir si l’IA ne renforce pas malgré tout mes biais cachés.

• Je ne suis pas débutant, mais comme je continue à apprendre de nouveaux frameworks, langages et algorithmes, je ne pense pas que l’autocomplétion par IA soit une mauvaise chose. Les anciens autocomplétions comme IntelliSense ou ReSharper m’ont aussi énormément aidé à apprendre de nouvelles bibliothèques ou fonctionnalités de langage. ReSharper recommandait de nouvelles fonctionnalités quand je codais à l’ancienne, et j’ai beaucoup appris comme ça. L’autocomplétion basée sur l’IA me semble être une version bien plus avancée : elle suggère naturellement quelque chose, et je peux l’utiliser ou non, donc ça aide aussi à apprendre. Au final, tant qu’on garde la curiosité de lire et comprendre les suggestions, l’IA rend l’apprentissage plus facile. Avant, on faisait juste des copier-coller depuis Stack Overflow.

  • L’autocomplétion traditionnelle montre toutes les méthodes, variables et constantes du scope concerné, et relie aussi à la documentation. On peut donc juger soi-même quelles options existent, ce qui est vraiment très formateur. L’autocomplétion par IA ressemble plutôt à coller une réponse de Stack Overflow sans explication contextuelle. Quand on apprend, il vaut mieux chercher soi-même sur Stack Overflow ou, si besoin, demander ensuite à un chatbot d’expliquer pourquoi ce code fonctionne ainsi.

  • Je pense qu’il y a quand même une différence. Quand on a déjà un peu d’expérience, utiliser l’autocomplétion dans un nouveau langage est assez naturel. Mais pour un débutant sans bases qui apprend sa toute première boucle for, ce n’est pas la même chose.

  • J’aime la programmation agentique avec l’IA. Construire des choses me rend heureux, et cela fait partie de mon expérimentation d’idées. Je ne déploie pas ce code en production, donc le regard des autres m’importe peu. Pour discuter avec des collègues techniquement brillants, il faut essayer soi-même et apprendre. J’aime programmer depuis l’âge de 10 ans, même si je n’ai jamais été développeur professionnel. Avec l’arrivée de l’IA, mon amour du code et de l’expérimentation a repris vie. J’adore explorer les technologies web du futur comme WASM, différents systèmes, la recherche de bugs, et faire les choses à ma manière. Des outils comme Cursor AI automatisent même ma configuration git et simplifient jusqu’au push en ssh. Bien sûr, je peux le faire moi-même, mais je préfère laisser l’IA s’en charger. J’ai gardé certaines habitudes héritées de mes débuts en C, mais j’aime aussi travailler avec un backend python, un serveur web flask et un frontend JavaScript. WASM Python est encore très immature, mais je continue à expérimenter. J’aime consolider mes bases et apprendre à ma manière. Et je trouve souvent que les ingénieurs ont tendance à rendre les choses plus compliquées que nécessaire.

  • L’autocomplétion par IA est le meilleur des outils : elle propose le code voulu sans documentation, sur quelques lignes seulement, donc c’est facile à relire. Elle ne génère pas de gros blocs automatiquement, donc elle ne nuit pas non plus à l’apprentissage.

• Je ne suis pas débutant non plus, mais Copilot m’a clairement facilité l’apprentissage de Rust. En combinaison avec Intellisense, cela réduit la charge liée à la syntaxe et permet de se concentrer sur les parties importantes du langage. En une semaine, je suis passé de l’ouverture d’un livre sur Rust à un outil fonctionnel. Bien sûr, cela ne fait pas de moi un ingénieur senior, mais ça réduit clairement la barrière du « 0 à 1 ». Je ne demande pas à Copilot d’écrire le code à ma place ; je l’utilise comme une autocomplétion améliorée, en acceptant ou refusant moi-même ses suggestions.

  • Le thème récurrent ici, c’est qu’un senior expérimenté, même s’il ne connaît pas encore un nouveau langage, sait déjà « comment coder » et peut donc tirer de la valeur de ces outils. Peu importe le langage, les code smells restent les mêmes. Un débutant, lui, ne sait souvent même pas ce qu’est un « code smell ».

  • Moi aussi, je pensais autrefois que Copilot m’aidait beaucoup à apprendre Rust, mais quand j’ai essayé de coder sans IA, c’était vraiment difficile. Ce n’est qu’en coupant l’IA pour apprendre qu’on peut sortir de l’illusion de vraiment savoir.

• On retrouve le même problème avec toutes sortes de raccourcis éducatifs : des élèves qui font faire leurs devoirs par un prof particulier, ou qui écoutent une explication puis s’imaginent qu’ils réussiront l’examen. En réalité, comprendre une explication et réussir seul sont deux capacités totalement différentes.

• Si l’IA ne remplace pas réellement tous les emplois de cols blancs d’ici quelques années, je pense qu’on ne se retrouvera pas seulement avec une bulle boursière, mais aussi avec une pénurie de travailleurs qualifiés. Pour moi, c’est presque le choc de regarder « les meilleurs talents de ma génération se dissiper ainsi ».

• J’ai essayé de trouver une formule représentative utilisable pour le titre de l’article, mais je n’ai rien trouvé de vraiment satisfaisant, donc j’ai fait de mon mieux. Si vous avez une proposition de titre plus précise et plus neutre, vous pouvez la remplacer. Voir aussi les consignes associées.

• Le passage « j’ai compris, mais si je dois l’écrire depuis zéro, je suis totalement bloqué » me parle énormément. Le moment le plus douloureux et le plus difficile, c’était justement de passer du simple suivi d’un tutoriel à la tentative de créer quelque chose de similaire soi-même, puis de se retrouver bloqué. Mais ce processus douloureux a aussi été l’expérience d’apprentissage la plus dense et la plus efficace que j’aie jamais connue. J’ai ensuite appris des choses plus complexes et variées, mais je n’ai jamais retrouvé cette même densité d’apprentissage. Cela ressemblait un peu à cette douleur mentale et ce stress qu’on ressentait en maths au lycée. Je ne pense pas que ce soit une expérience universelle.