Codage par IA
(geohot.github.io)- Les IA pour la programmation ont une structure de rôle similaire à celle des compilateurs traditionnels
- Les prompts en anglais présentent, en tant que langage de programmation, des caractéristiques imprécises et inefficaces
- L’effet d’amélioration de la productivité de l’IA tend en réalité à être exagéré ou mal perçu
- Les outils d’IA transforment le processus de développement, mais la véritable innovation pourrait émerger de meilleurs langages et outils
- L’adoption des LLM ne signifie pas le remplacement des développeurs ; elle reflète plutôt les limites de l’environnement de développement actuel
Similarité entre l’IA et le compilateur
- L’auteur explique qu’en vieillissant, il a renoncé à essayer de convaincre les autres
- Il souligne que beaucoup de gens ne s’intéressent pas à la vérité et ne suivent que les croyances qui leur sont profitables
- Il critique ceux qui affirment que « Perception is reality »
- Il fait remarquer que les milliards de dollars investis dans la conduite autonome constituent un gaspillage dû à des croyances erronées
- L’idée selon laquelle l’IA peut coder s’apparente à la vision selon laquelle un compilateur ferait lui-même le codage
Le codage par IA comme modèle comparable au compilateur
- Il affirme que le meilleur modèle pour l’IA de programmation est le compilateur
- L’utilisateur saisit un prompt (du code), puis reçoit en sortie un résultat compilé
- La différence est que le prompt est saisi en anglais, mais l’anglais présente plusieurs défauts : manque de clarté, absence de spécification, etc.
- Lorsqu’il s’agit de tâches nouvelles ou complexes, la verbosité des prompts finit par augmenter
- La sortie de l’IA est non déterministe, et la modification d’une partie du prompt affecte le résultat dans son ensemble
Regard critique sur le codage par IA
- Si le codage par IA semble positif, c’est à cause de la médiocrité des outils, langages et bibliothèques actuels
- Grâce aux technologies dites « IA », il devient possible d’obtenir de meilleurs outils de recherche, d’optimisation et d’extraction de motifs
- En réalité, celui qui code reste le programmeur lui-même ; seul le langage de l’acte d’écrire du code a changé
- Si une entreprise peut remplacer des développeurs par des LLM, cela signifie que sa base de code et ses critères de recrutement sont à un niveau très faible
- L’IA peut progressivement prendre en charge certaines tâches, à l’image d’un compilateur ou d’un tableur
L’IA est un outil ; à terme, il faut de meilleurs langages et bibliothèques
- Il insiste sur la nécessité de réfléchir avec attention à l’IA dans une perspective instrumentale
- Des milliards de dollars sont gaspillés en raison d’investissements fondés sur de mauvaises attentes ou des illusions
- Il évoque la sur-réaction du marché face à de faux outils de productivité comme le « vibe coding »
- Il existe l’illusion que l’IA augmente réellement la productivité de 20 %, alors qu’une étude (article de recherche) citée conclut en réalité à un ralentissement de 19 %
- Les véritables progrès pourraient venir de l’innovation dans les langages de programmation, les compilateurs et les bibliothèques
1 commentaires
Avis Hacker News
J’ai presque 50 ans et j’écris du code professionnellement depuis la fin des années 90. Je visualise immédiatement les projets dans ma tête et je sais exactement quoi construire. Je suis aussi plutôt bien payé. À première vue, je pourrais sembler être l’archétype de l’anti-IA, mais ce n’est pas le cas. Je peux tout construire, mais je me lasse souvent de toutes les tâches de base. C’est pourquoi j’adore pouvoir utiliser l’IA pour traverser rapidement les parties ennuyeuses et me concentrer sur le travail essentiel que j’aime. Le développement avec l’IA ressemble à donner en quelques phrases une heure de travail à un développeur situé entre junior et intermédiaire. En revanche, le fait que cela puisse empêcher de vrais juniors de progresser et réduire à terme le vivier de seniors est une question qu’il faut prendre très au sérieux, mais c’est un sujet distinct
J’ai dit que j’utilisais l’IA pour expédier les parties ennuyeuses, mais parmi les seniors expérimentés, certains sont au contraire négatifs parce qu’ils redoutent les parties difficiles. Beaucoup de développeurs trouvent une forme de sécurité psychologique dans les sections faciles et routinières, et avec l’arrivée de l’IA, le travail peut devenir une succession ininterrompue de difficultés. Un senior avec beaucoup d’années d’expérience mais peu de compétence réelle s’épuisera vite s’il doit enchaîner les tâches exigeantes. Les entreprises adoptent l’IA en ne pensant qu’à accélérer, tout en oubliant que les humains ont besoin de repos cognitif. S’il ne reste que le travail le plus dur, ce n’est pas bon pour les gens. Bien sûr, les développeurs lassés des tâches répétitives et simples peuvent se régénérer avec l’IA. Au final, il faut une approche différente selon les personnes
Je suis moi aussi un peu plus jeune que vous, mais je pense presque exactement pareil. En fait, c’est peut-être encore plus prononcé chez moi. Je n’ai plus l’impression que le plaisir vient d’écrire le code qui matérialise une idée intéressante, mais du fait d’avoir des idées et de les expérimenter. Donc j’ai codé parce qu’il le fallait, pas parce que c’était intrinsèquement ce que j’avais envie de faire. Si je voulais concrétiser mes idées, je n’avais pas vraiment le choix. L’IA est excellente comme partenaire de brainstorming. Si on lui demande de ne pas flatter, elle signale franchement quand je suis en train de surconcevoir. Elle est aussi vraiment très bonne en débogage. Du coup, j’explique à l’ordinateur en langage naturel l’architecture et les approches possibles, je brainstorme, je rédige une spec, puis je laisse l’IA implémenter. Si mon raisonnement est mauvais, j’itère rapidement avec l’IA. Les itérations sont si rapides que se tromper n’a plus beaucoup d’importance. Avant, je vivais avec de mauvais choix d’architecture parce qu’il fallait refondre tout le code ; avec les outils d’Agentic coding, modifier toute la codebase n’est plus un problème. J’ai aussi pu entrer efficacement dans de nouveaux domaines techniques où je n’étais pas expert, et monter vite en compétence grâce à l’IA. Honnêtement, c’est la période où je suis le plus heureux de toute ma vie de programmeur. Les outils s’améliorent chaque semaine, parfois plusieurs fois dans la même semaine
Cela correspond totalement à mon expérience aussi. J’ai à peu près la même ancienneté. J’utilise activement l’IA à la fois pour mes projets personnels et pour mon travail. D’abord, l’IA joue le rôle d’interlocuteur pour les idées avec moins de biais. Une boucle de feedback rapide et la validation de trajectoire me semblent absolument essentielles. Ensuite, elle me fait gagner du temps et de la frappe. Les « tâches de base » peuvent lui être confiées d’un coup, et elle en exécute au moins 80 % parfaitement. Ce n’est pas 100 % fini, mais le temps économisé est tellement plus important que le bilan est clairement positif. En utilisant l’IA, j’ai aussi pris l’habitude de toujours poser des garde-fous, de donner des consignes aussi précises et détaillées que possible, et de toujours revoir moi-même le résultat
J’ai environ dix ans d’expérience de moins, mais une position similaire. Cela dit, je n’arrive pas vraiment à m’y reconnaître. Dès qu’une partie commence à devenir ennuyeuse, l’automatiser ou la généraliser devient en soi un défi suffisamment difficile pour que je m’ennuie rarement en pratique. Au contraire, taper le code moi-même va souvent plus vite. C’est en écrivant directement les parties ni intermédiaires ni simples que je trouve de meilleures structures ou des idées d’automatisation. Du coup, il y a très peu de code que j’aie envie de déléguer. Et je pense que cette manière de voir vient aussi du fait que je suis resté longtemps dans la même entreprise. Si j’avais dû enchaîner de nouvelles tâches de code en permanence, j’aurais probablement pensé autrement
J’ai aussi la cinquantaine, je code depuis les années 90 et j’ai gagné assez d’argent pour vivre plus de trois vies. En 30 ans de carrière, le trait commun chez les meilleurs développeurs que j’ai rencontrés, c’est la « paresse parfaite ». Ça peut sembler étrange, mais la seule caractéristique vraiment commune chez les excellents ingénieurs, c’était la paresse. C’est fascinant de voir comment la paresse conduit à la productivité. La raison, c’est qu’ils automatisent systématiquement les tâches répétitives. J’ai appris une règle stricte : si on fait deux fois la même chose, il faut absolument l’automatiser à la troisième. Avec l’arrivée de l’IA, le niveau même de l’automatisation a complètement changé. On peut maintenant automatiser toute une série de tâches qui étaient auparavant impossibles à automatiser. J’ai trouvé d’innombrables façons d’utiliser l’IA, et pas seulement moi : mes collègues paresseux l’utilisent aussi extrêmement bien. Aujourd’hui, je n’arrive plus à imaginer le travail sans IA. Pas parce que c’est « magique », mais parce qu’elle prend en charge, à la place de quelqu’un de paresseux comme moi, tout ce qui peut être automatisé
Je pense que c’est un exemple extrême de pensée de groupe autour de l’IA, comme on en voit souvent sur Hacker News. Geohot fait partie des 99,999 % meilleurs développeurs, mais les 99,999 % de développeurs qu’il ne comprend pas continuent à faire des tâches bien plus élémentaires. C’est le paradoxe de l’expert. Si tout le monde était au niveau d’un expert, alors ils ne seraient plus des experts. J’ai vu beaucoup de développeurs se comporter comme une IA. Ils ne savent même pas expliquer la codebase qu’ils ont eux-mêmes produite ni la maintenir de manière cohérente. C’est comme si un ingénieur aérospatial se moquait de quelqu’un qui fabrique des jouets Kinder Surprise parce qu’il ne connaît pas la simulation des fluides
Je suis surpris que vous pensiez que HN est négatif sur l’IA. De mon point de vue, en lisant les commentaires et les articles populaires, HN paraît globalement très optimiste vis-à-vis de la technologie
Le fait qu’une personne ayant fondé une entreprise de conduite autonome adopte cette position me paraît aussi très incohérent. Si les modèles d’IA ne savent pas écrire du code, il est alors légitime de douter qu’ils puissent remplacer une tâche bien plus difficile comme la conduite
Ce point est déjà expliqué au début du billet. L’idée, c’est que beaucoup de workflows de programmation courants sont suffisamment fréquents pour être possibles, mais que dès qu’on veut faire quelque chose de nouveau, il faut l’exprimer avec un niveau de détail comparable à celui du langage lui-même
Je travaille dans l’aérospatial, et les ingénieurs ici ne sont pas spécialement meilleurs non plus. Mais il ne faut pas trop s’inquiéter : en entreprise, ce genre de personnes finit dans des postes où elles ne font aucun dégât, et la plupart deviennent managers
Je ne sais pas si Geohot fait vraiment partie des 99,999 % meilleurs développeurs. « Le modèle optimal pour une IA de programmation, c’est le compilateur. On lui donne un prompt (= du code), il produit du code compilé. Plutôt que de l’utiliser de manière interactive avec du feedback comme dans la plupart des IDE, il vaut mieux faire prompt tuning → recompilation. » Je ne suis pas sûr que ce soit vraiment juste
Un des points centraux de la discussion, c’est qu’il faut définir plus précisément le « type de programmation » dont on parle. De la même manière qu’il ne sert à rien de demander seulement si « les robots, c’est bien ou mal » pour fabriquer quelque chose, il faut d’abord se demander : « appliqué à quoi ? » Sans cela, le débat n’avance pas
Je vois plusieurs problèmes dans ce texte. D’abord, l’affirmation selon laquelle « le codage par IA est un compilateur ». Un compilateur transforme un langage de manière déterministe selon une spécification, tandis que les outils de codage par LLM sont des synthétiseurs de programmes qui recherchent, génèrent et modifient itérativement du code sous contraintes (tests/types/linters/CI, etc.). En pratique, ils résolvent même de bout en bout de gros problèmes open source comme ceux de SWE-bench Verified. Ensuite, l’affirmation selon laquelle « le langage de programmation, c’est l’anglais ». En réalité, on a un assemblage de code, de tests, de specs, d’API, de schémas JSON, de diff, d’outils IDE, etc., et l’anglais ne sert que de colle. L’auteur isole l’interface la plus faible pour la critiquer. Troisièmement, l’idée que la non-déterminisme serait le problème. En réalité, il existe déjà beaucoup d’éléments probabilistes dans le fuzzing, SAT/SMT, etc., mais la détermination finale et la correction viennent de specs externes (tests, système de types, CI, etc.). Et dire que les LLM sont populaires parce que les langages ou les bibliothèques sont mauvais, c’est poser une fausse alternative. Même avec de meilleurs langages comme Rust ou TypeScript, les LLM restent utiles pour la recherche d’API, le traçage dans les dépôts, l’écriture répétitive de code, les migrations, la rédaction de tests, le refactoring, etc. Enfin, comme seule alternative, il propose « faites de meilleurs langages ou compilateurs », alors qu’en pratique les équipes modernes tirent déjà énormément de valeur de la combinaison avec l’IA. Donc, plutôt que de croire aveuglément au codage par IA et aux LLM comme à un « compilateur anglais magique piloté par prompt », il est bien plus réaliste de les utiliser comme un « binôme junior » qui aide selon mes propres contraintes (types, tests, CI, etc.)
(Auteur lui-même) Je suis d’accord avec cet avis. Si j’avais écrit le billet de blog comme cela, il n’aurait probablement pas eu autant de succès. La description des « outils de codage LLM comme synthétiseurs de programmes fondés sur l’exploration » est, à mon sens, très proche en pratique de la définition d’un compilateur. Simplement, si la plupart des compilateurs ne font pas suffisamment d’exploration et s’appuient beaucoup sur des heuristiques, c’est seulement parce qu’ils ne sont pas intégrés à l’exécution. Il est vrai aussi que « de nombreux outils d’ingénierie sont non déterministes » ; mais par exemple, dans un solveur SAT, l’introduction d’aléatoire peut modifier le temps de résolution sans affecter la validité du résultat. Un fuzzer sert par nature au test, donc on n’attend pas de lui la perfection. Je n’ai jamais vu de fuzzer utilisé en production. Je suis tout à fait d’accord avec l’idée que « la détermination vient des tests externes ou des specs ». Mon rêve, ce n’est pas un mode d’implémentation, mais un langage où seul le comportement est spécifié. Quelque chose qui généraliserait davantage la notion de schedule de Halide. L’ordinateur trouverait lui-même la manière d’implémenter. Je pense que l’IA peut fournir ce genre d’outil. Ce n’est pas forcément un LLM, et il faut impérativement des specs strictes. En soi, cela reste de la programmation. Dans cette perspective, je suis opposé à l’idée de voir l’IA comme un « compilateur anglais magique ». En revanche, l’utiliser comme outil d’assistance au travail en connaissant bien ses forces et ses limites, c’est un excellent workflow
Excellente réponse. Je suis entièrement d’accord
Il n’est pas surprenant qu’un texte aussi problématique ait été écrit par George Hotz, alias Geohot
J’utilise souvent Openpilot comme claude code. Je place les deux outils presque au même niveau. Openpilot conduit vraiment très bien pendant des heures sur autoroute et dans d’autres situations simples. claude code, lui, gère sans mon intervention des tâches répétitives comme le refactoring intuitif, le boilerplate, le scaffolding, le git bisect, etc. Mais au final, aucun des deux ne remplace le « conducteur ». claude code, c’est un peu le niveau 2 de la conduite autonome appliqué à la programmation
L’étude METR a connu un succès énorme à cause de son titre. J’imagine que peu de gens l’ont lue attentivement — elle était assez longue. Pourtant, dans les données, une seule personne, celle qui avait le plus d’expérience avec Cursor ou l’usage de l’IA, a observé une hausse de vitesse de 50 %. Cela suggère que les gains deviennent vraiment visibles après familiarisation. De plus, dans un petit échantillon, la variation statistique est forte. Plus tard, il a été corrigé qu’un autre écart de vitesse avait été mal enregistré, ce qui laisse encore des questions sur la signification réelle des résultats. Les inefficacités mesurées dans l’étude sont des choses qui peuvent largement être résolues avec des LLM améliorés, des agents parallèles et d’autres avancées techniques. Au moment de l’étude, on était encore à l’époque de Claude 3.7, avant Claude Code. Et même le simple ressenti d’avoir travaillé 20 % de moins a déjà beaucoup de valeur. Quand on travaille avec plaisir, le temps passe vite
Jusqu’ici, les labs IA ont trop survendu l’IA. On entend sans cesse : « l’IA pense vraiment, ce n’est pas juste du pattern matching ». Moi, en tant que personne qui crée et utilise des outils IA, je trouve au contraire qu’il est bien plus utile de les considérer comme des « prédicteurs du token suivant » fondés sur le pattern matching. Quand on injecte trop d’informations inutiles dans le contexte, l’IA échoue souvent à généraliser. Au fond, cela revient précisément au pattern matching et à la prédiction du token suivant. Je pense que « la technologie IA peut contribuer à produire de très bons outils aujourd’hui », mais cela vient des énormes volumes d’exploration/optimisation et du recyclage de motifs existants. Par exemple, si je demande à Claude code d’écrire une API CRUD simple, il me la sort en une minute et m’économise une heure. Si je demande un algorithme déjà implémenté des centaines de milliers de fois, il produit immédiatement le bon code. L’IA fonctionne vraiment très bien quand on l’utilise dans son domaine d’expertise. En dehors de cela, les résultats sont médiocres
C’est une question de différence de niveau d’intelligence. Pas de connaissance, mais de capacité de raisonnement fondamentale. Nous sous-estimons l’effort cognitif que demandent certaines tâches. Mais il arrive aussi que l’IA montre parfois des comportements plus « réfléchis » qu’on ne l’attendait. À ce moment-là, cela donne vraiment une impression de magie
Les CRUD ou le boilerplate peuvent en fait être partiellement traités par de l’outillage classique. Mais il y a aussi beaucoup de choses possibles uniquement avec l’IA. Par exemple, quand je dois tester et analyser tout un niveau de logs en trace, lire moi-même des centaines de lignes prend énormément de temps ; si je demande à l’IA « exécute le test et trouve la cause », j’obtiens des résultats tout à fait exploitables. Aujourd’hui, c’est souvent devenu ma première étape
Je pense qu’il y a une part de vérité dans votre avis. Mais le monde des affaires est animé par un désir immense de « réorganisation de l’ordre ». Des masses de capitaux veulent des rendements élevés sur une courte période, et les gestionnaires de fonds qui ne suivent pas la tendance sont licenciés. Pareil pour les CIO et les CEO. La course à l’adoption de l’IA ressemble déjà à une course aux armements nucléaires : elle ne peut plus vraiment s’arrêter. Fondamentalement, ce n’est bon pour personne. Mais puisque tout le monde s’y jette, personne ne peut se permettre de rester à l’écart. Avant l’arrivée de la voiture, l’être humain était déjà suffisamment heureux. Mais avec la voiture, les villes ont été réorganisées, les distances entre les bâtiments se sont allongées, et les trajets domicile-travail sont devenus la norme. L’IA va pareillement changer le contexte même dans lequel nous travaillons. Désormais, on s’attend à ce que tout le monde utilise l’IA, et à un certain moment cela finira par sembler « indispensable ». Plus largement, parmi les produits créés par la science et la technologie, il y en a très peu qui aient été de véritables « besoins » humains. La technologie crée les problèmes puis les présente comme des solutions. Le problème n’existait pas à l’origine ; il devient un problème seulement après l’arrivée de la solution. C’est exactement l’un des moteurs fondamentaux du business
Beaucoup de tribunes sur le codage par IA semblent écrites du point de vue de software engineers très expérimentés, une sorte de vision « tour d’ivoire ». (L’étude en question ne portait d’ailleurs que sur « 16 développeurs open source expérimentés ».) Mais pour les non-professionnels, ces outils ont une valeur énorme. J’ai moi-même un peu d’expérience en code, mais ce n’est pas mon métier principal — je suis artiste visuel. Ce qui me prenait autrefois plusieurs jours, je peux maintenant le finir en un après-midi. J’ai quitté mon emploi il y a deux mois pour me consacrer au développement de jeux ; mon budget n’est pas énorme, mais Claude et ChatGPT sont pour moi des abonnements indispensables. Et le fait de pouvoir, à 1 heure du matin dans mon lit, écrire une idée, la lancer aussitôt dans Codex, puis me réveiller le matin et l’essayer, c’est vraiment magique. Avant, j’hésitais à commencer à cause de l’angoisse du « est-ce vraiment la meilleure manière de faire ? », mais maintenant cette inquiétude a disparu parce que le refactoring est facile. L’effet n’est pas seulement utile pour écrire le code lui-même, il abaisse aussi énormément la barrière psychologique. Bien sûr, je comprends que l’essentiel des critiques vise en réalité l’exagération marketing autour de ces outils et le discours du type « maintenant tous les ingénieurs vont se faire virer »
J’ai 72 ans et j’ai travaillé comme développeur pendant 40 ans. Je n’ai plus la même capacité de concentration intense qu’avant, mais grâce à l’IA je continue à construire des choses. Je rédige la spec du projet et les agents se chargent de l’implémentation et même des tests. Désormais, je code uniquement pour le plaisir