- Avec l’arrivée des outils de codage LLM, le postulat fondamental du développement logiciel qui tenait depuis des décennies s’est effondré, et la compétence clé n’est plus l’écriture du code mais la capacité à définir le problème et à concevoir la structure
- Le cœur du développement est en train de se déplacer : ce n’est plus « savoir bien écrire du code », mais la capacité à formuler, c’est-à-dire à imaginer un problème et à l’expliquer clairement
- Une structure de code propre, un README bien organisé et une bonne documentation ne sont plus des signaux fiables de sérieux ou d’expertise ; au contraire, plus c’est trop parfait, plus il y a de chances que ce soit du slop
- À mesure qu’il devient pratiquement impossible de distinguer visuellement le code généré par l’IA de celui écrit par des humains, ce ne sont plus la qualité mais la responsabilité, la provenance et l’humanité qui déterminent la valeur du code
- Les incitations à collaborer et à partager qui soutenaient l’écosystème FOSS s’affaiblissent, et la confiance, la gouvernance et la capacité de curation deviennent des actifs plus importants que le code lui-même
- Ces outils sont de puissants amplificateurs pour les développeurs expérimentés, mais pour les débutants, ils peuvent devenir un génie dangereux susceptible de leur enlever l’occasion de construire une compréhension de base
Introduction : l’adage de Linus Torvalds et son renversement
"Talk is cheap. Show me the code"
- En 2000, cette phrase de Linus Torvalds symbolisait l’idée que les paroles n’ont pas de valeur tant qu’elles ne sont pas prouvées par du code réel
- À l’époque, même avec un plan de développement très clair, implémenter un programme complexe demandait en soi un effort immense, du temps et une répétition fastidieuse
- Le véritable goulot d’étranglement n’était pas la technologie mais les limites humaines : la bande passante cognitive, le temps et l’énergie individuels, ainsi que le coût biologique de devoir garder en tête l’ensemble d’un grand système tout en écrivant le code ligne par ligne
- En conséquence, la plupart des idées finissaient empilées dans une wishlist de “ce que j’aimerais essayer un jour”, puis disparaissaient sans même être tentées
25 ans plus tard : les LLM renversent tout
- En 2025, Linus Torvalds a fusionné du code généré par IA dans son projet hobby, en déclarant : « Est-ce meilleur que ce que j’aurais écrit moi-même à la main ? Bien sûr. »
- Du point de vue d’un auteur de logiciels depuis des décennies, l’auteur affirme sans détour que le développement logiciel tel que nous le connaissions est déjà terminé
- En tant que génération ayant vécu directement les nombreuses transitions, du dial-up au gigabit, de Basic à Node.js, de SourceForge à GitHub, il reconnaît clairement que ce changement n’est pas une mode passagère mais une rupture qualitative
Effondrement des critères d’évaluation de la qualité du code
- Autrefois, pour évaluer un projet FOSS, l’ancienneté du projet, la fréquence des commits, la cohérence de la structure du code, la qualité du README et de la documentation servaient de critères importants
- Des commentaires concis et une documentation bien organisée étaient perçus comme des signaux de réflexion et d’attention portée aux autres développeurs
- Mais depuis que les LLM peuvent générer d’un coup des pages de documentation abouties, des README excessivement détaillés, des interfaces propres, des patterns ordonnés et des commentaires, ces signaux ne fonctionnent plus
- Il devient donc difficile de distinguer, à l’apparence seule, si un dépôt a été fabriqué en vibe coding par un non-technicien ou s’il s’agit du résultat conçu par un développeur expérimenté
- Paradoxalement, plus quelque chose paraît trop parfait, plus il faut soupçonner qu’il s’agit d’une génération one-shot à faible effort
- Sans examen et analyse de niveau expert, il devient de plus en plus difficile de distinguer le bon grain du slop
- En conséquence, plus encore que le code lui-même, qui l’a produit, pourquoi, avec quel historique, et s’il existe une gouvernance et un plan de maintenance deviennent des éléments de jugement centraux : autrement dit, la provenance
L’évolution de la valeur de l’effort
- Autrefois, un développeur expérimenté devait passer par un long processus de concentration et d’amélioration répétée pour produire 10 000 lignes de code de qualité donnant un résultat significatif
- Le nombre de lignes n’est pas en soi une mesure de qualité, mais 10 000 lignes bien raffinées impliquaient du temps, de la concentration, de la patience, de l’expertise et un certain niveau de gestion de projet
- Les LLM peuvent désormais générer ce type de résultat en quelques secondes à peine, en couvrant l’ensemble du workflow technique, des tests à la configuration système et au déploiement
- Lorsque l’expertise et le jugement humains interviennent avec eux, le résultat peut atteindre une qualité suffisamment élevée pour un usage réel
- L’auteur a lui-même vécu à plusieurs reprises l’expérience de terminer en quelques jours, parfois en quelques heures, un travail qui aurait autrefois pris des semaines ou des mois
- Cela a été possible avec un simple agent CLI basé sur un LLM, sans AGENT.md ni orchestration complexe multi-agents
- Le coût physiologique, cognitif et émotionnel autrefois payé pour obtenir un résultat logiciel a diminué de plusieurs ordres de grandeur
- Le temps et l’espace mental ainsi libérés sont réinvestis dans la réflexion d’ingénierie, la conception d’architecture, la discussion, l’expérimentation et l’expansion de l’imagination
- L’ancienne formule « programmer, c’est 90 % de réflexion et 10 % de frappe » n’est plus une métaphore mais une réalité
Définition du slop et valeur du code
- Quand même quelqu’un n’ayant jamais écrit une ligne de code peut produire du code à l’échelle industrielle en quelques secondes, quelle est encore la valeur du code comme livrable en soi ?
- Dire « je ne veux que du code purement humain, pas du code IA » relève, si l’on considère la réalité, presque de la blague ironique
- Les grands incidents causés par du code écrit par des humains existent déjà en abondance : panne IT de CrowdStrike (2024), immobilisation du Boeing 737 MAX, scandale de la Poste britannique, fuite massive de données en Inde, fuite de données Equifax, etc.
- Une part considérable du code écrit chaque jour par des humains dans le monde est déjà, du point de vue de la qualité, dans une zone limite
- Le développement logiciel reste un domaine qu’il est difficile de considérer comme une discipline professionnelle objectivement arrivée à maturité
- Là où les médecins ou les ingénieurs civils doivent suivre une formation stricte, obtenir une licence et répondre de leurs résultats, il n’existe presque rien d’équivalent en développement logiciel
- La société actuelle fonctionne sur des systèmes logiciels conçus de façon lâche, bricolés à la va-vite et excessivement gonflés
- Si l’on veut forcer le trait, on pourrait même dire que le slop produit par l’IA a au moins souvent une forme propre, une documentation bien rangée et une cohérence syntaxique
- Lire les phrases et messages sans âme générés par des LLM qui remplissent Internet est de plus en plus perçu, au sens littéral, comme un gaspillage de l’activation des neurones de l’amygdale
- Dès que disparaît le processus créatif humain, avec sa perfection comme ses défauts, langage, littérature, art et musique deviennent fondamentalement impossibles à apprécier
- Ce qui peut être généré sans effort, à l’infini et instantanément devient extrêmement difficile à évaluer en termes de valeur pour les humains
Le code n’est pas de l’art
- Le code a toujours été, par essence, un moyen au service d’une fin, jamais une fin en soi
- L’utilisateur final ne lit pas le code, n’a pas besoin de le lire et ne s’y intéresse pas
- Pour l’utilisateur, il est sans importance de savoir dans quel langage, framework ou type d’architecture sont implémentés les centaines de systèmes qui tournent derrière un portail
- Le code est une présence entièrement cachée ; l’utilisateur ne fait l’expérience que des résultats et des effets qu’il produit via l’UX
- Le critère qui permet de décider si un code IA fonctionnellement identique est du slop ou non, c’est la structure de responsabilité (accountability) et le degré d’intervention humaine
- Une PR écrite et soumise directement par une personne dans un dépôt open source reçoit naturellement, indépendamment de la qualité du code, une forme d’empathie et de valeur fondée sur le temps et l’effort humains qu’elle suppose
- À l’inverse, une PR générée par un LLM suscite souvent comme première réaction « slop ! », quelle que soit sa qualité, parce qu’on ne peut pas immédiatement estimer l’effort humain qu’elle contient
- En même temps, la charge de lire et de vérifier ce code devient disproportionnée, et croît de manière exponentielle par rapport à son coût de production
- Au fond, ce n’est qu’une variation parmi une infinité d’autres, générée sans effort, sans provenance ni contexte significatifs
- À ce stade, notre réalité ressemble de plus en plus à la “Bibliothèque de Babel” décrite par Borges
L’avenir du FOSS
- Le FOSS est probablement l’un des plus grands biens publics jamais créés par l’humanité
- Au départ du FOSS, il y avait l’idée d’une époque où le logiciel était extrêmement coûteux et ne pouvait être produit que par une petite minorité d’experts
- À l’échelle mondiale, très peu de personnes pouvaient créer du logiciel, et tous les autres devaient se contenter d’en utiliser les résultats
- Désormais, même pour des besoins très de niche, un expert peut créer rapidement une petite bibliothèque exactement adaptée à son propre besoin
- Mieux encore, toute personne un minimum débrouillarde peut aujourd’hui fabriquer elle-même, en vibe coding, les petits outils dont elle a besoin pour un usage personnel
- Ce qui s’est produit sur StackOverflow est en train de se reproduire, plus lentement mais de façon similaire dans l’ensemble du logiciel
- Cela semble ébranler frontalement les motivations humaines, les conditions sociales et les incitations à participer qui soutenaient la collaboration et le partage dans le FOSS
- Si l’on considère l’explosion cambrienne de projets FOSS qui va déferler à une échelle sans précédent
- Alors, dans les projets FOSS de haute qualité qui survivront et prospéreront, la gouvernance experte, la curation et les structures de confiance pourraient devenir des actifs plus importants que le code lui-même
Les deux extrêmes qui voient l’arbre mais pas la forêt
- Même à l’époque où il n’existait ni coloration syntaxique, ni IDE, ni tous les outils d’aujourd’hui, les humains ont déjà créé des logiciels d’un niveau remarquable
- À l’inverse, même aujourd’hui, alors que les outils et les ressources débordent, on continue à produire des logiciels médiocres
- Un bon développeur expressif et soucieux de la qualité saura utiliser les LLM ou n’importe quel autre outil à sa manière pour produire de bons résultats
- À l’inverse, un développeur incapable d’expliquer le problème et indifférent à la qualité produira de mauvais résultats, qu’il utilise un LLM ou non
- Les croyants extrêmes du vibe coding « agentique » comme ceux qui rejettent totalement les LLM restent finalement fixés sur les arbres sans voir la forêt
- Il existe clairement un point d’équilibre pragmatique, où une personne dotée d’expérience, d’expertise, de capacité de réflexion et d’expression choisit les bons trade-offs pour obtenir le résultat voulu
- Le vibe coding peut aussi être un point d’entrée important pour les non-techniciens, leur permettant pour la première fois de toucher au logiciel, d’expérimenter, de s’amuser et de développer leurs compétences
- Mais ceux qui idéalisent le vibe coding manquent un élément essentiel de ce qui pousse les humains à prendre un livrable au sérieux : la finitude
- Ils finissent ainsi par construire eux-mêmes une immense bibliothèque borgésienne, où il est facile de se perdre dans une mer de slop produite par des agents flatteurs
- Des livrables générés à l’infini sans effort et sans provenance significative sont extrêmement difficiles à valoriser comme à prendre au sérieux
- Les humains sont, par nature, très mauvais pour faire face à une offre infinie, surtout à une infinité de choix
- De leur côté, les sceptiques des LLM ne dépassent souvent pas l’argument d’incrédulité
- Ils rejettent la technologie elle-même parce qu’elle ne leur plaît pas personnellement, parce qu’ils n’obtiennent pas les résultats voulus, parce qu’elle a déçu leurs attentes ou simplement parce qu’ils en sont lassés
- Mais cet argument perd de sa force face au fait qu’il existe un grand nombre de personnes qui utilisent efficacement les mêmes outils et vivent l’expérience exactement inverse
- Les implémentations stupides et nuisibles poussées par le battage médiatique, la frénésie et la cupidité sont évidemment bien réelles et constituent un sujet d’inquiétude majeur
- La bulle business de l’IA pourrait bien être l’une des plus grandes bulles de l’histoire
- Malgré cela, la diffusion des technologies d’IA FOSS reste un signal clairement porteur d’espoir
- Assimiler les mauvais acteurs, le jeu des chiffres ou les implémentations absurdes aux capacités fondamentales et physiques de cette technologie est irrationnel
Le coût humain
- Du point de vue des développeurs et ingénieurs expérimentés, ces technologies d’IA fonctionnent comme des outils d’assistance extrêmement puissants et efficaces
- Mais pour les apprenants en début de parcours et les juniors qui entrent tout juste dans le secteur, le problème est tout autre
- Si les bases manquent et qu’il ne s’est pas encore formé une compréhension intrinsèque et subtile des systèmes et du processus de développement logiciel, cette technologie ressemble davantage à un génie peu fiable et dangereux
- Demander du code et en recevoir, puis demander une modification et l’obtenir immédiatement, cela semble pratique en apparence
- Mais l’utilisateur se retrouve vite enfermé dans une base de code dont il ne comprend pas le fonctionnement, dépendant sans cesse du génie pour résoudre les problèmes
- Si cette dépendance se répète, l’environnement même dans lequel des compétences fondamentales peuvent se former naturellement disparaît, avec un risque réel de régression cognitive
- On peut alors voir apparaître toute une génération de juniors qui n’auront jamais l’occasion de devenir des seniors réellement solides
- La véritable inquiétude est que la génération des apprenants perde l’occasion d’acquérir l’expertise nécessaire pour distinguer objectivement ce qui est du slop et ce qui ne l’est pas
- Plus grave encore : même les praticiens expérimentés qui savent très bien exploiter ces outils pourraient perdre la motivation de mentorat et de formation de base des juniors
- Le risque dépasse le seul développement logiciel : il ouvre la voie à un monde où les humains délèguent entièrement leur agentivité et leur prise de décision à des boîtes noires
Conclusion : désormais, la parole vaut plus que le code
- Même pour les développeurs qui ont toujours développé à la main, la capacité à lire le code et à l’évaluer de façon critique devient plus importante que celle qui consiste à maîtriser la syntaxe et taper ligne par ligne
- Bien sûr, cette dernière reste une compétence importante, et savoir lire le code efficacement repose en fin de compte sur ce socle
- Malgré cela, le workflow quotidien du développement logiciel a déjà été totalement renversé
- Le développeur expérimenté qui sait bien parler, c’est-à-dire imaginer, expliquer, définir un problème, concevoir une architecture et faire de l’ingénierie, bénéficie désormais d’un avantage disproportionné comme jamais auparavant sur celui qui ne le peut pas
- La connaissance d’un langage, d’une syntaxe ou d’un framework particulier n’est plus le principal goulot d’étranglement
- Les contraintes physiologiques et physiques qui retenaient autrefois les développeurs ne constituent plus des obstacles décisifs
- Les machines capables de produire immédiatement de grandes quantités de code sont désormais des outils commoditisés, accessibles à tous au niveau d’un
pip install - Il n’est plus vraiment nécessaire de suivre une formation spécialisée ni d’apprendre un nouveau langage ou framework
- Ce qu’il faut, c’est seulement l’ancienne pensée critique, des capacités humaines fondamentales et un minimum de compétence opérationnelle pour piloter cette machine
- En conséquence, les méthodologies historiques du développement logiciel et la répartition des rôles — Waterfall et Agile, développeur et testeur, senior et junior — subissent des transformations fondamentales
- Les frontières traditionnelles sont en train de se fondre dans des boucles itératives “agentiques” incroyablement rapides, compressées et floues
- Par ricochet, les dynamiques entre les personnes, les organisations et les communautés publiques autour du développement logiciel, ainsi que les incitations humaines qui soutenaient le partage et la collaboration, évoluent elles aussi rapidement
- La fin du bug bounty de curl, l’introduction par Zulip de directives sur l’usage de l’IA, ou encore la politique explicite de Ghostty sur l’IA en sont des exemples
- Pour la première fois dans l’histoire, une bonne parole (talk) devient un facteur d’une valeur exponentiellement supérieure à un bon code
- Les répercussions de ce changement seront majeures, et en même temps profondément destructrices
10 commentaires
Je ressens aussi profondément cette idée de « la disparition de l’environnement d’apprentissage lui-même ». Dans un monde où le coût d’accès au savoir est proche de zéro, quelle forme l’éducation prend-elle désormais ?
« Même quelqu’un qui n’a jamais écrit une seule ligne de code peut désormais produire en quelques secondes du code à l’échelle industrielle »
-> Si on construit un immeuble avec des bâtonnets, ça compte comme de l’échelle industrielle ?
Dans la réalité, la plupart des recrutements exigent toujours au minimum N années d’expérience dans des langages comme Java.
La « parole » et l’« écrit » sont deux choses différentes.
En réalité, il semble plus important de bien écrire que de bien parler.
🐎🐎🐎🐎🐎
Kimi no Aiba fait zkyun dokyun~
J’aimais bien cette phrase de Torvalds... l’époque a complètement changé.
Il y a seulement quelques années encore, quand on allait voir des collègues de boîte ou qu’on participait à des meetups de développeurs, on rabaissait comme des « parlogrammeurs » ces ingénieurs qui n’avaient pas vraiment de compétences mais parlaient beaucoup (obsession moutonnière d’early adopter pour les dernières tendances et mots-clés tech, au mieux juste de l’expérience d’usage de frameworks et de bibliothèques, sans avoir jamais construit eux-mêmes ne serait-ce que les bases…). Aujourd’hui, les « parlogrammeurs » sont devenus la réalité du métier de développeur. Ah, quelle époque.
Avis Hacker News
Aujourd’hui, j’ai demandé à Codex d’écrire des tests unitaires pour Redux
Au début, ça avait l’air correct, donc je suis passé à autre chose, mais plus tard, quand j’ai voulu ajouter moi-même des tests, en relisant je suis tombé sur des dizaines de passages qui faisaient dire « c’est quoi ça ? »
Ça s’exécutait, mais c’était du grand n’importe quoi. Et pourtant le code était simple
J’ai ce genre d’expérience presque à chaque fois que j’utilise l’IA — en apparence ça semble correct, mais dès qu’on essaie d’étendre, ça vire à la catastrophe, et au final c’est moi qui dois tout remettre en ordre
Le problème avec l’idée que « le code ne coûte rien », c’est que la génération ne coûte pas cher, mais la maintenance coûte cher
Générer des milliers de lignes par jour, c’est comme accumuler de la dette avec une carte de crédit. On croit que c’est gratuit, puis la facture arrive plus tard
Je ne sais pas si nous pouvons agir directement dessus, mais j’aimerais voir ce qui s’est passé
Pour référence, l’approche de test de Redux est décrite dans la documentation officielle
Il faut d’abord clarifier la méthodologie de test, puis formuler la demande au modèle à partir de là
Il faut faire attention, parce que l’IA suppose arbitrairement tout ce qui n’est pas explicité
Fondamentalement, ce qui compte, ce sont les tests. Il ne faut pas juger du code IA à l’intuition, mais le vérifier par des tests
La valeur du code est proportionnelle au niveau des tests. Valider ça à la va-vite façon « LGTM », c’est comme conduire une moto les yeux fermés
Dans certains cas ça marche bien, dans d’autres c’est un désastre total
Par exemple, je lui ai donné un cas d’usage correct, mais le code était faux, et quand le test a échoué, l’IA a réécrit le test
En d’autres termes, il y a le risque qu’elle définisse elle-même ses propres critères de réussite
J’avais essayé autrefois de lancer deux instances de Claude, une pour les tests et une pour l’implémentation, mais la configuration était beaucoup trop pénible
C’est pour ça que je pense que cette technologie est imposée aux équipes
Comme pour la migration vers le cloud, le vrai coût n’apparaît que plus tard. Sauf que cette fois, ce sera probablement bien plus rapide
Pour reprendre l’analogie avec l’assemblage automobile,
quelqu’un qui se contente d’assembler des pièces selon des spécifications a de bonnes raisons de craindre d’être remplacé par un bras robotisé
En revanche, quelqu’un qui expérimente des conceptions, fabrique des prototypes et programme les bras robotisés se soucie moins de l’automatisation
Beaucoup de contre-arguments reviennent à dire que « l’IA automatisera aussi ce second rôle », mais en pratique j’ai l’impression qu’on prend souvent le premier travail pour le second
Parce qu’il peut déboguer, changer de direction et donner des consignes précises
L’utilisateur lambda, lui, se contente de répéter « ça ne marche pas, corrigez-le »
Donc la nature du travail va changer, mais le métier lui-même ne va pas disparaître
Si l’IA peut imiter ça, elle peut me remplacer
Dans une économie peu concurrentielle, une « imitation plausible » peut suffire
Même un résultat d’IA lamentable leur suffit, tant que ça garantit les revenus et l’exit
Le monde a toujours toléré les « déchets distribués ». Regardez Windows
En réalité, une bonne part était automatisable, et mon ego l’avait sans doute surestimée jusqu’ici
Mais les LLM d’aujourd’hui sont bien plus généraux, au point de pouvoir prendre en charge certaines classes de travail
Si on disait à un bras robotisé « améliore le design des voitures de cette année », il s’arrêterait net, mais une IA peut formuler un avis
Si une IA peut exécuter l’ensemble du processus, de l’idée → la conception → la fabrication → le test → l’évaluation,
alors c’est une innovation fondamentalement différente des technologies du passé
Dire que « l’époque où l’on écrivait le code à la main est terminée » est exagéré
Ce genre d’exagération sert à ébranler l’expertise des gens et à déclencher leur FOMO
Il ne faut pas se laisser intimider et il faut faire confiance à son propre jugement
En revanche, il est vrai que la technologie change les manières de pratiquer
Au final, l’important reste la capacité à équilibrer performance, coût, calendrier et qualité
Il y a toujours beaucoup de résistance à l’idée que « l’ingénierie est finie »,
mais à mon sens, dans les produits à grande échelle, l’écriture du code ne représente que 10 à 20 % du total
Le reste, c’est la conception, l’expérimentation, l’analyse, la communication, etc., et les LLM ont du mal à remplacer cela
Au contraire, la collaboration et la coordination deviennent encore plus complexes, et les LLM aggravent souvent ce problème
C’est pourquoi il vaut mieux voir l’IA comme un outil plutôt qu’un substitut
Eux disent que « des décennies de manière de développer sont terminées », pas que l’ingénierie est terminée
Si l’écriture du code représente 10 à 20 %, cela signifie que le reste de la « conversation » est devenu encore plus important
Comme le dit Linus, « il faut montrer que le code fait bien ce qui est prévu »
Écrire quelques lignes avec un LLM est facile, mais les modifier en toute sécurité reste difficile
Il paraît que Liz Fong-Jones de Honeycomb a elle aussi déjà fait ce type d’erreur
Les entreprises vont se réveiller à la réalité à mesure qu’elles suivront le ROI des LLM
Pour l’instant, on est au sommet du hype cycle de Gartner, et on va sans doute bientôt descendre dans le creux de la désillusion
Grâce à Claude, je refactorais rapidement, puis à un moment tout s’est complètement bloqué
La raison, c’est que je ne savais pas ce que je voulais
Quand le modèle de données n’est pas clair et qu’on dit « continue à écrire », on obtient un très mauvais résultat
programmer est une activité de court terme, tandis que l’ingénierie logicielle est un processus de long terme
L’IA accélère la première, mais ne remplace pas la seconde
Le présupposé d’un « plan de développement clair et d’un savoir-faire d’implémentation » n’est pas réaliste
Programmer est en soi un acte de planification, et le langage est un excellent outil de pensée
C’est pour cela que les visions des LLM divergent — entre ceux qui voient le langage comme un outil de pensée, et ceux qui n’y voient qu’un outil d’exécution
Les premiers reconnaissent la valeur de la programmation en elle-même, les seconds cherchent à masquer le code
En fin de compte, c’est un choix : construire dès le départ un bon modèle conceptuel, ou finir plus tard dans l’enfer du débogage
Les outils actuels ne sont pas pensés pour le premier cas. Il y a un énorme fossé dans l’outillage
Certains combinent les deux pour inventer de nouvelles façons de travailler
Le sens d’origine de « Talk is cheap », c’est que « parler est facile et ne vaut rien »
Mais « Code is cheap. Show me the talk. » suggère quelque chose d’encore moins précieux, ce qui m’a paru désagréable dès le départ
Et en lisant l’article, j’ai constaté que mon intuition était juste
L’auteur n’est pas ignorant en matière de code. Il est aussi très actif dans l’open source
L’idée est simple — autrefois, implémenter en code une bonne conception coûtait cher,
mais maintenant que c’est devenu moins coûteux, la qualité de la conception compte encore plus
« Talk is cheap, show me the code »
Le plus important n’est pas le code, mais le modèle mental du développeur
Le code n’est qu’un sous-produit de ce modèle, et sans interprétation humaine il n’a pas de sens
Cette façon de voir influence aussi fortement l’usage des LLM
J’ai du mal à être d’accord avec l’idée que « la manière de faire des dernières décennies est terminée »
Les façons de développer en 2005, 2015 et 2025 sont toutes différentes
Il y a toujours eu du changement, et le présupposé selon lequel « tout est resté identique pendant des décennies » est faux
Les outils ont progressé, mais la manière de travailler des développeurs reste assez similaire
le neovim d’aujourd’hui est bien plus puissant qu’à l’époque
Il y a une tendance à sous-estimer les progrès progressifs des 30 dernières années
À l’époque, la plupart des informations s’obtenaient dans des livres papier ou par rétro-ingénierie
La formule « Talk is even cheaper, still show me the code » me parle davantage
L’IA promet une productivité multipliée par 10, mais je vois rarement des résultats de cet ordre
Grâce à l’IA, la complexité est devenue plus supportable, mais écrire une application React reste une souffrance
Gérer des API non déterministes reste aussi pénible
Cela dit, passer moins de temps sur les fautes de frappe ou la recherche d’exemples est un vrai avantage
Mais à cause du manque de raisonnement et des limites de connaissance, coder reste toujours aussi fastidieux
puis le convertit en caractères ANSI pour le réécrire dans le terminal —
autrement dit, il implémente de façon compliquée quelque chose qu’on pourrait faire simplement avec curses
Des formules comme « Code is cheap. Show me the talk. » sont désormais trop souvent utilisées comme appâts à clics
Le texte lui-même n’est pas mauvais, mais il n’a rien de nouveau
Surfer sur la vague de l’IA n’est pas réservé aux entreprises, les blogueurs et les influenceurs font pareil
Il suffit de coller un titre sensationnaliste à un article pro- ou anti-IA pour devenir tendance sur HN ou Reddit
Pour référence, cette formule vient à l’origine de ce tweet et de
cette page de mèmes
Enfin quelqu’un a bien exprimé la zone intermédiaire réaliste entre les extrêmes
Les LLM ne sont ni des dieux ni des catastrophes. Ce sont des outils
On peut critiquer l’extraction de rente de sociétés comme OpenAI, Google ou Microsoft,
tout en exploitant des modèles locaux comme Qwen ou Mistral
Les LLM cloud ne permettent pas l’E2EE pour des raisons de sécurité, donc ils sont inadaptés aux environnements d’entreprise
Mais grâce aux LLM locaux, il est désormais possible, même seul, de réaliser un travail de niveau entreprise
Avec un simple Mac Mini, on peut gérer les requêtes de base de données, l’intégration d’API et l’automatisation
En dehors des très grandes organisations, un senior généraliste peut remplacer trois profils intermédiaires
Bien sûr, j’ai toujours beaucoup de réserves sur la destruction d’emplois ou les questions de droits d’auteur,
mais les LLM locaux ont désormais trouvé leur place dans mon toolkit essentiel
C’est un texte que j’aimerais montrer à ceux qui sont dans une sorte de « foi ».