IA : l’incompétence accélérée
(slater.dev)- Une dépendance excessive aux LLM en ingénierie logicielle peut accroître la vitesse à court terme, mais affaiblir la pensée critique et la capacité de résolution de problèmes
- Plus que les sorties erronées, le risque majeur est d’accepter tels quels des prompts défectueux, ce qui accélère l’accumulation de dette technique et l’érosion des compétences des utilisateurs
- Les LLM ne peuvent ni mémoriser ni intérioriser une théorie du programme au-delà de leur fenêtre de contexte actuelle ; le modèle mental partagé nécessaire à la conception et à la maintenance reste donc du ressort des ingénieurs humains
- La complexité continue d’augmenter pendant la maintenance, et les LLM, simples prédicteurs de tokens au niveau du texte, peuvent accroître l’entropie du programme par des modifications inutiles ou étranges
- L’IA peut être utilisée comme un outil, mais ne doit pas devenir une béquille ; il faut continuer à investir dans les fondamentaux de l’ingénierie et dans la réflexion approfondie, comme en 2019
Les risques d’ingénierie créés par la dépendance aux LLM
- Qualifier les LLM d’« amis » relève moins d’un véritable compagnonnage que d’un euphémisme pour dire qu’ils apportent un bénéfice à l’utilisateur
- Les ingénieurs qui adoptent cette vision donnent généralement la priorité à la vitesse, ou subissent une pression pour la privilégier
- Les LLM peuvent produire beaucoup de code rapidement, mais leur usage s’accompagne d’une longue traîne de risques
Cinq risques visibles dans la génération de code
-
Risque de sortie
- Les LLM peuvent produire des résultats manifestement faux, comme du code qui ne compile pas
- Les cas plus dangereux sont les erreurs subtiles et difficiles à détecter, comme les bugs logiques
- Le risque augmente lorsque l’auteur du prompt n’est pas qualifié pour évaluer le résultat
- L’exemple donné est celui d’un chef de projet qui demande du code source
-
Risque d’entrée
- Les LLM ne contestent pas les questions orientées, les hypothèses erronées ou les prompts incomplets dans leur contexte
- Par exemple, à la demande « fournir une implémentation de liste thread-safe en C# », ils peuvent générer 200 lignes de code plausibles, alors que la vraie question est peut-être : « comment rendre ce code thread-safe ? »
- Dans ce cas, la réponse peut tenir en une seule ligne utilisant
System.Collections.Concurrent - Le LLM ne reconnaît pas ce cas de XY Problem, puisqu’on ne lui a pas demandé
-
Ralentissement futur
- Les LLM peuvent dégrader très rapidement la qualité d’une base de code
- Sans garde-fous solides, le code généré par LLM peut paraître correct en surface tout en devenant intérieurement un espace insalubre et non fonctionnel
- Cela est présenté comme un problème plus urgent que les discussions habituelles sur la dette technique
-
Infantilisation des utilisateurs
- Dans les individus et les organisations qui délèguent la réflexion et la résolution de problèmes aux LLM, le talent peut disparaître
- Les ingénieurs seniors peuvent voir s’affaiblir leur capacité de résolution de problèmes et leur pensée critique en perdant les occasions d’apprendre par l’effort productif
- Les ingénieurs juniors risquent de ne jamais développer ces compétences au départ, puis d’avoir du mal à accompagner les futurs juniors
- ThoughtWorks Technology Radar Volume 32 évoque des cas où la confiance fondée sur l’IA se fait au détriment de la pensée critique
- Coding as Craft: Going Back to the Old Gym insiste sur une collaboration délibérée avec l’IA pour préserver le code comme un artisanat
- Thoughts on Thinking estime que les LLM peuvent fournir une pensée achevée, mais pas la croissance intellectuelle qui vient du développement de sa propre pensée
-
Perte de plaisir
- Beaucoup de développeurs rapportent que l’usage de l’IA leur retire l’état de flow et le plaisir de créer
- Le code généré par IA peut devenir pénible à lire et à modifier
- L’article lié est The Hidden Cost of AI Coding
Deux compétences que les LLM ne remplacent pas
- Face à l’inquiétude selon laquelle les ingénieurs expérimentés deviendraient inutiles à cause de l’IA, deux capacités de programmation que les LLM ne fournissent pas sont mises en avant
- Ces capacités sont la théorie du programme et l’entropie du programme
Théorie du programme : le code n’est pas le programme lui-même
- Programming as Theory Building de Peter Naur considère la programmation comme une activité consistant à former une compréhension ou une théorie du problème
- Dans la perspective de Naur, le programme n’est pas le code source, mais une construction mentale partagée, autrement dit une théorie ou une conception
- Le code dérive de cette conception, mais la vraie valeur du produit se situe dans la conception plus que dans le code
-
Expérience de pensée avec deux équipes
- Deux équipes A et B, de même niveau, sont placées dans des pièces séparées sans communiquer
- L’équipe A écrit un programme, par exemple un jeu d’échecs en terminal, tandis que l’équipe B attend ou joue réellement aux échecs
- Une fois le travail de l’équipe A terminé, le code source est transmis à l’équipe B, et les deux équipes doivent ajouter une fonctionnalité comme un joueur d’échecs virtuel
- L’équipe la plus à même de produire la meilleure solution est l’équipe A
- L’équipe A dispose d’un modèle mental frais du programme qu’elle vient de créer
- L’équipe B ne possède pas ce modèle
- Comme un programme continue d’être modifié après sa création initiale, disposer uniquement du code source sans compréhension intériorisée de la conception augmente le coût du changement
- Cela renvoie à l’expérience familière d’une productivité proche de zéro en arrivant sur une grosse base de code existante, puis en hausse à mesure qu’on charge dans sa tête la théorie du programme
-
Les LLM et la théorie du programme
- Les LLM actuels ne se souviennent pas au-delà de leur fenêtre de contexte et ne peuvent donc pas maîtriser une théorie, une conception ou une construction mentale
- Les êtres capables d’acquérir et de maintenir une théorie du programme sont les humains
Entropie du programme : la capacité à réduire la complexité ou à lui résister
- La complexité est une force fondamentale à laquelle la programmation s’oppose, et elle est liée à l’entropie
- Dans The Mythical Man-Month, Fred Brooks décrit la construction d’un programme comme un processus de réduction de l’entropie, et sa maintenance comme un processus d’augmentation de l’entropie
- Dans la vision de Brooks, après la construction initiale, toute modification d’un programme tend inévitablement à rendre le code source plus complexe
- Toutefois, les changements en harmonie avec la conception peuvent ralentir cette hausse de complexité
-
Les LLM et l’entropie du programme
- Les LLM sont des prédicteurs de tokens et n’opèrent qu’au niveau du texte
- Les LLM ne raisonnent pas au niveau conceptuel des idées, des diagrammes ou des spécifications d’exigences
- Toute personne ayant injecté de gros blocs de code dans un LLM a pu constater sa tendance à appliquer des modifications inutiles et étranges
- Plus la conversation s’allonge, plus les résultats peuvent dériver
- La capacité à réduire la complexité du code ou à lui résister appartient aux humains
Comment utiliser l’IA en ingénierie
- Si l’on espérait que l’IA fasse passer une carrière d’ingénieur au niveau supérieur, elle peut au contraire produire l’effet inverse
- Les LLM peuvent accélérer l’incompétence, mais ne remplacent pas l’ingénierie humaine
- L’attrait économique de l’IA tient à la marchandisation de l’ingénierie pour en réduire les coûts
- Mais, tout comme le recours aux talents d’ingénierie offshore produit des résultats mitigés, les LLM s’accompagnent eux aussi de limites et de risques
- Le cycle de hype autour de l’IA peut finir par atteindre son sommet
- Les entreprises qui abusent aujourd’hui de l’IA devront assumer des coûts de long terme et pourront devoir changer de cap ou disparaître
- La proposition de valeur de long terme de l’humain en ingénierie ne change pas
- Le monde a toujours besoin de compétences techniques et de réflexion approfondie
- Et il continuera à payer pour ces compétences
- L’IA va rester, mais elle doit être utilisée comme un outil, pas comme une béquille
- Il faut continuer à investir dans les compétences fondamentales de l’ingénierie qui étaient déjà jugées précieuses en 2019
1 commentaires
Avis de Hacker News
Le débat sur le codage avec l’IA donne parfois l’impression de refléter la différence entre ingénieurs logiciel et data scientists/ingénieurs machine learning
Les deux gèrent des exigences floues et des bugs difficiles à cerner, mais, dans l’ensemble, les ingénieurs logiciel construisent des logiciels qui doivent toujours se comporter d’une certaine manière, où la reproductibilité, les tests et des outils matures sont importants
À l’inverse, les ingénieurs machine learning travaillent avec des modèles intrinsèquement probabilistes, et leurs tests sont centrés sur des métriques d’évaluation du type « sortie correcte dans 90 % des cas » plutôt que sur la production d’une sortie précise
Il est donc plus naturel, côté machine learning, d’adopter un état d’esprit consistant à composer avec une IA qui n’est jamais totalement fiable, et d’évaluer les assistants de codage en se disant : « c’est correct à 80 %, ça me fait gagner du temps, et je corrigerai les 20 % restants »
Quand je travaillais chez Amazon, les solutions fondées sur le machine learning convenaient souvent très bien à de vrais problèmes pour lesquels il n’existait pas d’approche classique. Par exemple, la prédiction de mouvement basée sur des cartes en grille, ou la classification d’images/cartes en grille, s’intégraient bien aux pipelines classiques d’estimation et de contrôle, et étaient utiles
À l’inverse, dans une startup, un manager subalterne n’arrêtait pas de me réprimander parce que je mettais en doute une approche fondée sur l’apprentissage pour estimer au fil du temps l’orientation d’un plan immobile. Comme l’équipe ne connaissait pas les bases de la cartographie ou du filtrage et supposait que « rajouter plus de données » résoudrait le problème, tout le pipeline de contrôle du véhicule ingérait des estimations de rotation arbitraires qui clignotaient et sautaient
Cet écart est vraiment important, et j’aimerais qu’on dispose de meilleurs moyens de le détecter en entretien
J’ai un jour entendu l’architecte senior de notre entreprise se plaindre après une réunion : pour notre produit, l’exactitude et la justesse avaient toujours été de grands arguments de vente, mais l’équipe machine learning d’un autre bureau ne le comprenait pas et considérait qu’une précision de 80 à 90 % suffisait pour les clients
Cela me rappelle le débat sur le taux de létalité de 1 % d’une maladie pandémique : est-ce faible ou élevé ? 1 est le plus petit entier, mais 1 % de 300 millions de personnes, cela fait 3 millions
Mais je ne pense pas que ce soit tout ce que dit cet article. Il traite des préoccupations de méta-niveau des personnes qui font de l’ingénierie logicielle et de la manière dont l’IA s’y insère, et je pense qu’il touche juste lorsqu’il parle d’« entropie des programmes »
Une grande partie de la création de produits logiciels consiste à gérer l’entropie. Il faut augmenter le code et les effectifs tout en conservant un rythme d’avancement correct, et faire en sorte que tout le monde comprenne comment les morceaux s’emboîtent et comment en ajouter de nouveaux. Un jour, l’IA rendra peut-être cela plus facile, mais pour l’instant elle aggrave souvent l’entropie
Ce ne serait pas un gros problème si des personnes ayant des intérêts en jeu n’essayaient pas de nous convaincre que « si, l’IA peut être utilisée immédiatement pour tout »
Cette hypothèse est si absurde qu’il est presque difficile de la réfuter par la logique, et jusqu’ici elle a très bien fonctionné comme récit fondé sur la croyance pour attirer d’énormes investissements et habiller des optimisations d’effectifs centrées sur le profit
Je suis fortement d’accord avec le postulat de l’article et avec la plupart de ses arguments concrets, mais j’utilise des LLM au quotidien et j’en vois aussi les aspects positifs. Pour référence, cela fait environ 30 ans que je travaille dans l’industrie du logiciel
Avec du code généré par IA, on se met à lire du code. Le développement ressemble moins à un parcours de création à partir de zéro qu’à une série de revues de code, et pour un développeur solo, cela a l’avantage de lui faire imiter et apprendre des responsabilités qu’il est généralement plus facile d’acquérir en équipe
Travailler avec un LLM fait aussi rapidement apparaître que le développeur doit comprendre le problème sous forme de couches claires et bien structurées. Si on lui demande une grosse chose d’un coup, on finit généralement par se tirer une balle dans le pied ; l’aborder sous l’angle de la conception, rédiger des spécifications détaillées et implémenter par parties aide donc à définir les frontières et les interfaces des blocs conceptuels
On peut voir les LLM comme un puissant accélérateur aidant les développeurs juniors à évoluer vers un rôle senior. Avec un guidage approprié, ils exposent le cheminement des leçons que des personnes plus expérimentées ont appris avec le temps. Je ne vois pas tout en noir, je ne pense pas non plus que l’IA remplacera les développeurs ; elle est très disruptive aujourd’hui, mais elle finira probablement par trouver sa place quelque part parmi les autres outils
Quand on relit du code produit avec l’aide d’un LLM, on peut dire qu’on lit du code plus fade, mais je pense qu’on apprend quand même. J’ai lu beaucoup de code généré par LLM, et j’y apprends souvent des idiomes que je ne connaissais pas ou des appels à des bibliothèques que j’ignorais
Pour les développeurs seniors aussi, les LLM sont un accélérateur plus puissant. Comme ils savent ce qui existe et ce qu’il n’est pas utile d’essayer, ils peuvent mieux prompter
Il suffit de regarder l’actualité récente : les licenciements se poursuivent dans les Big Tech, les entreprises technologiques de taille moyenne et les petites entreprises tech
Vous vous souvenez de l’époque où l’on disait que l’impression 3D allait remplacer toute la fabrication ?
L’IA est plus proche de cet état d’esprit que de la singularité
On peut aussi considérer que les LLM n’ont pas tant amélioré les choses qu’ils ont révélé des failles systémiques, mais l’impact lui-même est évident. Des dizaines de déroulés de cours qui étaient standard il y a deux ans ne fonctionnent plus
Cela inclut en particulier l’ensemble de l’enseignement en ligne et à distance ; ironiquement, ChatGPT est arrivé précisément au moment où beaucoup d’universités commençaient à y investir après le Covid. C’est un impact à l’échelle de tout l’enseignement supérieur et secondaire dans le monde
L’aérospatiale en est un bon exemple. Une grande partie de ce que font SpaceX et les jeunes entreprises de ce secteur n’aurait pas été possible sans pièces imprimées en 3D. Des pièces comme les tuyères, les chambres de combustion et les turbopompes sont souvent imprimées
Cela dit, la comparaison ne me semble pas juste. Quand je faisais du génie mécanique, l’impression 3D m’a plutôt rendu meilleur ingénieur, parce qu’elle permettait de prototyper et de se tromper plus vite et à moindre coût
Elle n’a pas remplacé toute la fabrication, mais elle joue un rôle important dans la conception, et elle n’a pas fait régresser les compétences de ses utilisateurs
Les LLM sont étonnants pour écrire du code, mais très mauvais pour en être propriétaires et le maintenir
Chaque ligne acceptée sans compréhension est une compréhension empruntée, que l’on rembourse avec de gros intérêts lors de la maintenance. Cela donne l’impression d’une vitesse gratuite, mais en réalité c’est plutôt une dette technique avec quelque chose comme 40 % d’intérêt annuel
En tant que collectif, nous devons trouver comment automatiser la saisie avec l’IA sans automatiser la pensée
Or ce n’est pas le cas, et son fonctionnement ne le permet pas
Donc chaque ligne produite par un LLM et acceptée sans compréhension relève en réalité d’une compréhension inexistante. Ce n’est qu’une ligne de code crachée par un modèle probabiliste, et elle reste non comprise tant qu’un être capable de comprendre réellement le contexte, le système et la conception de la base de code ne l’a pas examinée. À ce jour, les seuls êtres connus dans ce rôle sont les humains
Dans le développement traditionnel, je n’aime pas particulièrement l’un ni l’autre, mais les LLM actuels rendent les deux plus faciles et plus utiles
Et la « règle de trois » cesse pratiquement de s’appliquer entre composants. L’impact du code doit soit rester localisé, soit faire partie d’une bibliothèque de base très robuste. Les cas intermédiaires font exploser la complexité du refactoring
« Les LLM ne contestent pas les prompts orientés » : ce risque lié à l’entrée a été jusqu’ici la plus grande source de douleur
Ce qui est encore plus frustrant, c’est qu’on peut même ne pas se rendre compte qu’on oriente les choses dans une certaine direction. Vu le fonctionnement des LLM, cela se tient, mais un seul mot formulé de façon ambiguë peut faire dévier le résultat dans une mauvaise direction, l’envoyer à l’opposé de ce que je voulais et l’entraîner dans un mauvais terrier de lapin
Quand on s’en rend compte, on se retrouve au milieu d’un bourbier de code bricolé tant bien que mal, qui fonctionne à peu près. Le langage humain est très ambigu et peu spécifique ; c’est presque pour cela qu’on a inventé des langages formels régis par des règles, qui permettent la précision dès le départ
Personnellement, j’ai aussi eu l’impression que mes compétences régressaient rapidement à cause des outils d’IA. À une époque, par paresse, je me tournais vers l’IA pour la moindre petite tâche, mais en prenant du recul, je n’ai pas vraiment gagné de temps ; au contraire, je me suis épuisé beaucoup plus vite à lire des dizaines ou des centaines de lignes de code, à comprendre en quoi l’IA s’était trompée et à corriger
Je ne l’ai pas mesuré, mais globalement j’ai l’impression d’avoir perdu beaucoup plus de temps avec les outils d’IA que je n’en ai gagné
Le vrai problème, c’est que l’IA est effectivement utile pour beaucoup de tâches, mais que ses utilisateurs se répartissent en deux catégories. D’un côté, ceux qui l’utilisent pour des tâches complexes où de petites erreurs s’accumulent rapidement ; de l’autre, surtout des profils de managers, qui voient l’outil cracher 200 lignes de code qu’ils ne comprennent pas, considèrent qu’une appli TODO qui fonctionne à peine est un « MVP », et se disent : « puisque je peux faire ça, ton travail doit aussi être facile »
Si vous voulez répondre par les classiques « tu l’as mal utilisée » ou « le modèle s’est trompé », j’aimerais que vous lisiez d’abord cet ancien commentaire, qui donne le contexte de mon expérience avec ces outils : https://news.ycombinator.com/item?id=44055448
Autrement dit, l’IA est mon assistante, mais la responsabilité de produire un résultat de qualité et maintenable m’incombe
Cela dit, du point de vue du grand public, il suffit de penser à une simple calculatrice. La calculatrice a abîmé la capacité des gens à faire du calcul mental. L’IA fera la même chose avec l’écriture, la communication, la résolution de problèmes, etc.
Les modèles semblent s’accrocher à certains mots-clés quelque part dans le fil du prompt, abandonner la logique traditionnelle et vous pousser dans une voie plus étroite qui ne résout même pas correctement le problème initial. Au bout du compte, cela ne fait qu’accroître la frustration et le malheur côté humain
Pour éviter que mes compétences ne régressent, j’essaie de n’utiliser l’IA que pour de petites tâches bien définies que j’aurais auparavant résolues avec une recherche StackOverflow. Au lieu de chercher « comment faire X ? », je pose la même question au modèle et j’utilise sa réponse comme un guide de résolution, pas comme la vérité
Cela dit, il y a bien des choses que l’IA rend plus faciles aujourd’hui. Par exemple, quand on a un exemple du type « fais comme cette page, mais avec les données x au lieu de y », c’est souvent plus rapide que de chercher la documentation. Avec la réserve qu’elle peut halluciner, mais il y a de fortes chances que cela s’améliore avec le temps
L’amélioration que j’aimerais voir, en plus d’une plus grande exactitude générale, c’est qu’elle cherche la solution la plus simple sans qu’on ait à le préciser à chaque fois. Le principal défaut quand on lâche ChatGPT, Claude, etc., c’est qu’ils produisent très vite beaucoup de déchets et ne s’arrêtent pas en disant : « ça deviendra trop compliqué à gérer plus tard ». Le texte original affirme que seul un humain comprenant la conception d’ensemble peut résister à l’entropie ; je ne sais pas si ce point ne s’améliorera jamais, mais c’est ce qui me semble aujourd’hui le plus gros problème
Au premier tour, les principales hypothèses que le modèle est en train de faire apparaissent généralement, et on peut ensuite les resserrer et les clarifier
En lisant ton ancien commentaire indiquant que tu avais tenté plusieurs approches, ton expérience des LLM m’a paru bien plus large que la mienne. Mais je n’y ai pas vu cette technique, donc je la laisse ici au cas où elle aiderait quelqu’un
Des affirmations comme « il ne peut pas raisonner à partir d’idées, de diagrammes ou de spécifications d’exigences » ou « seuls les humains peuvent réduire la complexité » ressemblent à des détails manifestement faux accolés à un concept intéressant
C’est très facile à faire. Il suffit de demander du code plus simple. Je l’utilise souvent pour obtenir un second avis, avec de bons résultats
Si on n’interroge pas le modèle, on n’obtient ni réponse complexe ni réponse simple. Interroger le modèle avec les options par défaut est aussi un choix ; ce n’est pas inhérent au concept même de LLM
Je m’en sers aussi très bien pour convertir du code en idées ou diagrammes, et inversement. Je ne comprends pas pourquoi certains avancent des affirmations fortes que des gens réfutent chaque jour en pratique
Le texte répète aussi un raisonnement étrange qui semble correct en surface, mais ne tient pas quand on l’examine de près. L’histoire de Naur est désormais devenue un mème, répété dans le monde réel comme une intuition, mais elle oublie une autre règle fondamentale et pratique du génie logiciel : tout programme non trivial finit rapidement par dépasser la capacité d’une seule personne à garder toute sa théorie en tête
Nous travaillons rarement avec une théorie vraiment complète du programme. Les langages de programmation, techniques, méthodologies et outils ont tous évolué pour permettre aux gens de mieux travailler sans comprendre la majeure partie du code
Sur ce point, les humains partagent les mêmes limites que les LLM ; nous nous en sortons simplement mieux parce que nous n’avons pas besoin d’attendre qu’une nouvelle boucle d’inférence nous soit accordée pour obtenir un autre point de vue
Je pense qu’on peut appliquer une logique similaire aux technologies de cartographie comme Google Maps ou Apple Maps. L’argument est que ces outils font régresser notre capacité à nous orienter dans le monde physique, notre sens de l’orientation et notre sens géographique.
Ce n’est pas complètement faux. Aujourd’hui, beaucoup de gens ont du mal à trouver leur chemin sans une béquille comme Google Maps, et notre relation au monde physique a changé à bien des égards.
Mais autrefois aussi, beaucoup de gens n’étaient pas particulièrement doués pour s’orienter. En particulier, la capacité moyenne à aller de manière sûre et fiable d’un point A à un point B dans une zone inconnue a clairement beaucoup augmenté.
Et pour la minorité de personnes naturellement douées en géographie et en orientation, des outils comme Google Maps n’ont pas remplacé leurs capacités, ils les ont complétées.
Je pense que l’IA finira de façon similaire, mais à plus grande échelle. Il y aura évidemment des compromis, et certaines compétences et capacités diminueront, mais beaucoup plus de gens pourront faire des choses qu’ils ne pouvaient pas faire auparavant, et une minorité fera encore mieux ce qu’elle faisait déjà.
Bien sûr, ce n’est pas toujours le cas. Cartographier le monde entier est une tâche extrêmement complexe, avec d’innombrables exceptions et cas limites. Mais la différence est énorme par rapport aux sorties des LLM. Même avec une température à 0, régénérer plusieurs fois le même prompt peut produire des sorties très différentes.
En outre, les LLM couvrent un champ conceptuel bien plus large, si bien que les gens les utiliseront à la place de leur propre tête dans beaucoup de situations où ils ne devraient vraiment pas le faire. Rien qu’avec les cartes, il y a déjà des gens qui conduisent dans un lac parce que Google Maps indique que c’est une route ; je n’ose même pas imaginer ce qui se passera quand ils feront aveuglément confiance aux sorties des LLM et remplaceront leur propre réflexion par celles-ci.
Là où j’habite, Google Maps est meilleur qu’un chauffeur de taxi dans 90 % des cas.
L’IA n’est même pas meilleure que quelqu’un qui a fait ce travail pendant quelques jours.
En réalité, 70 % des employés font leur travail tellement à la va-vite que l’IA fait souvent aussi bien, voire mieux.
La vraie difficulté, c’est que les gens qui faisaient déjà les choses à la va-vite restent inutiles même avec l’IA, tandis que les autres apprennent et progressent avec elle.
La conduite entièrement autonome, c’est un peu pareil. Le FSD est meilleur qu’un conducteur humain nul, ivre ou en train d’envoyer des SMS, et il y en a beaucoup sur les routes.
Je me demande d’où vient l’impression de l’auteur selon laquelle « [l’IA] ne peut pas travailler au niveau conceptuel ».
Ce que les LLM récents ont démontré à maintes reprises, c’est qu’ils peuvent clairement travailler au niveau conceptuel, par exemple en traduisant correctement, selon le contexte, les concepts d’une langue vers une autre.
Dire qu’ils ne « comprennent » pas les concepts comme les humains est une autre question. Ils ne peuvent sans doute pas « comprendre » la douleur puisqu’ils ne l’ont pas vécue, mais les humains parlent sans cesse de choses qu’ils n’ont pas vécues directement. Savoir si c’est légitime est un autre sujet.
C’est un modèle faible de certaines caractéristiques des concepts, comme l’association. Par exemple, « dog » est associé à « cat ». Mais cela ne modélise pas la compositionnalité, l’intension, ni le rôle que jouent les termes dans les conditionnels contrefactuels.
Cela dit, si la question ressemble aux données d’entraînement, on peut obtenir à la force brute une apparence de capacité conceptuelle. Si quelqu’un a posé une question comme « les chiens seraient-ils heureux s’ils jouaient sur Mars ? », ou un ensemble de questions suffisamment similaires, on peut placer « dog » près du cluster des « faits littéraux » et de clusters de contrefactuels déjà connus.
Pour voir la différence entre cela et de véritables capacités mentales, il suffit de constater que les combinaisons conceptuelles de profondeur arbitraire sont infinies et peuvent être constituées d’un nombre infini de contrefactuels. Un enfant qui ne dispose que des briques de base et de son imagination peut évaluer cette diversité infinie.
C’est pourquoi les LLM sont surtout utilisés dans des domaines étroits où le « travail conceptuel » nécessaire est très bien documenté et suffisamment stable, en particulier le génie logiciel.
Je suis de plus en plus tenté de transformer 90s.dev en une communauté sans IA. Un endroit centré sur l’art ancien de bien écrire du logiciel, et ouvert à tous ceux qui ont poli cet art.
Par quoi faudrait-il commencer ? Un forum ? Une liste de diffusion ? Un agrégat de blogs multi-auteurs à la façon de hackernoon ?
J’ai créé une liste de diffusion temporaire pour les personnes intéressées sur https://github.com/sdegutis/90s.dev/issues/2 ; pour recevoir les e-mails sur ce sujet, il suffit de s’abonner ou de commenter.
Les forums ont été ruinés par les LLM et les bots, donc cette option est exclue. Pour que ce genre de chose fonctionne, il faudrait que ce soit sur invitation uniquement, et que chaque personne qui recommande quelqu’un soit responsable de son arbre d’invitations.
La communauté doit être suffisamment précieuse pour que perdre l’accès incite à bien se comporter. Dans certaines communautés en ligne, ce modèle fonctionne très bien.