L’auteur le dit pourtant clairement, son intention est de convaincre quiconque aurait été déçu des capacités de codage de l’IA, voici 6 mois, voire deux, car depuis tout a radicalement changé. L’exemple donné des problèmes pour faire coder du Rust montre bien que l’IA n’a toujours rien compris à la programmation, se contentant d’enchaîner des heuristiques ; qui certes semblent fonctionner admirablement bien s’il faut produire du code « médiocre » tant en termes de qualité (´article l’affirme) que d’originalité (je crains que l’auteur oublie ce point).
C’est là que ma position devient irréconciliable avec celle défendue. Nonobstant que les IA semblent n’avoir pas fréquenter le genre de problèmes sur lequel je code, j’ai coutume de sermonner mes étudiants en affirmant que la programmation est le domaine du zéro fautes. Pas de place donc pour les approximations.
Qui sait, peut-être l’an prochain serais-je enfin convaincu. Avec un remplaçant à X11 et Wayland codé par AI et combinant les qualités des deux ? Qui sait.
j’ai coutume de sermonner mes étudiants en affirmant que la programmation est le domaine du zéro fautes.
Et pourtant les logiciels qu'on utilise sont remplis de bugs, espèce de mauvais prof ;)
De mon côté, j'ai besoin d'aide pour coder un outil dans le cadre de mon travail : personne codera ça car c'est bien trop de niches, sans sous et la tâche ne présente que peu d' intérêt algorithmique pour un ingénieur.
Je sais un peu coder, donc je relis le code que me fournit les "IA", et je le comprends et l'adapte. Mais utiliser des "IA" rend le projet possible car je n'aurais pas l'énergie sinon. Et je peux aussi me concentrer davantage sur les aspects métiers et théoriques qui me sont importants.
D'ailleurs dans quelques mois, je presenterai ce projet sur Linuxfr, je me demande bien quels retours j'aurai…
La règle de l’accord en nombre avec un privatif (« pas de », « sans »…) en français est particulièrement étrange, elle dit :
On accorde en nombre avec le nombre habituel de ce qui est absent.
Exemples :
« Il n’y a pas de micro sur ce casque » avec « micro » au singulier parce qu’il est attendu qu’il n’y en ait qu’un
« Ce lion n’a pas de courage » avec « courage » au singulier parce qu’indénombrable
« Il n’y a pas d’abeilles dans cette ruche » avec « abeilles » au pluriel parce qu’il est attendu qu’il y en ait plusieurs.
Le cas de « zéro » est encore plus particulier, parce que c’est souvent un raccourci pour un privatif (« zéro sucres » pour « pas de sucres ») ; mais là on ajoute une règle flottante sur une règle déjà pas très claire. Donc : c’est pas spécialement une faute.
C’est aussi le moment de rappeler que le français est une langue vivante, et contrairement à ce que tentent de faire croire quelques organismes enkystés dans un monde théorique, son orthographe n’est pas complètement figée et encore moins logique.
Je conseille donc de se détendre à ce sujet, de lire https://www.tract-linguistes.org/ (leur tract papier est plus complet que le site et vraiment pas cher) et d’arrêter d’attaquer les gens sur leur orthographe, ce qui n’a jamais aucun intérêt (sauf cas rare où le message est complètement illisible) mais plutôt de se concentrer sur le fond (ou éventuellement le ton s’il est problématique) de leurs propos, c’est infiniment plus intéressant et utile au débat.
L’exemple donné des problèmes pour faire coder du Rust montre bien que l’IA n’a toujours rien compris à la programmation
Mes juniors formés à faire du python et du javascript sont incapable de faire du rust. Ont-ils pour autant rien compris à la programmation ?
qui certes semblent fonctionner admirablement bien s’il faut produire du code « médiocre » tant en termes de qualité (´article l’affirme) que d’originalité (je crains que l’auteur oublie ce point).
Ça tombe bien, c'est exactement ce que je lui demande. À lui le code chiant, stupide, rébarbatif; et à moi le code rigolo et intelligent.
j’ai coutume de sermonner mes étudiants en affirmant que la programmation est le domaine du zéro fautes. Pas de place donc pour les approximations.
et après tes étudiants découvriront ce truc qu'on appelle "les contraintes de la vraie vie". En entreprise (sauf cas particuliers critiques), avoir aujourd'hui un code qui gère 95% des cas >> à un code qui gère absolument tous les cas possible et inimaginable mais qui ne sera livré que dans 10 ans.
Qui sait, peut-être l’an prochain serais-je enfin convaincu. Avec un remplaçant à X11 et Wayland codé par AI et combinant les qualités des deux ? Qui sait.
tu attends aussi de tes étudiants qu'ils soient capable de faire ça ?
Ça tombe bien, c'est exactement ce que je lui demande. À lui le code chiant, stupide, rébarbatif; et à moi le code rigolo et intelligent.
Qu’est le « code rigolo et intelligent » qui ne sera pas jugé comme chiant par une autre personne ou que tu ne peux confier à l’intelligence a…?
j’ai coutume de sermonner mes étudiants en affirmant que la programmation est le domaine du zéro fautes. Pas de place donc pour les approximations.
et après tes étudiants découvriront ce truc qu'on appelle "les contraintes de la vraie vie". En entreprise (sauf cas particuliers critiques), avoir aujourd'hui un code qui gère 95% des cas >> à un code qui gère absolument tous les cas possible et inimaginable mais qui ne sera livré que dans 10 ans.
Tu veux dire que 5% des cas inimaginables arriveront dans 10 ans non ? Du coup, on gère bien tous les cas imaginables non ? En tout cas je ne comprends pas où doit être l’opposition : toute violation de contrainte est en soi une faute, et tout code d’entreprise est soumis à moult contraintes connues.
P.S. J’ai eu la chance de connaître des cursus où l’on enseignait par exemple la Méthode B <3
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Une autre serait, qu'est ce qu'il te faut comme matos en local pour résoudre "cette tâche bien particulière" à l'heure ou presque aucune machine/CPU n'est vendue sans le tampon IA.
"Si tous les cons volaient, il ferait nuit" F. Dard
L'autre problématique rarement évoqué sur ce sujet est la confidentialité.
Utiliser un LLM dans son coin pour son boulot qui est en ligne et non avalisé par son employeur, cela signifie que tous les échanges sont normalement monitorés par l'entreprise fournissant le dit LLM.
Ce n'est pas terrible alors que dans le lot il peut y avoir des données plus ou moins sensibles, que ces échanges et donc le code et ces éléments peuvent servir de base d'entrainement et donc éventuellement ressortir plus tard. Etc. Dans un contexte pro c'est vraiment un problème.
Je doute que tout le monde fasse attention à cela dans ce contexte…
La question du droit d'auteur n'est semble-t-il toujours pas tranché à ce jour non plus.
Cet article présente des arguments qui font sens et d'autres beaucoup moins. Et c'est dommage de mettre les défauts et problématiques réels sous le tapis, même si je peux comprendre sa frustration face à certains arguments, il ne faut pas oublier ces éléments non plus.
Ce n'est pas terrible alors que dans le lot il peut y avoir des données plus ou moins sensibles, que ces échanges et donc le code et ces éléments peuvent servir de base d'entrainement et donc éventuellement ressortir plus tard. Etc. Dans un contexte pro c'est vraiment un problème.
Il faut clairement demander l'autorisation, mais en général, si tu utilises les API payantes (et non les interfaces web gratuites) les données ne se retrouvent pas dans les données d’entraînement.
Ok cet article va vraiment à l'opposé de moi, sauf qu'il a en gros des arguments similaires… sauf que pour cette personne, ces arguments sont des "avantages", pour moi des défauts.
Pour n'en citer que quelques uns, il en va jusqu'à dire que le code médiocre est une bonne chose:
As a mid-late career coder, I’ve come to appreciate mediocrity. You should be so lucky as to have it flowing almost effortlessly from a tap.
Cela résonne particulièrement avec mon argument principal sur l'IA (qui s'applique aussi sur beaucoup de changements de société), que j'ai beaucoup répété: "l'IA est une nouvelle apogée de médiocrité". Cela est une juste continuation des précédentes étapes dans cette direction:
déconsidérer le travail des artistes en jouant sur leur précarité (cf. les multiples "concours" des grosses boîtes qui ont largement de quoi rémunérer mais préfèrent le travail gratuit);
racheter des journaux connus, se débarrasser des journalistes et experts du sujet pour les remplacer par… des publicitaires, voire par rien;
dans le monde logiciel, faire de plus en plus de la merde, car on peut se le permettre ("enshittification"), la qualité des services n'est depuis longtemps plus une priorité;
etc.
Ben l'IA est l'étape d'après, que ce soit pour remplacer des artistes (graphiques, sons, auteurs…), des journalistes, des développeurs… après tout puisque la qualité n'était déjà plus recherchée, aller encore plus loin, avec l'IA, dans la recherche du profit au détriment de la qualité, n'est effectivement pas perçu comme un problème.
Maintenant qu'on ne me fasse pas dire ce que je n'ai pas dit. Bien entendu que parfois, on est OK pour que certaines tâches ne soient pas parfaites. C'est la gestion des priorités. Sauf qu'avec l'IA, on décale d'autant plus les critères vers la médiocrité généralisée de toutes les tâches.
Y a aussi tout le speech sur le "code ennuyeux" ("tedious code"), qui correspond sûrement beaucoup au "boilerplate" code. On appelle souvent ainsi le code plus structurel (à comparer avec du code plus algorithmique), l'organisation du code par le code quoi. Si on veut faire une analogie, ce sera comment on organise des fichiers dans son bureau, pour les retrouver facilement, ou pour être plus efficace, avec une logique qui rend son travail plus simple au final, etc. Cette personne semble pré-supposer que ce code pourrait être simplement fait par des IAs. Or c'est justement le genre de code qui ne doit absolument pas être fait par des IAs. C'est en fait une erreur typique de débutants de croire que les projets chiants de réorganisation (par exemple la "factorisation" de code) est un truc pour les petits nouveaux. Alors que c'est tout l'inverse. La bonne organisation du code, avec une logique qui donne tout de suite beaucoup plus de sens au code plus "métier" est un truc très humain qui demande une grosse réflexion sur le sens du code. Dans un code objet par exemple, on va réfléchir à quelle classe est sémantiquement fille de quelle autre classe, ou doit implémenter telle interface. On va aussi réfléchir à l'organisation des fichiers: doit-on séparer le code dans son propre fichier? Doit-on au contraire le mettre dans tel fichier ou classe existant(e) parce que ça paraît structurellement sain? Quels noms donner aux fonctions? Quelle est la logique des diverses parties du code? Etc. Etc. La partie vraiment "boilerplate" prend peut-être beaucoup de lignes mais en fait, cette part du travail est très rapide (quelques secondes) et peut d'ailleurs être automatisée (pas par IA, mais parce que ce sont des choses répétitives que l'on peut aisément automatiser d'une manière où on est sûr qu'on ne crée pas de bugs). La part "chiante" du travail d'organisation par contre est importante et n'est pas quelque chose que l'on donne à faire au débutant/stagiaire/IA.
Donc quand le gars finit cette section de son post avec cette phrase:
If you listen to me, you’ll know that. You’ll feel worse yak-shaving. You’ll end up doing… real work.
Ma première réaction, c'est que ce gars n'est sûrement pas très compétent (ce qu'il dit lui-même être le cas en introduction de son billet).
Un code a besoin d'être bien structuré pour être maintenable. Si vous avez des centaines de milliers de ligne de code, vous voulez qu'elles suivent une logique et une organisation saine et compréhensible, pas un truc fait à la va-vite par le stagiaire qui était là quelques semaines, ne comprenait pas le code existant mais a quand même voulu vous faire un "refactoring" parce qu'il est persuadé qu'il fera mieux que les barbus qui ont fait ce code y a 10 ans.
Donc non, mon cher monsieur, toute cette partie "ennuyeuse" est très certainement chiante et personne ne veut la faire, mais elle n'en reste pas moins primordiale pour que votre logiciel ne s'écroule pas comme un château de carte après quelques itérations de stagiaires et incrémentations IA… ce qui ne vous intéresse pas seulement lorsque vous vous dites que de toutes façons, vous ne serez sûrement plus là quand ça arrivera.
Penser que ce n'est pas du "real work", c'est n'avoir rien compris à notre métier et ne peut que conduire à faire des correctifs principalement superficiels. Parfois, la bonne correction pour certains problèmes implique de la restructuration, ce qui nécessite d'aller plus loin dans la compréhension du code et des différents rouages d'un logiciel; c'est même souvent à cela qu'on reconnaît les débutants, c'est qu'ils se contentent de petits "pansements" du code qui consistent souvent en changement superficiel des symptômes (cachant le vrai bug, qui réapparaîtra un jour sous une autre forme), tout ça parce qu'ils n'ont pas réellement étudié le code du logiciel et sa structure. C'est d'ailleurs assez symptomatique de cette vision des tests unitaires visibles dans cet article, où croire que si l'IA peut itérer dans le code jusqu'à ce que les tests passent, alors ça veut dire que le code est bon… euh… comment dire. Un développeur qui pense ainsi me fait peur au plus haut point.
Ensuite il explique que de toutes façons, il faut lire le code donc au final on le comprend, et il devient "nôtre". Et là je me pose de plus en plus de questions sur ses compétences.
Bien sûr qu'on relit du code d'autrui, ce qui permet de faire des revues de code pour que ces personnes le corrige. Sauf que cela prend énormément plus de temps que si on écrivait ce code nous même de rien. Combien de fois un mainteneur a-t-il passé des heures (étalés sur des jours, voire des semaines, donc avec en plus la perte de temps liée au fait de changer notre état mental d'un code à l'autre — context switch pour une analogie technique) sur une revue de patch en se disant que ça lui aurait pris 30 min pour le faire parfaitement soi-même?
Alors… dans ces conditions, pourquoi fait-on cela? L'une des raisons est pour provoquer la montée en compétence des autres contributeurs. Ils ne connaissent pas encore aussi bien la base de code que nous, ils sont peut-être aussi jeunes, etc. On les forme en quelque sorte. Cela veut dire aussi que c'est un investissement sur l'avenir car ce petit nouveau sera alors très efficace dans quelques semaines, puis encore plus dans quelques mois, et enfin quelques années.
L'IA, elle sera toujours aussi nulle. Elle ne monte pas en compétence. Donc en gros, on est coincé avec un débutant perpétuel qui fera toujours un code qui nous fera perdre notre temps. Or si ce gars estime que ce code de débutant qu'il doit à chaque fois relire, comprendre et réorganiser ne lui fait en fait pas perdre de temps… ben je me demande vraiment comment il code!
Je passe ensuite sur les propres hallucinations du gars quand il parle des hallucinations de l'IA en les balayant d'une main, ou sur son argument nul et à vomir quand il parle du stagiaire qui coûte plus que 20€ par mois (d'autant plus quand on sait que ce n'est même pas un business model viable et que les pris sont destinés à augmenter; là ils perdent de l'argent à tout va juste pour habituer les gens au produit en espérant les rendre suffisamment accros et dépendants pour qu'ils paient plein pot plus tard).
Je vais aussi passer tous les autres arguments (rust; j'ai déjà aussi parlé de son ode à la médiocrité; je ne m'étendrai même pas sur son balayage atroce d'un revers de main du problème de droit d'auteur, prétextant que les artistes, c'est différent 🙄 — ce qui tombe bien car il n'est pas artiste! Ni même vraiment développeur j'ai l'impression…).
Je vais juste faire un dernier point sur la section expliquant qu'on n'est pas des artisans. Ah bah voilà. Personnellement je me considère artisan du code. Le gars en gros t'explique que l'artisanat, c'est du hobbyisme:
I have a basic wood shop in my basement †. I could get a lot of satisfaction from building a table. And, if that table is a workbench or a grill table, sure, I’ll build it. But if I need, like, a table? For people to sit at? In my office? I buy a fucking table.
Ben il a juste pas compris ce qu'est l'artisanat. L'artisan menuisier, c'est pas un gars qui fait des tables nulles sur lesquelles on peut pas travailler correctement (pour réutiliser son analogie)! Bien sûr, il peut y en avoir des bons et des moins bons. Mais le bon artisan menuisier, il vous fera une table de qualité qu'on peut garder sur des générations, qui sera belle en plus d'être utile, possiblement personnalisée à votre besoin en plus.
Mais oui, ça coûtera plus cher. C'est pour cela que les gens vont chez les industries qui font des tables à la chaîne. Mais de meilleure qualité? Sûrement pas! C'est le contraire en fait!
Mais c'est sûr que si on se considère comme un "travailleur à la chaîne" du code, qu'on se complaît dans la médiocrité de son résultat, voire limite qu'on en est fier, que la chose principale qui nous importe soit apparemment le bas coût de l'AI (avec une vision très court-termiste puisqu'il est connu — car ça a été publiquement dit par les entreprises de l'IA — que ces coûts actuels sont à perte), et qu'on s'en fout de la problématique écologique (cette problématique n'est même pas citée parmi les autres arguments, soit parce que le gars ne saurait pas comment la démonter — faut dire aussi que pour le faire, faut avoir une bonne dose de mauvaise foi —, soit parce que la problématique écologique ne pénètre même pas l'esprit des solutionnistes technologiques) alors oui peut-être dans ce cas, je peux comprendre qu'on trouve l'IA bien.
En gros, on a les mêmes arguments, mais pour des gens qui ont ce mode de pensée, alors ce sont des arguments positifs, et pour d'autres c'est bel et bien négatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ben il a juste pas compris ce qu'est l'artisanat. L'artisan menuisier, c'est pas un gars qui fait des tables nulles sur lesquelles on peut pas travailler correctement (pour réutiliser son analogie)! Bien sûr, il peut y en avoir des bons et des moins bons. Mais le bon artisan menuisier, il vous fera une table de qualité qu'on peut garder sur des générations, qui sera belle en plus d'être utile, possiblement personnalisée à votre besoin en plus.
Plus précisément, il la fera en gaspillant un minimum de matériau. Ce qui est aussi une caractéristique de l'artisanat (le vrai, pas celui des youtubeurs et youtubeuses qui gâchent des tonnes de matières premières pour faire un truc plus ou moins merdique).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Posté par MicP .
Évalué à 3 (+2/-0).
Dernière modification le 04 juin 2025 à 19:52.
Celui qui sait choisir les différentes essences de bois qu'il faudra pour pouvoir fabriquer ou restaurer des tables ou autres meubles, c'est un ébéniste. On reconnait facilement un ébéniste car souvent, il lui manque un ou plusieurs doigts.
Le menuisier fera plutôt des charpentes, des portes, des fenêtres et le cadre qui servira à les tenir en place, des plinthes, etc. qui seront parfois en bois, ou en PVC ou en aluminium …(Les menuisiers menuisent car ils déposent des plinthes au parquet)
Dans certaines contrées les menuisiers sont aussi des ébénistes, ou l’inverse. Et il faut aussi choisir les essences de bois pour faire portes et fenêtres par exemple.
Question : quelle est la différence entre le menuisier et le charpentier ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Affûteur/Affûteuse
Agenceur/Agenceuse de cuisines et salles de bains
Bûcheron/Bûcheronne
Charpentier/Charpentière bois
Conducteur/Conductrice de machines à papier
Conducteur-opérateur/Conductrice-opératrice de scierie
Designer industriel/Designeuse industrielle
Ébéniste
Ingénieur forestier/Ingénieure forestière
Ingénieur papetier/Ingénieure papetière
Menuisier/Menuisière
Ouvrier forestier/Ouvrière forestière
Responsable de scierie
Technicien forestier/Technicienne forestière
(*) au moins un pote de ma promo d'ingé en informatique est désormais charpentier
# Toujours pas changé d’avis
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 9 (+8/-1).
L’auteur le dit pourtant clairement, son intention est de convaincre quiconque aurait été déçu des capacités de codage de l’IA, voici 6 mois, voire deux, car depuis tout a radicalement changé. L’exemple donné des problèmes pour faire coder du Rust montre bien que l’IA n’a toujours rien compris à la programmation, se contentant d’enchaîner des heuristiques ; qui certes semblent fonctionner admirablement bien s’il faut produire du code « médiocre » tant en termes de qualité (´article l’affirme) que d’originalité (je crains que l’auteur oublie ce point).
C’est là que ma position devient irréconciliable avec celle défendue. Nonobstant que les IA semblent n’avoir pas fréquenter le genre de problèmes sur lequel je code, j’ai coutume de sermonner mes étudiants en affirmant que la programmation est le domaine du zéro fautes. Pas de place donc pour les approximations.
Qui sait, peut-être l’an prochain serais-je enfin convaincu. Avec un remplaçant à X11 et Wayland codé par AI et combinant les qualités des deux ? Qui sait.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Toujours pas changé d’avis
Posté par lejocelyn (site web personnel) . Évalué à 5 (+5/-2).
Et pourtant les logiciels qu'on utilise sont remplis de bugs, espèce de mauvais prof ;)
De mon côté, j'ai besoin d'aide pour coder un outil dans le cadre de mon travail : personne codera ça car c'est bien trop de niches, sans sous et la tâche ne présente que peu d' intérêt algorithmique pour un ingénieur.
Je sais un peu coder, donc je relis le code que me fournit les "IA", et je le comprends et l'adapte. Mais utiliser des "IA" rend le projet possible car je n'aurais pas l'énergie sinon. Et je peux aussi me concentrer davantage sur les aspects métiers et théoriques qui me sont importants.
D'ailleurs dans quelques mois, je presenterai ce projet sur Linuxfr, je me demande bien quels retours j'aurai…
[^] # Re: Toujours pas changé d’avis
Posté par BAud (site web personnel) . Évalué à -2 (+3/-7).
encore faudrait-il avoir zéro faute pour faire un sans-faute ;-)
(outre l'accord au participe passé après l'auxiliaire avoir, dans la même phrase de surcroît :p)
[^] # Re: Toujours pas changé d’avis
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10 (+12/-0). Dernière modification le 04 juin 2025 à 10:15.
La règle de l’accord en nombre avec un privatif (« pas de », « sans »…) en français est particulièrement étrange, elle dit :
Exemples :
Le cas de « zéro » est encore plus particulier, parce que c’est souvent un raccourci pour un privatif (« zéro sucres » pour « pas de sucres ») ; mais là on ajoute une règle flottante sur une règle déjà pas très claire. Donc : c’est pas spécialement une faute.
C’est aussi le moment de rappeler que le français est une langue vivante, et contrairement à ce que tentent de faire croire quelques organismes enkystés dans un monde théorique, son orthographe n’est pas complètement figée et encore moins logique.
Je conseille donc de se détendre à ce sujet, de lire https://www.tract-linguistes.org/ (leur tract papier est plus complet que le site et vraiment pas cher) et d’arrêter d’attaquer les gens sur leur orthographe, ce qui n’a jamais aucun intérêt (sauf cas rare où le message est complètement illisible) mais plutôt de se concentrer sur le fond (ou éventuellement le ton s’il est problématique) de leurs propos, c’est infiniment plus intéressant et utile au débat.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Toujours pas changé d’avis
Posté par Lutin . Évalué à 8 (+6/-0).
Ah si, le message a provoqué ta réponse et j'y ai appris des trucs.
[^] # Re: Toujours pas changé d’avis
Posté par jtremesay (site web personnel) . Évalué à 5 (+3/-0).
Mes juniors formés à faire du python et du javascript sont incapable de faire du rust. Ont-ils pour autant rien compris à la programmation ?
Ça tombe bien, c'est exactement ce que je lui demande. À lui le code chiant, stupide, rébarbatif; et à moi le code rigolo et intelligent.
et après tes étudiants découvriront ce truc qu'on appelle "les contraintes de la vraie vie". En entreprise (sauf cas particuliers critiques), avoir aujourd'hui un code qui gère 95% des cas >> à un code qui gère absolument tous les cas possible et inimaginable mais qui ne sera livré que dans 10 ans.
tu attends aussi de tes étudiants qu'ils soient capable de faire ça ?
[^] # Re: Toujours pas changé d’avis
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Qu’est le « code rigolo et intelligent » qui ne sera pas jugé comme chiant par une autre personne ou que tu ne peux confier à l’intelligence a…?
Tu veux dire que 5% des cas inimaginables arriveront dans 10 ans non ? Du coup, on gère bien tous les cas imaginables non ? En tout cas je ne comprends pas où doit être l’opposition : toute violation de contrainte est en soi une faute, et tout code d’entreprise est soumis à moult contraintes connues.
P.S. J’ai eu la chance de connaître des cursus où l’on enseignait par exemple la Méthode B <3
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# My AI enthousiast friends are all pathetic
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+14/-0).
On dirait quelqu'un qui essaye de justifier son dernier achat impulsif de robot cuisine.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Ressources utilisées ?
Posté par Glandos . Évalué à 9 (+7/-0).
Pas un mot sur l'efficacité ?
C'est sûr, c'est rapide. Un train-fusée aussi, c'est très rapide, mais ça bouffe tellement de carburant que c'est pas très pratique.
Les LLM non-locaux, ça mange une énergie folle pour sortir un code plus rapidement, mais à quel prix du coup ?
[^] # Re: Ressources utilisées ?
Posté par Luc-Skywalker . Évalué à 5 (+3/-0).
C'est une question, c'est sur.
Une autre serait, qu'est ce qu'il te faut comme matos en local pour résoudre "cette tâche bien particulière" à l'heure ou presque aucune machine/CPU n'est vendue sans le tampon IA.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Ressources utilisées ?
Posté par Renault (site web personnel) . Évalué à 10 (+9/-0).
L'autre problématique rarement évoqué sur ce sujet est la confidentialité.
Utiliser un LLM dans son coin pour son boulot qui est en ligne et non avalisé par son employeur, cela signifie que tous les échanges sont normalement monitorés par l'entreprise fournissant le dit LLM.
Ce n'est pas terrible alors que dans le lot il peut y avoir des données plus ou moins sensibles, que ces échanges et donc le code et ces éléments peuvent servir de base d'entrainement et donc éventuellement ressortir plus tard. Etc. Dans un contexte pro c'est vraiment un problème.
Je doute que tout le monde fasse attention à cela dans ce contexte…
La question du droit d'auteur n'est semble-t-il toujours pas tranché à ce jour non plus.
Cet article présente des arguments qui font sens et d'autres beaucoup moins. Et c'est dommage de mettre les défauts et problématiques réels sous le tapis, même si je peux comprendre sa frustration face à certains arguments, il ne faut pas oublier ces éléments non plus.
[^] # Re: Ressources utilisées ?
Posté par flagos . Évalué à 3 (+1/-0).
Il faut clairement demander l'autorisation, mais en général, si tu utilises les API payantes (et non les interfaces web gratuites) les données ne se retrouvent pas dans les données d’entraînement.
# Cet article est une ode à la médiocrité
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+21/-0).
Ok cet article va vraiment à l'opposé de moi, sauf qu'il a en gros des arguments similaires… sauf que pour cette personne, ces arguments sont des "avantages", pour moi des défauts.
Pour n'en citer que quelques uns, il en va jusqu'à dire que le code médiocre est une bonne chose:
Cela résonne particulièrement avec mon argument principal sur l'IA (qui s'applique aussi sur beaucoup de changements de société), que j'ai beaucoup répété: "l'IA est une nouvelle apogée de médiocrité". Cela est une juste continuation des précédentes étapes dans cette direction:
Ben l'IA est l'étape d'après, que ce soit pour remplacer des artistes (graphiques, sons, auteurs…), des journalistes, des développeurs… après tout puisque la qualité n'était déjà plus recherchée, aller encore plus loin, avec l'IA, dans la recherche du profit au détriment de la qualité, n'est effectivement pas perçu comme un problème.
Maintenant qu'on ne me fasse pas dire ce que je n'ai pas dit. Bien entendu que parfois, on est OK pour que certaines tâches ne soient pas parfaites. C'est la gestion des priorités. Sauf qu'avec l'IA, on décale d'autant plus les critères vers la médiocrité généralisée de toutes les tâches.
Y a aussi tout le speech sur le "code ennuyeux" ("tedious code"), qui correspond sûrement beaucoup au "boilerplate" code. On appelle souvent ainsi le code plus structurel (à comparer avec du code plus algorithmique), l'organisation du code par le code quoi. Si on veut faire une analogie, ce sera comment on organise des fichiers dans son bureau, pour les retrouver facilement, ou pour être plus efficace, avec une logique qui rend son travail plus simple au final, etc. Cette personne semble pré-supposer que ce code pourrait être simplement fait par des IAs. Or c'est justement le genre de code qui ne doit absolument pas être fait par des IAs. C'est en fait une erreur typique de débutants de croire que les projets chiants de réorganisation (par exemple la "factorisation" de code) est un truc pour les petits nouveaux. Alors que c'est tout l'inverse. La bonne organisation du code, avec une logique qui donne tout de suite beaucoup plus de sens au code plus "métier" est un truc très humain qui demande une grosse réflexion sur le sens du code. Dans un code objet par exemple, on va réfléchir à quelle classe est sémantiquement fille de quelle autre classe, ou doit implémenter telle interface. On va aussi réfléchir à l'organisation des fichiers: doit-on séparer le code dans son propre fichier? Doit-on au contraire le mettre dans tel fichier ou classe existant(e) parce que ça paraît structurellement sain? Quels noms donner aux fonctions? Quelle est la logique des diverses parties du code? Etc. Etc. La partie vraiment "boilerplate" prend peut-être beaucoup de lignes mais en fait, cette part du travail est très rapide (quelques secondes) et peut d'ailleurs être automatisée (pas par IA, mais parce que ce sont des choses répétitives que l'on peut aisément automatiser d'une manière où on est sûr qu'on ne crée pas de bugs). La part "chiante" du travail d'organisation par contre est importante et n'est pas quelque chose que l'on donne à faire au débutant/stagiaire/IA.
Donc quand le gars finit cette section de son post avec cette phrase:
Ma première réaction, c'est que ce gars n'est sûrement pas très compétent (ce qu'il dit lui-même être le cas en introduction de son billet).
Un code a besoin d'être bien structuré pour être maintenable. Si vous avez des centaines de milliers de ligne de code, vous voulez qu'elles suivent une logique et une organisation saine et compréhensible, pas un truc fait à la va-vite par le stagiaire qui était là quelques semaines, ne comprenait pas le code existant mais a quand même voulu vous faire un "refactoring" parce qu'il est persuadé qu'il fera mieux que les barbus qui ont fait ce code y a 10 ans.
Donc non, mon cher monsieur, toute cette partie "ennuyeuse" est très certainement chiante et personne ne veut la faire, mais elle n'en reste pas moins primordiale pour que votre logiciel ne s'écroule pas comme un château de carte après quelques itérations de stagiaires et incrémentations IA… ce qui ne vous intéresse pas seulement lorsque vous vous dites que de toutes façons, vous ne serez sûrement plus là quand ça arrivera.
Penser que ce n'est pas du "real work", c'est n'avoir rien compris à notre métier et ne peut que conduire à faire des correctifs principalement superficiels. Parfois, la bonne correction pour certains problèmes implique de la restructuration, ce qui nécessite d'aller plus loin dans la compréhension du code et des différents rouages d'un logiciel; c'est même souvent à cela qu'on reconnaît les débutants, c'est qu'ils se contentent de petits "pansements" du code qui consistent souvent en changement superficiel des symptômes (cachant le vrai bug, qui réapparaîtra un jour sous une autre forme), tout ça parce qu'ils n'ont pas réellement étudié le code du logiciel et sa structure. C'est d'ailleurs assez symptomatique de cette vision des tests unitaires visibles dans cet article, où croire que si l'IA peut itérer dans le code jusqu'à ce que les tests passent, alors ça veut dire que le code est bon… euh… comment dire. Un développeur qui pense ainsi me fait peur au plus haut point.
Ensuite il explique que de toutes façons, il faut lire le code donc au final on le comprend, et il devient "nôtre". Et là je me pose de plus en plus de questions sur ses compétences.
Bien sûr qu'on relit du code d'autrui, ce qui permet de faire des revues de code pour que ces personnes le corrige. Sauf que cela prend énormément plus de temps que si on écrivait ce code nous même de rien. Combien de fois un mainteneur a-t-il passé des heures (étalés sur des jours, voire des semaines, donc avec en plus la perte de temps liée au fait de changer notre état mental d'un code à l'autre — context switch pour une analogie technique) sur une revue de patch en se disant que ça lui aurait pris 30 min pour le faire parfaitement soi-même?
Alors… dans ces conditions, pourquoi fait-on cela? L'une des raisons est pour provoquer la montée en compétence des autres contributeurs. Ils ne connaissent pas encore aussi bien la base de code que nous, ils sont peut-être aussi jeunes, etc. On les forme en quelque sorte. Cela veut dire aussi que c'est un investissement sur l'avenir car ce petit nouveau sera alors très efficace dans quelques semaines, puis encore plus dans quelques mois, et enfin quelques années.
L'IA, elle sera toujours aussi nulle. Elle ne monte pas en compétence. Donc en gros, on est coincé avec un débutant perpétuel qui fera toujours un code qui nous fera perdre notre temps. Or si ce gars estime que ce code de débutant qu'il doit à chaque fois relire, comprendre et réorganiser ne lui fait en fait pas perdre de temps… ben je me demande vraiment comment il code!
Je passe ensuite sur les propres hallucinations du gars quand il parle des hallucinations de l'IA en les balayant d'une main, ou sur son argument nul et à vomir quand il parle du stagiaire qui coûte plus que 20€ par mois (d'autant plus quand on sait que ce n'est même pas un business model viable et que les pris sont destinés à augmenter; là ils perdent de l'argent à tout va juste pour habituer les gens au produit en espérant les rendre suffisamment accros et dépendants pour qu'ils paient plein pot plus tard).
Je vais aussi passer tous les autres arguments (rust; j'ai déjà aussi parlé de son ode à la médiocrité; je ne m'étendrai même pas sur son balayage atroce d'un revers de main du problème de droit d'auteur, prétextant que les artistes, c'est différent 🙄 — ce qui tombe bien car il n'est pas artiste! Ni même vraiment développeur j'ai l'impression…).
Je vais juste faire un dernier point sur la section expliquant qu'on n'est pas des artisans. Ah bah voilà. Personnellement je me considère artisan du code. Le gars en gros t'explique que l'artisanat, c'est du hobbyisme:
Ben il a juste pas compris ce qu'est l'artisanat. L'artisan menuisier, c'est pas un gars qui fait des tables nulles sur lesquelles on peut pas travailler correctement (pour réutiliser son analogie)! Bien sûr, il peut y en avoir des bons et des moins bons. Mais le bon artisan menuisier, il vous fera une table de qualité qu'on peut garder sur des générations, qui sera belle en plus d'être utile, possiblement personnalisée à votre besoin en plus.
Mais oui, ça coûtera plus cher. C'est pour cela que les gens vont chez les industries qui font des tables à la chaîne. Mais de meilleure qualité? Sûrement pas! C'est le contraire en fait!
Mais c'est sûr que si on se considère comme un "travailleur à la chaîne" du code, qu'on se complaît dans la médiocrité de son résultat, voire limite qu'on en est fier, que la chose principale qui nous importe soit apparemment le bas coût de l'AI (avec une vision très court-termiste puisqu'il est connu — car ça a été publiquement dit par les entreprises de l'IA — que ces coûts actuels sont à perte), et qu'on s'en fout de la problématique écologique (cette problématique n'est même pas citée parmi les autres arguments, soit parce que le gars ne saurait pas comment la démonter — faut dire aussi que pour le faire, faut avoir une bonne dose de mauvaise foi —, soit parce que la problématique écologique ne pénètre même pas l'esprit des solutionnistes technologiques) alors oui peut-être dans ce cas, je peux comprendre qu'on trouve l'IA bien.
En gros, on a les mêmes arguments, mais pour des gens qui ont ce mode de pensée, alors ce sont des arguments positifs, et pour d'autres c'est bel et bien négatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cet article est une ode à la médiocrité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
J’aurais voulu plusser plusieurs fois <3
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Cet article est une ode à la médiocrité
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Plus précisément, il la fera en gaspillant un minimum de matériau. Ce qui est aussi une caractéristique de l'artisanat (le vrai, pas celui des youtubeurs et youtubeuses qui gâchent des tonnes de matières premières pour faire un truc plus ou moins merdique).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Cet article est une ode à la médiocrité
Posté par MicP . Évalué à 3 (+2/-0). Dernière modification le 04 juin 2025 à 19:52.
Celui qui sait choisir les différentes essences de bois qu'il faudra pour pouvoir fabriquer ou restaurer des tables ou autres meubles, c'est un ébéniste. On reconnait facilement un ébéniste car souvent, il lui manque un ou plusieurs doigts.
Le menuisier fera plutôt des charpentes, des portes, des fenêtres et le cadre qui servira à les tenir en place, des plinthes, etc. qui seront parfois en bois, ou en PVC ou en aluminium …(Les menuisiers menuisent car ils déposent des plinthes au parquet)
[^] # Re: Cet article est une ode à la médiocrité
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Dans certaines contrées les menuisiers sont aussi des ébénistes, ou l’inverse. Et il faut aussi choisir les essences de bois pour faire portes et fenêtres par exemple.
Question : quelle est la différence entre le menuisier et le charpentier ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Cet article est une ode à la médiocrité
Posté par Benoît Sibaud (site web personnel) . Évalué à 5 (+2/-0).
https://www.onisep.fr/metier/decouvrir-le-monde-professionnel/filiere-bois/les-metiers-et-l-emploi-dans-la-filiere-bois
Visiblement y a des vélléités de reconversion (*), alors « Découvrez des métiers de la filière bois »
(*) au moins un pote de ma promo d'ingé en informatique est désormais charpentier
[^] # Re: Cet article est une ode à la médiocrité
Posté par Thomas (site web personnel) . Évalué à 2 (+1/-0).
Voilà.
Bien envoyé \o/
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.