- La croyance selon laquelle les outils de codage par IA augmentent réellement la productivité des développeurs est une illusion
- Ces outils nuisent au plaisir de programmer et à la profondeur de compréhension humaine
- L’IA peut être utile pour la génération de code répétitive, mais elle reste faible sur le contexte, les performances et les nuances
- Une dépendance excessive affaiblit la volonté d’apprendre et d’explorer des développeurs, ainsi que la qualité du code
- Le problème de la disparition progressive de la nature même du métier de programmeur sous l’effet de la commodité apportée par l’IA devient plus grave
Introduction : le délire autour des outils de codage par IA
- Cet article traite de la réalité des outils de génération de code par IA à la date de mai 2025
- Le débat sur l’incompétence de l’IA pourrait s’atténuer avec le temps, mais le problème de l’atteinte à l’essence du développement et au plaisir de programmer devrait au contraire s’aggraver
Chapitre 1 : Mon collègue, le programmeur
- L’auteur prend comme exemple l’expérience de travailler avec des développeurs non professionnels qui copient-collent du code de manière irresponsable, et souligne les problèmes qu’ils laissent derrière eux : dégradation des performances, bombes à bugs, mépris de l’architecture
- Ce type de collègue modifie continuellement le code sans tests, profilage ni compréhension du contexte, finissant par miner la motivation et l’envie d’apprendre de toute l’équipe
- Avec le retournement « Captain Obvious », l’auteur révèle qu’il s’agit en réalité d’une satire visant les outils de codage par IA comme GitHub Copilot, Claude Codex, etc.
- Un véritable copilote d’avion comprend l’ensemble du système, coopère et assume ses responsabilités. À l’inverse, les Copilot IA ne laissent qu’un code superficiel, sans compréhension fondamentale
- En empruntant simplement le nom « Copilot », ils sont imposés dans tous les IDE des développeurs sous le vernis de la productivité et de l’innovation
Chapitre 2 : Les avantages de Copilot
- Les outils de codage par IA ne sont pas totalement inutiles
- Ils sont utiles lorsqu’un débutant veut simplement apprendre une syntaxe complexe d’un langage comme le C++, ou consulter rapidement un concept
- Pour le brainstorming, l’organisation du contexte ou le code template répétitif, ils vont plus vite qu’un stagiaire humain et commettent moins d’erreurs
- Leur absence totale de réflexion sur les performances et l’efficacité, ainsi que le risque de catastrophe de qualité de production en l’absence de supervision, restent évidents
- Ils peuvent fournir rapidement un scaffold ou un brouillon de code sans contexte, mais la conception complète et le tuning restent du ressort des développeurs humains
Chapitre 3 : Moi, développeur, face à l’IA
- L’auteur accorde une grande importance au plaisir même de coder et au sentiment d’accomplissement que procure le fait de construire soi-même
- Si l’on confie à l’IA le code répétitif (boilerplate) et que l’on renonce même à implémenter soi-même bibliothèques et macros, on finit par perdre la créativité et la motivation intrinsèque du développeur
- Le phénomène qui consiste, par FOMO (peur d’être dépassé), à s’appuyer sur Copilot pour produire rapidement un flot de code grossier et non vérifié en est une conséquence
- La dépendance à l’IA fait disparaître les occasions de véritable apprentissage, de compréhension des performances bas niveau et des structures, ainsi que de gestion de la qualité du code
- Le nom « Copilot » évoque non pas un collègue d’égal à égal, mais une illusion comparable à celle d’un gamer peu expérimenté qui prétendrait piloter un avion
Chapitre 4 : L’ordinateur est une machine
- La capacité à comprendre la réalité et la structure de la machine (le matériel), ainsi que ses caractéristiques de performance n’appartient qu’aux humains
- L’IA n’a aucune intuition ni expérience directe des cache misses, du layout mémoire, du profiling ou des goulets d’étranglement de performance
- Les réponses fournies par l’IA sont déconnectées du contexte et deviennent inutiles dans les domaines qui exigent une optimisation concrète
- Même pour développer une application CRUD ordinaire, les développeurs doivent faire preuve de respect et de sérieux envers les utilisateurs et le système
- L’expertise et l’artisanat professionnel se forgent par l’expérience directe, la difficulté et l’amélioration répétée
Chapitre 5 : Conclusion
- Les outils de codage par IA et leur accessibilité entraînent la disparition de l’esprit hacker
- L’auteur s’inquiète de voir l’industrie ne plus conserver que des utilisateurs passifs, sans véritable intérêt pour le code, la structure ou les performances
- Autrefois, les nuits passées sur IRC, les expérimentations matérielles et l’exploration bas niveau étaient pleines de curiosité pure et de créativité
- Désormais, il ne resterait plus qu’un travail mécanique consistant à répéter la « revue de patchs IA », accompagné d’indifférence
- L’auteur met en garde contre le risque que la génération de code dépourvue de compréhension du contexte et de compétence réelle devienne le standard du secteur, au détriment des personnes réellement compétentes
Historique des modifications du texte
- Ajout d’un avertissement concernant la date de rédaction
- Clarification, en tenant compte des avis sur HN, de la portée de la critique sur les performances (systèmes complexes vs CRUD)
- Ajustement partiel du style des phrases et de l’usage des symboles pour améliorer la lisibilité
25 commentaires
Le texte est amusant, mais je commence à ressentir une certaine fatigue, parce que trop d’articles semblent pouvoir se résumer à : « ne pas utiliser l’IA n’est pas la solution à tout, mais lui faire une confiance aveugle et s’y soumettre n’est pas non plus souhaitable ».
Les LLM et l’IA progressent avec le temps. Il y a encore seulement quelques mois, il était presque impossible d’espérer une vraie cohérence du code à partir de ce qu’on leur demandait, mais désormais, si l’on téléverse dans l’espace concerné les fichiers du code initial demandé à l’IA et qu’on lui donne comme consigne de toujours respecter le style du code existant lorsqu’elle écrit du nouveau code, elle produit un code assez cohérent.
> Vu les anciens posts de l’auteur, on dirait qu’il est développeur de jeux.
> Comme les connaissances et ressources en développement de jeux ne peuvent pas être apprises en masse par les LLM, contrairement aux cas d’applications CRUD, j’ai l’impression que l’auteur du texte perçoit mieux les limites des LLM.
Je l’ai lu en entier, et au final je pense que c’est précisément pour cette raison que l’auteur a un point de vue un peu biaisé.
Bien sûr, ce que dit le texte est globalement juste, dans le sens où c’est presque un discours de manuel.
Mais je pense que l’IA est déjà suffisamment performante sur le CRUD et le front-end, où elle dispose de beaucoup de données d’entraînement.
Il faut sans doute l’exploiter au mieux dans son propre domaine.
J’ai l’impression qu’il n’y a pas un léger malentendu sur le sens voulu par l’auteur.
L’auteur met l’accent sur les performances, la stabilité et une architecture facile à maintenir, ainsi que sur la cohérence du code, pour les projets qu’il gère lui-même, et justement l’architecture et la cohérence du code font partie des domaines où les LLM actuels sont vraiment mauvais.
Le web, en particulier, est un domaine où beaucoup de gens se mettent au développement et où la mentalité du « tant que ça tourne, ça va » est très forte, si bien qu’une énorme quantité de code de faible qualité est déployée. Comme les LLM ont été entraînés sur cette base, la qualité de leurs sorties en devient absurdement basse.
Demandez simplement à GPT : « c’est pour l’intégrer dans un front web, peux-tu implémenter un algorithme de tri rapide en JS ? » Si vous ne voyez pas de problème dans le résultat produit, je pense que cette discussion n’aura pas beaucoup de sens.
Bonjour. Par curiosité, j’ai essayé de lui dire : « Je vais l’intégrer dans un front web, peux-tu m’implémenter rapidement l’algorithme de tri rapide en js ? » Mais, de mon point de vue, il m’est difficile de bien voir où est le problème. Si vous pouviez me l’expliquer, cela m’aiderait énormément. Merci d’avance. https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd
On dirait que le lien ne fonctionne pas correctement, donc je réessaie. https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e
La deuxième implémentation de
quickSortInPlace()que vous avez jointe est elle aussi une implémentation lente.Exécutez le code ci-dessous.
function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;
const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}
function partition(arr, left, right) {
const pivot = arr[right];
let i = left;
for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}
[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}
function quickSort(arr) {
if (arr.length <= 1) return arr;
const pivot = arr[arr.length - 1];
const left = [];
const right = [];
for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}
return [...quickSort(left), pivot, ...quickSort(right)];
}
const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));
let sorted: Array<number>;
const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();
const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();
console.log(
q: ${qe - qb} ::: rq: ${rqe - rqb});Fondamentalement, on peut considérer qu’il s’agit d’un code qui ne prend absolument pas en compte la charge liée à la création, à l’exploitation et à la fusion des collections. Dans le cas du C++, des propositions et implémentations concernant le Move Constructor existaient déjà il y a une dizaine d’années, et le fait d’être constamment très attentif au coût des copies mémoire est vraiment une base élémentaire. Le quick sort est, par son mécanisme même, un algorithme qui permet de fixer l’index de toutes les valeurs, et il est préférable que chaque champ fournisse un accès aléatoire.
Même sans optimisation maniaque, le simple fait d’appliquer ce qui précède donne déjà plus du double de performances par rapport à la méthode du lien que vous avez partagé.
Je l’ai exécuté moi-même, et il a bien tendance à être un peu plus lent, mais ça ne semble pas aller jusqu’à 2x.
===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0
bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14
deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3
Ah… j’ai compris ce que vous vouliez dire. Vous n’aviez pas compris ce qu’il fallait comparer avec quoi… l’algorithme quick sort n’a pas deux modes d’implémentation,
quicksortetin-place……Dès le départ, c’est le fait de rédiger puis de fournir aux utilisateurs de l’IA les fonctions
quickSortGPT()etquickSort()du code ci-dessus (toutes deux générées par GPT), avec la fusion de tableaux intégrée, que je critiquais.Comme la réponse de GPT contenait à la fois
quickSortetquicSortInPlace, et qu’un commentaire signalait la partie[...,quickSort(left), ...equal, ...quickSort(right)], j’avais compris qu’il fallait comparerquickSortavecquickSortetquickSortInPlaceavecquickSortInPlace, mais visiblement ce n’est pas le cas.La phrase « quickSort avec quickSort » me donne envie de me tenir la nuque.
Lorsque vous lisez l’article, vérifiez bien le contexte.
Je ne suis pas en train de me vanter de mon niveau en programmation. Ce que je souligne ici, c’est que du code médiocre comme
quickSort(), utilisé dans l’exemple actuel, est mis en avant avec une priorité élevée par GPT.Quand on fait plusieurs recherches avec GPT, il arrive souvent qu’il fournisse uniquement le résultat d’une fonction
quickSort(). Et encore une fois,quickSort()n’est qu’un exemple. Quand on demande du code à GPT pour un vrai travail, il produit très souvent du code de qualité médiocre (je parle ici en tant qu’utilisateur payant). Si le développeur n’a pas lui-même la capacité de faire la différence, alors je partage l’avis de l’auteur de l’article : il y a de fortes chances que le projet prenne une mauvaise direction et finisse par être détérioré. C’est dans ce contexte que j’en suis arrivé à cette conclusion.Autour de moi, je vois déjà de plus en plus de projets recouverts de ce type de code médiocre.
Bien sûr, la comparaison doit porter sur les performances des deux fonctions
quickSort()etquickSortInPlace()........Partager un résultat affichant un écart de plus du double, allant jusqu’à 3 à 4 fois, puis dire que ce n’est probablement pas jusqu’à 2 fois ?
return [...quickSort(left), ...equal, ...quickSort(right)];
Réfléchissez attentivement à cette partie du code.
J’en apprends beaucoup.
Merci pour votre réponse !
D’abord, dans ce que je disais sur « l’utilisation de l’IA dans un domaine », il va de soi que la conception et la coordination sont assurées par des humains...
En réalité, si cela a pu se discuter autrefois, maintenant que tout le monde connaît les limites des LLM, c’est devenu tellement évident qu’il n’est même plus nécessaire de le préciser.
Ensuite, concernant le cas où des personnes sans connaissances en développement utilisent des LLM,
je ne crois pas que ni l’article, ni Hacker News, ni moi n’ayons parlé de cela, mais quoi qu’il en soit, même dans ce cas, on en est arrivé à un niveau où les utilisateurs peuvent être satisfaits des résultats.
Sinon, Bolt.new, v0 et même Cursor n’auraient sans doute pas la réputation qu’ils ont aujourd’hui.
Résumé,
Auteur : les développeurs doivent eux-mêmes développer et préserver leurs compétences. De toute façon, même l’IA ne fonctionne pas si bien que ça.
crawler : Hein ? Chez moi, ça marche très bien pourtant ?
superscv : Il y a beaucoup de problèmes...
crawler : Il faut juste bien l’ajuster pour l’utiliser
superscv : On s’est éloignés bien trop du message que l’auteur voulait transmettre au départ..
J’ai l’impression que vous n’avez pas bien compris pourquoi j’ai mentionné le domaine de l’auteur ni ce que signifie avoir son propre domaine d’expertise.
Il me semble aussi idiot de déléguer toutes ses décisions à l’IA sans réfléchir par soi-même,
mais je ne comprends pas très bien non plus les gens qui se situent à l’extrême opposé.
Enfin, ce que j’aimerais vous demander, c’est : superscv, comment pensez-vous qu’il faudrait utiliser les LLM pour coder ?
En général, je commente rarement, mais si j’ai laissé un commentaire sur cet article en particulier, c’est parce que je partage assez fortement l’avis de l’auteur. À mes yeux, l’important n’est pas l’IA ou les LLM en eux-mêmes, mais le fait que, quel que soit l’environnement qui se présente, moi, en tant que développeur, je sois prêt.
Du fait des caractéristiques des sources sur lesquelles ils sont entraînés, les LLM fournissent principalement des données proches de la moyenne des données en ligne réparties à travers le monde. (Le quicksort en js mentionné plus haut le démontre.) C’est pourquoi je les utilise souvent pour poser des questions sur des sujets où je veux vérifier dans quelle mesure une idée ou un design s’écarte ou non d’un point de vue généralement admis, ou encore sur des points que j’avais du mal à savoir à qui demander jusqu’à présent.
Je ne vois pas bien quel intérêt il y a à poursuivre davantage la discussion.
Si l’idée est simplement de dire qu’au départ, le code produit par l’IA peut comporter certains risques et qu’il vaut donc mieux le raffiner soigneusement pour l’utiliser de manière appropriée, il me semble qu’il suffirait alors d’expliquer en quoi le texte de l’auteur reflète un point de vue biaisé. D’autant plus que le résumé contient déjà une idée assez proche : « il peut fournir rapidement du code de type scaffold/ébauche, dépourvu de contexte, mais la conception complète et le tuning restent du ressort des développeurs humains ».
Le message de l’auteur a certes une tonalité assez forte, mais si l’on lit bien le texte, il ne dit pas « n’utilisez pas l’IA ». Il propose plutôt une manière de l’utiliser, avec comme idée centrale que les développeurs ne doivent pas eux-mêmes manquer de compétences.
Si le message de l’auteur paraît si appuyé, c’est parce qu’il a été formulé en réaction à une vision selon laquelle il deviendrait possible de développer avec Copilot (avec une nuance de forte dépendance au développement via Copilot). Dans cette perspective, il a orienté son propos de façon à dire aux développeurs de ne pas adopter une posture qui porte atteinte à leur propre valeur d’existence.
Comme l’auteur ne dit pas non plus « n’utilisez pas l’IA », au final, si l’on parle d’exploiter l’IA, cela se situera forcément quelque part dans un compromis ; en ce sens, le fond de son message rejoint assez largement ce que vous venez de répondre.
En revanche, dans ce que vous aviez écrit au départ, j’ai eu du mal à être d’accord avec la partie sur la « vision biaisée », d’où ma réponse en premier lieu.
Réactions sur Hacker News
Si vous voulez créer un logiciel qui doit être parfaitement robuste, comme un logiciel pour pacemaker, système de guidage de missile ou char M1, alors mieux vaut laisser de côté les agents de code IA et adopter une posture d’apprentissage par soi-même
Mais la plupart d’entre nous ne construisent pas ce genre de choses, on produit surtout des apps CRUD avec quasiment les mêmes exigences, où seuls le schéma et la manière d’intégrer changent un peu
En pratique, la plupart des logiciels que nous écrivons n’ont rien de nouveau
Souvent, le mieux à faire est simplement de réutiliser des connaissances existantes
Pour moi, les agents de code sont une version gigantesque de cette réutilisation de code du passé
Et au passage, ironiquement, ce texte lui-même donnait l’impression d’avoir été écrit par une IA
Personnellement, je n’ai déjà pas envie d’écrire du code bas niveau mission-critical
Je ne pense pas non plus que les outils IA soient aussi utiles que l’auteur semble le croire, mais les débats du genre « si tu ne fais pas de programmation système en C, tu n’es pas un vrai programmeur » me fatiguent
J’aime faire du front-end
Je n’ai pas non plus envie de créer moi-même une bibliothèque graphique bas niveau
Je ne suis pas du genre à me réveiller à l’aube pour aller hacker, mais j’ai de la passion et de la fierté pour mon travail
Je ne pense pas que tout le monde doive adopter la même posture extrême que l’auteur
Le marché du logiciel a besoin de diversité
On peut tout à fait contester ce que dit l’auteur, mais affirmer que ce texte a été écrit par une IA, c’est excessif
L’auteur y met des formules très vivantes, des métaphores fortes et même un humour vraiment drôle, avec un style personnel qui traverse tout le texte
Pour un LLM aujourd’hui, écrire quelque chose comme ça serait vraiment difficile
Ce n’est pas de l’IA, c’est un texte bien écrit
Qu’on soit d’accord ou non avec le fond, la qualité d’écriture est là
Il y a aussi ce passage dans le texte original
« Vous n’écrirez probablement pas vous-même le code qui fait voler un avion, ni celui qui touche directement à la vie humaine. La plupart des gens ne le feront pas. Mais même si vous travaillez dans l’enterprise à empiler des apps CRUD banales, vous avez quand même la responsabilité de traiter vos utilisateurs avec respect et dignité »
Cela insiste sur le fait que même les logiciels les plus simples exigent un minimum de responsabilité
En réalité, l’auteur reconnaît lui-même plusieurs cas où l’IA est utile
Son problème principal, c’est qu’on appelle l’IA un « copilote », ce qui peut pousser les débutants à lui faire trop confiance
Un vrai copilote devrait être un pair expérimenté, alors qu’une IA, pour l’instant, c’est une moitié du temps un collègue pourri
« En ce moment, nous plaçons la curiosité et l’initiative à l’extérieur du système. Des gens qui avaient le potentiel pour progresser passent leur temps à relire des patchsets générés par l’IA jusqu’à perdre leur élan. Le terminal devient un tableur, le débogueur devient un cercueil »
Mais l’IA n’est au fond qu’une abstraction de plus
De la même manière que certains craignaient qu’avec des automatisations devenues naturelles comme le GC (ramasse-miettes), on perde les fondamentaux, il y a aussi la crainte qu’avec l’IA, des capacités très élémentaires de programmation et d’apprentissage disparaissent
Grâce aux abstractions, les développeurs web peuvent construire de bons sites sans connaître en profondeur toute la pile
Mais l’IA est une abstraction pleine de trous, et permet à un certain niveau de faire fonctionner des choses sans vraiment connaître les bases
Le problème, c’est qu’un jour on découvre qu’elle cache un bug grave, et que le débogage, la résolution de problèmes et la capacité à apprendre par soi-même sont des domaines que l’IA ne peut pas remplacer
D’où la crainte qu’un apprentissage trop facile avec l’IA fasse sauter des compétences fondamentales importantes
Au fond, la vraie manière d’apprendre passe par la répétition et par le fait de se confronter directement aux problèmes
Si l’IA abstrait jusqu’à cet « apprentissage » lui-même, alors à long terme elle affaiblira les compétences des développeurs
Bien sûr, ce n’est pas parce qu’on utilise l’IA que tout le monde va devenir idiot, et il y aura toujours des gens qui apprennent de façon proactive
Mais dans l’ensemble, cette proportion risque de diminuer
Parce que l’expérience même de « construire en réfléchissant par soi-même » pourrait disparaître pour les débutants
Et cette abstraction qu’est l’IA reste finalement très lacunaire
Pour un débutant, l’IA donne l’impression de tout faire, mais au bout du compte, les compétences essentielles en programmation et en débogage restent nécessaires
Donc, si l’on veut vraiment détecter les problèmes dans le code produit par l’IA, il faut impérativement développer ses compétences
Moi aussi, j’utilise assez bien les assistants de code IA
Mais puisqu’ils ont aussi des défauts, ma conclusion est qu’il ne faut pas les regarder comme si tout n’était que positif
J’ai créé ma propre petite vidéo comique avec Google Whisk puis je l’ai mise sur TikTok, et une fois dedans, ce n’était qu’un océan de contenus générés par IA ou de vidéos que les gens se recopient mutuellement
Je pensais qu’il y avait vraiment quelque chose dans la « création originale », mais au fond nous sommes des êtres trop facilement reproductibles
Même si on mettait nos vidéos de code quotidiennes sur TikTok, ce serait juste une répétition infinie des mêmes apps
Comme le dit Elon Musk, on a presque l’impression qu’il ne reste plus qu’à aller vraiment sur Mars
Il y a deux ans déjà, j’avais dit que les LLM n’« hallucinaient » pas tant que ça, et les gens croient encore qu’il faut absolument l’humain, mais j’ai l’impression que ce n’est de moins en moins vrai
J’aimerais qu’on se rappelle cette discussion dans deux ans
« La machine est réelle. Le silicium, la DRAM, le cache L1, le false sharing, le branch predictor qui lance une pièce, tout cela est réel. Si on s’y intéresse, on peut s’en emparer »
Cela faisait longtemps que je n’avais pas trouvé une phrase aussi belle
L’auteur écrit avec un style à la Dave Barry, et ça m’a fait rire plusieurs fois
J’ai beaucoup aimé la manière dont il exprime, avec humour, des idées très justes sur Copilot
Dans les discussions sur le développement logiciel, on oublie souvent que ce ne sont pas seulement les « résultats du code écrit » qui comptent
Le parcours lui-même, avec ses innombrables compromis, est extrêmement important
Il suffit de faire développer une seule fonctionnalité à un junior dans une codebase un peu complexe pour sentir immédiatement, en tant qu’ingénieur expérimenté, quels compromis on est en train de faire de manière quasi inconsciente
L’IA a bien une notion de ces compromis, mais elle les apprend surtout par observation
Oui, elle aide à « mieux écrire du code », mais au final juger et réfléchir restent des tâches humaines
Les LLM ne « pensent » pas
Et à mesure que l’IA progresse, il y a un risque réel que les humains réfléchissent de moins en moins
Pour moi, les qualités et les défauts de Copilot sonnent tous juste
Mais contrairement à l’image du hacker ou de l’« artisanat » des débuts, les ingénieurs ont toujours été des ingénieurs
Si les technologies centrales d’aujourd’hui sont apparues dans la douleur, c’est aussi parce qu’il fallait absolument résoudre ces difficultés à l’époque
Généraliser cette histoire dramatique en parlant de « l’époque où on faisait comme ça » peut mener à une vision biaisée
Les mises à jour CRUD toutes simples sont répétitives et ennuyeuses, mais les défis casse-tête qui surgissent de temps à autre, les moments où l’on réutilise des notions apprises à l’université, ou encore les cas exceptionnels comme les algorithmes récursifs, sont de véritables joyaux dans une carrière
J’aimerais que les ingénieurs logiciel de demain, guidés par l’IA, accordent encore plus de valeur à ce genre d’expériences
L’IA pourra peut-être parfois fournir une réponse logique, mais comme elle se trompe aussi parfois de façon totalement absurde et dangereuse, il faudra toujours des gens qui sachent réellement ce qu’il faut faire
Quand les IA « hallucinent » ou manquent de contexte, il y aura toujours des situations où seul un humain pourra résoudre le problème
Mon point de comparaison, ce n’est pas le pair programming, mais les développeurs offshore
Franchement, si Copilot, Cursor et les autres outils IA me paraissent bien meilleurs, c’est aussi parce que je n’ai plus besoin de perdre mon temps en appels Zoom à cause de problèmes de communication flous, de barrières de langue ou de décalages de compréhension
Par exemple, des situations fréquentes en sous-traitance comme « on a ajouté une fonction isChild (retour booléen) liée au root node, mais qui n’a rien à voir avec la vérification de l’existence d’un parent », ou « ce paramètre d’API n’accepte soudainement plus de tableau »
Quand ça arrive avec une IA, je peux immédiatement lui dire que c’est faux et lui expliquer pourquoi, et elle corrige vite
Il y a beaucoup moins de communication laborieuse, de malentendus ou de perte de temps qu’avec un humain
Dès que l’IA sera facilement reliée aux tickets Jira, environ 80 % du travail de développement va se transformer en rédaction de tickets et en rôle de supervision
Bien sûr, cela ne veut pas dire que le rôle de l’ingénieur disparaîtra — les équipes Biz n’écriront jamais de bons tickets, et quelqu’un devra toujours assumer la responsabilité finale
Malgré tout, beaucoup d’organisations vont l’oublier, et cela laisse de la place pour de gros accidents
Ce que je retiens surtout de ce texte, c’est
« Nous finirons par glorifier au plus haut point la réalité arriérée, boursouflée et excessivement abstraite du logiciel actuel. La culture qui consistait à extraire jusqu’à la dernière goutte de performance, ou à construire des systèmes maigres, tranchants et limpides, ne survivra plus que comme un vieux récit »
Il y a une vraie inquiétude que les bibliothèques ou patterns d’architecture créés avant 2023 se figent à jamais en devenant le cœur des données d’entraînement des LLM
Au lieu d’innover sans cesse, on risque de perpétuer éternellement les dépendances accumulées et le code sale des trente dernières années
Ça m’inquiète même pour quelque chose comme Javascript, qui semble parti pour vivre éternellement
En ce moment, je ressens la pression quotidienne du leadership qui répète « nous n’utilisons pas assez l’IA » ou « si on adopte l’IA, on peut couper les délais en deux »
On nous force à introduire de nouveaux outils IA pour atteindre les KPI, et si on ne s’adapte pas, on évoque même des réductions d’effectifs
J’ai vraiment l’impression que le monde est devenu complètement fou
L’IA est toujours présentée comme un « outil pour remplacer le travail des autres »
En réalité, elle ne paraît bonne que lorsqu’on évalue le travail de quelqu’un d’autre sans vraiment bien le connaître
On dirait que le management a pris un marteau appelé IA et essaie de clouer absolument tout ce qui existe
Il faut vraiment réfléchir à la manière de réduire d’une façon ou d’une autre la structure managériale, et de trouver un moyen de consacrer plus de temps au vrai travail productif
J’aimerais une culture qui se concentre davantage sur l’exécution réelle et la livraison que sur l’usage de l’IA
En réalité, ce n’est que le schéma classique du hype cycle de l’industrie IA
Quand la situation se calmera, il ne restera que les outils et technologies réellement utiles, et la majorité disparaîtra
L’idée est d’identifier intelligemment ce qui aura une vraie valeur durable, et si l’on peut influencer ce changement, c’est aussi comme ça qu’on pourra continuer à s’en sortir
L’injonction actuelle à « l’adopter vite » va exactement à l’encontre de ce que j’ai toujours considéré comme l’essence de l’ingénierie, du design ou du travail technique
Normalement, on étudiait soigneusement s’il fallait adopter un outil, un langage ou un service, on justifiait pourquoi cela convenait à notre cas, et on exposait clairement les avantages et inconvénients
Le processus normal de décision consistait à demander « pourquoi en avons-nous besoin ? », « pourquoi ce service est-il plus rationnel ? »
Il y avait un processus pour tester si une technologie devait vraiment être adoptée, puis pour évaluer les résultats et l’efficacité de cette adoption
Les entreprises actuelles s’éloignent de cette manière saine de faire
Le fantasme selon lequel « l’IA est toujours un outil capable de remplacer le travail des autres » est bien trop répandu
En pratique, il y a certes beaucoup de tâches répétitives, mais pour bien faire la plupart des métiers, il faut des subtilités et une finesse propres à chaque contexte, et tout cela risque de disparaître dans l’automatisation
Je ne suis pas d’accord avec l’idée que « 80 % avec l’IA, c’est suffisant »
Les erreurs ont un impact sur l’ensemble du système, et ceux qui évaluent les résultats manquent souvent d’expérience de terrain
J’ai l’impression que les postes de management vont disparaître plus vite encore
D’ici là, courage à tous
L’auteur semble clairement être un développeur C++
En pratique, les assistants de code IA fonctionnent rarement correctement en C++, et ceux qui en tirent réellement parti le font surtout avec des langages de script ou des apps CRUD
Les connaissances et ressources en développement de jeux n’ont pas été apprises massivement par les LLM, donc contrairement au cas des apps CRUD, l’auteur ressent probablement plus directement les limites des LLM
Une partie de ce texte s’entend presque avec la voix du personnage Bertram Gilfoyle dans la série Silicon Valley
Je me demande si je suis le seul à avoir eu cette impression
L’idée centrale, c’est de toujours garder une capacité de « télescope »
C’est très bien de travailler à un niveau élevé grâce aux agents de code, mais pour rester en sécurité, il faut être capable à tout moment de descendre dans les profondeurs du code pour le comprendre et le corriger soi-même