Tout ce qui entoure les LLM reste encore de l’ordre de la magie et de la pensée optimiste
(dmitriid.com)- Les récits de réussite autour des outils LLM omettent souvent des critères de comparaison comme les conditions du projet, l’expertise de l’utilisateur ou le volume de travail de suivi, ce qui rend leur utilité réelle difficile à évaluer
- Dans les discussions sur MCP, l’usage d’outils et les agents, la tendance à faire passer les critiques pour des gens qui « n’ont pas regardé assez en profondeur » rappelle les anciens débats sur la crypto
- Les LLM et les agents sont non déterministes : même pour un même problème, il est difficile de considérer qu’une méthode qui fonctionne maintenant fonctionnera encore à l’identique une minute plus tard
- La célèbre déclaration selon laquelle Claude Code « gère des bugs legacy » a aussi récolté 1,8 k likes et 204 repartages, sans préciser la taille de la codebase, le type de bug ni la manière dont le travail a été encadré
- Même du point de vue de quelqu’un qui a réellement utilisé plusieurs outils, les LLM ressemblent davantage à des machines statistiques non déterministes et, même s’ils peuvent sembler magiques quand ils fonctionnent, il est difficile d’affirmer qu’ils relèvent de la magie ou de l’ingénierie
Pourquoi il est difficile de comparer les retours d’expérience sur les LLM
- Les expériences positives comme négatives sur les outils LLM sont généralement partagées sous forme de fragments isolés, ce qui rend difficile de vérifier si tout le monde parle bien des mêmes conditions
- La nature du projet et de la codebase est souvent absente
- On ne sait pas clairement s’il s’agit d’un projet greenfield, d’une codebase mature ou d’une codebase propriétaire
- L’expertise de l’utilisateur est elle aussi difficile à comparer simplement
- On ne sait pas si cette expertise s’applique au même domaine, à la même codebase ou au même langage
- Le volume de travail supplémentaire nécessaire — revue, corrections, déploiement, finalisation — a aussi une grande influence sur l’évaluation
- Même si une personne fournissait toutes ces informations, la comparaison entre expériences resterait limitée tant que les conditions des autres ne sont pas connues
- À cela s’ajoute la non-déterminisme des systèmes LLM et des agents
- Même pour le même problème, on ne peut pas supposer qu’une méthode efficace maintenant le sera encore une minute plus tard
- L’expérience d’un ingénieur senior sur un projet React greenfield et celle d’un designer non développeur sur une codebase propriétaire en OCaml deviennent encore plus difficiles à comparer si le modèle et l’agent changent
- Même avec le même modèle et le même agent, les résultats peuvent varier d’une exécution à l’autre, ce qui complique les comparaisons simples
L’écart entre le discours surchauffé et l’usage réel des outils
- Les réactions qui traitent les critiques des LLM comme des personnes qui « n’ont pas suffisamment vu MCP et les outils » montrent la surchauffe du débat sur l’IA
- Parmi les exemples d’« industry leaders », on cite la déclaration de Steve Yegge à propos de Claude Code
- Il y affirme que Claude Code a attaqué avec vigueur pendant plusieurs jours des bugs legacy dans une ancienne codebase
- On y trouve aussi l’idée que Claude Code avance sans qu’il soit nécessaire de sélectionner soi-même le contexte
- Il y est également question d’un enchaînement allant jusqu’au déploiement en production et à la vérification des logs utilisateurs, tant que les validations bancaires continuent
- Mais là aussi, les informations nécessaires au jugement manquent
- La taille de la codebase n’est pas connue
- On ne sait pas de quels bugs il s’agit
- On ignore s’il y a eu une supervision supplémentaire
- Le langage de programmation et le framework ne sont pas précisés
- Malgré cela, cette déclaration a obtenu 1,8 k likes et 204 repartages
- Les sceptiques et les critiques n’évitent pas pour autant ces outils
- Il existe un side project entièrement conçu avec v0 de Vercel
- Une app de monitoring SwiftUI a été créée avec Claude Code sans connaître Swift au départ
- Des affiches d’événement ont été créées avec Midjourney
- Un serveur MCP a été vibe-codé en Elixir, sans utiliser phoenix.new
- L’expérience d’usage réelle se résume à peu près ainsi : « ça ne fonctionne qu’à 50 %, et seulement la moitié du temps »
- Les LLM sont des machines statistiques non déterministes et, même s’ils peuvent sembler magiques quand ils fonctionnent, ils ne sont ni de la magie ni de l’ingénierie en soi
- Le discours sur les LLM tend pourtant à ne les traiter que comme l’un ou l’autre
1 commentaires
Avis sur Hacker News
C’est frustrant que la direction de mon lieu de travail entende parler de choses comme une multiplication par 10 de la productivité. Certaines de ces affirmations viennent aussi d’early adopters en interne.
Mais les attentes sont devenues beaucoup trop élevées. L’une des raisons est la loi d’Amdahl : en réalité, je passe beaucoup plus de temps à réfléchir et à communiquer avec les autres, qui sont les clients de mon code, qu’à coder. Même si le codage devenait 10 fois plus rapide — ce qui n’est généralement pas le cas —, la productivité globale ne s’améliorerait que d’environ 10 à 15 %. Ce n’est pas négligeable, mais ce n’est pas un facteur 10.
Travailler sa réflexion avec un LLM me rappelle la sensation que j’ai eue quand j’ai appris à utiliser la recherche web il y a plus de vingt ans. Les moteurs de recherche rendaient l’accès à l’information possible quand on savait ce qu’on cherchait ; désormais, les LLM aident à déterminer ce qu’il faut chercher au départ, et font même la recherche. Des tâches que je classais autrefois comme difficiles à cause de l’effort et de l’incertitude deviennent triviales.
Aujourd’hui, je fais environ un tiers de mes recherches web avec ChatGPT o3, et il me serait désormais difficile de m’en passer.
Il y a aussi un effet psychologique : cela aide à structurer des idées encore immatures et sert de rubber duck. Beaucoup de tâches paraissent ainsi beaucoup moins pesantes, et cela suffit déjà à faire une grande différence.
Donnez à un senior un workflow LLM bien réglé, et il ne serait pas surprenant qu’il soit aussi productif que 10 juniors d’avant les LLM. Et comme un mauvais développeur peut même faire perdre du temps à un senior et rendre la productivité négative, dans ce cas on se rapproche d’un multiplicateur infini.
Même les juniors corrects sont généralement cantonnés à des tâches répétitives de bas niveau, et les LLM savent déjà mieux les faire.
Je comprends donc l’idée que des emplois puissent réellement disparaître.
La vague IA me rappelle le mouvement du début des années 2000 qui voulait externaliser massivement à l’étranger les ingénieurs logiciel. Il y avait d’énormes attentes chez les dirigeants et, sur le papier, cela semblait plausible, mais la plupart de ces initiatives se sont soldées par de gros échecs, et presque tous les emplois sont revenus aux États-Unis.
Beaucoup de gens ignorent que les ingénieurs logiciel accomplissent une multitude de petites tâches qui maintiennent l’ensemble cohérent. C’est précisément ce qui manque largement à l’IA. Je ne dis pas que les étrangers n’en sont pas capables, mais les barrières linguistiques, les décalages horaires, les différences culturelles, etc., ont créé des problèmes similaires. La qualité du code et sa maintenabilité se sont effondrées, et une grande partie de ce que les prestataires d’externalisation avaient produit a dû être jetée.
Je vois déjà des résidus d’IA s’accumuler dans les bases de code sur lesquelles je travaille. Il est très difficile de repérer ce genre de choses quand elles passent en revue de code, parce qu’en diff elles ont l’air raisonnables. Le problème, c’est le code dupliqué invisible et les abstractions bizarres qui, vues à un niveau plus élevé, n’ont absolument aucun sens.
Je fais partie exactement de la catégorie dont l’auteur se plaint. Depuis l’époque où il n’y avait que ChatGPT et où ses performances n’étaient pas terribles, j’ai lancé des produits greenfield non triviaux. Au début, j’utilisais Claude en copiant-collant entre le chat web et XCode, puis j’ai découvert Cursor
Cursor laissait beaucoup d’erreurs de build pénibles, mais la productivité était quand même au moins multipliée par 3. Maintenant que les agents se sont améliorés et que Claude 4 est sorti, je n’écris presque plus de code moi-même, et ça ne me déplaît pas. Je penche davantage vers un rôle d’architecte/manager, et quand c’est nécessaire je dirige l’agent avec mon expertise
Cela fait quelques mois que j’ai rejoint une startup exigeante, mais je n’ai toujours pas écrit une seule ligne de code à la main. Avant de créer une PR, j’audite tout moi-même et je teste rigoureusement, mais Cursor + Sonnet est vraiment absurdement puissant sur cette codebase. Pas selon des métriques dénuées de sens comme le nombre de lignes de code, mais parce que, même quand des experts de cette codebase arrivent avec des bugs étranges, moi qui viens d’arriver dans ce domaine, je peux les cerner en 5 à 30 minutes ; à ce titre, je suis convaincu d’être l’employé le plus productif
Même le travail de développeur frontend, que j’avais évité toute ma carrière, j’ai dû m’en détacher après avoir corrigé grâce à Claude de petits problèmes visibles. Ce n’est pas du vibe coding : il y a une procédure d’enquête, de planification, d’exploration prudente, et une façon de préparer le terrain pour que l’agent réussisse. Il faut aussi une connaissance du domaine. Mais je suis vraiment étonné que certains n’arrivent pas à en tirer la même utilité, et j’ai l’impression de voir deux articles comme celui-ci chaque semaine
Tu racontes une histoire difficile à croire sans partager la moindre preuve. Tu as même créé un compte jetable pour rendre impossible la vérification de ton identité et de tes affirmations
Du coup, ça ressemble à une blague
Cela ne veut pas dire que le besoin de curation disparaît. Cela reste mon rôle, et c’est aussi une partie de ce que le doctorat doit enseigner. Savoir traiter de manière précise et réflexive pourquoi on fait X, ce que l’on veut montrer avec Y, et découper chaque étape pour l’expliquer à quelqu’un d’autre, est une énorme soft skill. Comme les agents n’ont pas de modèle du monde persistant et qu’ils oublient vite l’objectif de l’interaction, même avec une compression intelligente, c’est aujourd’hui encore plus important
Quand je communique précisément, je peux utiliser Claude Code pour organiser des travaux de calcul d’une manière qui était impossible auparavant
Si l’on se soucie de la qualité, ce n’est pas plus facile que la programmation, mais c’est différent, et cela demande d’autres idiomes
Là où les agents sont vraiment utiles, c’est pour les grands refactorings mécaniques. Au lieu de me prendre la tête à concevoir une macro vim parfaite ou un script de réécriture d’AST, je le confie à l’agent
En moyenne, tes prompts font quelle longueur, et les tests unitaires sont-ils aussi écrits par le LLM ?
Personnellement, je pense que tu enjolives beaucoup trop l’expérience
Personnellement, je ne comprends pas bien cette idée.
Une quantité énorme du travail dans le secteur des services, partout dans le monde, revient en pratique à du déplacement manuel de données d’une feuille Excel à une autre, ou d’un CRM/e-mail vers Excel. Dans presque toutes les grandes entreprises, il y a des centaines, voire des milliers de salariés à temps plein qui font cela tous les jours, et une bonne partie est externalisée. À mon avis, pour 1 ingénieur logiciel, il doit y avoir 100 personnes qui font ce travail de pipeline de données manuel.
Donc les LLM n’ont pas besoin d’être extraordinairement bons en OCaml pour créer énormément de valeur. Il leur suffit d’être un peu meilleurs que les humains dans Excel. Là où MCP peut vraiment aider, c’est qu’il permet de connecter facilement ces systèmes. Beaucoup d’erreurs dans ce type de tâches viennent du fait qu’on essaie de mettre toute l’opération en contexte d’un seul coup. Si, avec MCP, on peut récupérer des e-mails, en extraire les données, puis les insérer ligne par ligne dans un CRM à nouveau via MCP, d’après mon expérience le taux d’hallucination est très faible. Au minimum, on atteint le niveau d’un junior surmené.
C’était peut-être d’ailleurs le propos du texte, mais dans ce type de cas d’usage, le non-déterminisme n’est pas un problème. Parce que les personnes impliquées ne sont pas déterministes non plus. On peut créer des systèmes et des processus qui imposent de la qualité à des systèmes non déterministes, par exemple des systèmes humains.
Enfin, j’ai suivi de près aussi bien les cryptomonnaies que les LLM, et en termes d’utilité et d’adoption, les deux ne me semblent pas comparables. Ce qui s’en rapproche le plus, c’est l’adoption des smartphones. Quand l’iPhone est sorti, beaucoup de mes amis non technophiles disaient ne pas avoir besoin d’un smartphone, mais en quelques années, ils en avaient tous un. Les LLM, c’est pareil. Aujourd’hui, presque tous mes amis non technophiles les utilisent pour des usages très variés.
Cela dit, la réaction sociale relève bien d’un courant de culte technologique, et beaucoup d’ingénieurs qui en ont vu passer pendant longtemps peuvent légitimement en être fatigués. Les affirmations irréalistes sont faciles à trouver, et les pires viennent des CEO d’entreprises d’IA.
En même temps, énormément de gens sont en pratique illettrés en informatique. Pour des personnes qui n’ont presque jamais été exposées ne serait-ce qu’à l’automatisation de base, on peut imaginer à quel point cela peut sembler excitant. L’« ordinateur qui parle » que nous avons l’habitude de voir dans la SF est en train de devenir presque réel.
Il y a quelques années, avant l’IA, je faisais du machine learning et du traitement automatique du langage naturel, et ce qui frappe le plus, c’est que ce domaine est devenu bien plus grand public que tout ce qui s’y était passé auparavant. Cela signifie aussi qu’il y a beaucoup plus de gens qui manquent d’expérience dans la conception fondée sur l’inférence statistique. Pendant un moment, ce sera le Far West, qu’il s’agisse d’opinions, d’implémentations réussies ou d’idées de projets réalistes à apprendre.
Voyez les choses comme ça : désormais, quand un ami arrive avec une idée d’appli digne d’un roman, on peut lui dire de la construire lui-même. C’est au moins bénéfique pour tout le monde.
Il peut aussi y avoir une part d’investissement émotionnel dans l’entreprise : l’instinct de survie pour ne pas se faire licencier, l’ambition de mieux faire, l’éthique et le jugement nécessaires pour signaler par d’autres canaux un manager problématique.
Un LLM ne va pas appeler un autre nœud de l’organisation pour vérifier quand il voit qu’une valeur semble étrange pour des raisons hors contexte. Par exemple, une situation où hier était un jour férié bancaire exceptionnel et où la valeur devrait donc être 0. Garantir l’exactitude de ces chiffres peut valoir le salaire annuel d’un salarié à temps plein. Et le fait d’avoir quelqu’un à blâmer, licencier ou envoyer en prison quand ils ne sont pas exacts a aussi de la valeur.
Ce qui pouvait vraiment être automatisé l’a déjà été. Je pense bien que l’IA va provoquer de grands bouleversements, mais je suis très sceptique face à l’idée que la plupart des emplois de cols blancs seraient des « métiers de l’e-mail » ou de la saisie de données. Cela ne correspond pas à mon expérience, y compris dans de grandes entreprises bureaucratiques que les gens d’ici qualifieraient volontiers de bloquées dans le passé.
Programmeur à la retraite. J’ai du mal à imaginer faire confiance à du code généré probabilistiquement dans un système critique. Si c’est presque juste et qu’il ne faut que de petites corrections, je peux comprendre, mais je n’en ai pas fait l’expérience directement.
Mon point principal, c’est que les LLM sont étonnants dans les domaines qui ne relèvent pas du code, par exemple le brainstorming, l’idéation libre, le fait de compléter des détails de recherche, ou de poser des questions qui me poussent à prendre du recul. Je traite les LLM comme des partenaires de réflexion. Ils se trompent, mais on peut facilement le repérer en vérifiant avec d’autres sources, ou en demandant à un autre LLM de passer leurs conclusions en revue.
En moins de 24 heures, j’ai construit quelque chose qu’il m’aurait fallu des mois rien que pour démarrer, et encore plus longtemps pour arriver à une version aussi aboutie que maintenant. Le plus impressionnant, c’est que cela fait plus vite ce que je sais déjà faire. Ce qui l’est encore plus, c’est que cela fait aussi des choses que je ne pouvais absolument pas faire moi-même, et pour lesquelles j’aurais dû recruter ou sous-traiter, avec beaucoup moins d’argent et de temps, et avec un rythme d’itération plus rapide que si je devais communiquer avec une autre personne.
Ce n’est pas parfait, et c’est parfois incroyablement frustrant. Il lui arrive de hardcoder des valeurs alors que je lui ai explicitement dit de ne pas le faire, ou de mentir en disant avoir appliqué une correction précise alors qu’en réalité il a modifié tout autre chose, sans rapport. Malgré cela, à mon avis, c’est un game changer.
En particulier, quand on essaie d’extraire des connaissances dans un domaine nouveau pour soi, il est facile et dangereux d’être induit en erreur par un LLM. Avec un moteur de recherche classique, on peut regarder les sites sources et juger de leur fiabilité, mais avec un LLM il n’y a pas ça. La sortie peut en pratique être n’importe quoi, et je ne suis pas d’accord avec l’idée qu’on peut forcément repérer facilement les erreurs.
Bien sûr, je vérifie le code produit, mais je suis presque tous les jours surpris par leur intelligence et leur précision. Cela n’a rien à voir avec les cryptomonnaies.
Si vous utilisez les sorties d’un LLM sans esprit critique, vous l’utilisez mal ; mais si vous utilisez les productions humaines sans esprit critique, c’est tout aussi mauvais.
Cela dit, les LLM ne sont pas magiques, et je crains que les gens ne s’en servent, via copilot ou des modèles d’agents, pour masquer de mauvaises pratiques d’ingénierie, et qu’à long terme ils empilent davantage de boilerplate au lieu de se concentrer sur l’efficacité, la sécurité et les refontes importantes.
Le problème, c’est qu’il faut donner au LLM le contexte de ce que l’on fait, et dans un chat à la ChatGPT, on ne donne pas ce contexte, ou bien c’est trop pénible de le faire. C’est là que Claude Code change la donne.
Prenons par exemple un fichier PCAP dans lequel chaque paquet UDP contient plusieurs messages. Comment filtrer par IP, port, protocole et heure ? On utilise un LLM puis on vérifie la sortie. Comment trouver le nombre de paquets ayant des motifs A, AB, AAB, ABB, etc. ? On utilise un LLM puis on vérifie la sortie. Comment créer, pour les tests, un PCAP ne contenant que ce type de paquets ? On utilise un LLM puis on vérifie la sortie.
Comme il peut aussi lire le code, il peut, franchement, bien mieux déduire ce que vous essayez de faire, parce que votre travail n’a rien d’exceptionnel. Quoi qu’il en soit, le simple fait de pouvoir dire « écris des tests unitaires pour toutes les fonctions ci-dessus » aide déjà à se donner les moyens de vérifier soi-même.
Il y a cette phrase : « comme la plupart des sceptiques et des critiques, j’utilise ces outils tous les jours. Et dans 50 % des cas, ils fonctionnent à environ 50 % ». De mon côté, j’utilise des LLM presque tous les jours au travail depuis environ un an, et ils résolvent environ 90 % de mes problèmes.
Il est très difficile de savoir s’il faut prendre au sérieux ce genre de plaintes sur l’IA/les LLM, ou les considérer comme des schémas d’utilisation irrationnels de la part de certains utilisateurs. Par exemple, je n’ai jamais donné toute une codebase à un LLM en espérant que cela fonctionne comme par magie. Je pose des questions directes et précises à l’intérieur des limites de ma propre compréhension, et j’applique les solutions de façon intentionnellement testable.
Si on aborde les choses autrement et qu’on se plaint ensuite des LLM, je penche plutôt pour dire qu’on les utilise mal. Et qu’on passe à côté d’une vraie petite magie, utile et assez cohérente.
Moi aussi, j’utilise gpt et Claude tous les jours via Cursor. gpt o3 est plutôt correct pour la recherche de connaissances générales. Claude s’effondre souvent, mais j’ai aussi vu qu’en gaspillant des tokens à se mettre en avant, il touche assez souvent des points pertinents pour le vrai problème.
Les modèles sont stupides, et plutôt simplement stupides que des idiots savants. Pourtant, ils tombent parfois sur des éléments pertinents. Si vous savez à peu près ce qui doit se passer et que vous traitez le LLM comme un terrier attrape-rats dans un champ de ferme, vous pouvez en tirer un bon parti.
Le chiffre de 90 % paraît lui aussi un peu suspect.
Cet article donne l’impression d’être en colère contre l’imprécision du discours, mais cette imprécision est, franchement, plus répandue chez les opposants que chez les partisans. Les partisans doivent en général composer tous les jours avec les défauts et les limites.
Conclure que tout ce qui entoure les LLM relève de la pensée magique me semble assez arrogant. Au cours des cinq dernières années, des problèmes auparavant presque insolubles, comme la traduction, la transcription ou la génération de code jusqu’à une certaine échelle, ont été entièrement ou presque entièrement résolus.
Google Translate, Whisper et les générateurs de code existaient déjà depuis assez longtemps sans LLM.
À propos de l’idée que « les cryptomonnaies sont de retour », les cryptomonnaies sont pour moi une bouée de sauvetage. Dans le pays où je vis, je ne peux pas ouvrir de compte bancaire pour des raisons que je ne peux ni contrôler ni corriger.
Donc si les cryptomonnaies ne vous servent à rien, tant mieux pour vous. Pour moi et pour des millions de personnes comme moi, c’est une question de vie ou de mort.
Il en va de même pour les LLM : pour certains, c’est magique ; pour d’autres, c’est un outil déterministe fiable, et en même temps c’est aussi magique. Je viens de classifier et trier des centaines de factures. Oui, c’est magique.
C’est pourquoi il est difficile de trouver quelque chose d’utile que les cryptomonnaies puissent faire dans l’économie légale. Elles ont été conçues pour rendre possibles des transactions que les gouvernements ne veulent pas, ou ne peuvent pas, faciliter. Dans certains cas, il y a des applications humanitaires, et aussi beaucoup d’applications illégales.
« Il fallait y être pour y croire » https://x.com/0xbags/status/1940774543553146956
La vague de l’IA traverse en ce moment une phase similaire. Toute critique est balayée comme venant d’un idiot qui ne comprend rien.
Si vous les utilisez comme monnaie, les gens qui veulent pump and dump des coins et en faire une machine à cash sont vos ennemis. Plus c’est stable, mieux c’est pour vous, plutôt que les montagnes russes des envolées et des krachs.
Je pense qu’il y a davantage de mensonges délibérés du côté des cryptomonnaies, et moins de valeur à en tirer, mais dans les deux cas, des personnes qui pourraient réellement en bénéficier font demi-tour avant même de franchir le seuil, à cause de la malhonnêteté et des déformations. Et dans les deux cas, il existe aujourd’hui des exemples de valeur réelle obtenue.
C’est un peu lié, mais la façon dont le terme AGI, et parfois même le terme IA, est utilisé ces temps-ci m’agace. Surtout dans les articles scientifiques, où l’on s’attend à ce que tout soit bien défini, au moins dans le cadre de l’article en question.
Pourquoi ne pourrait-on pas créer une définition de ce qu’est l’AGI ? On pourrait alors démontrer logiquement quelle IA correspond à cette définition. Même si cela semble peu utile en pratique, ce serait théoriquement bien plus utile que d’utiliser le terme sans signification.
En l’état, cela ressemble à une sorte d’échappatoire. Wikipedia dit : « un type d’IA qui égale ou dépasse les capacités humaines dans presque toutes les tâches cognitives ». Comment mesure-t-on cela ? Si l’on ne peut pas prouver qu’un système possède cette propriété, à quoi cela sert-il ?
C’est un peu un coup de gueule, mais j’espère que cela reste au moins lisible.
C’est un peu comme le fait que pour moi, « crypto » désigne toujours la cryptographie, pas les cryptomonnaies. Parfois, le grand public a simplement une opinion différente.
« L’IA, c’est ce qui n’a pas encore été fait »[1]
Récemment, mon entreprise a commencé à utiliser des LLM, et notre première tâche a consisté à transcrire 20 000 appels clients, puis à en extraire les informations suivantes :
Une recherche qui prenait auparavant des semaines a été terminée en quelques heures. Cela nous a aidés à élaborer une nouvelle stratégie et a créé une vraie valeur business.
Je vois simplement les LLM comme des moteurs de traitement du langage naturel, et ils sont excellents pour cet usage. Oui, certains exagèrent, mais cela ne change pas le fait que, dans notre cas, ils ont réellement été utiles. Je ne comprends pas pourquoi il y a autant d’articles « les LLM, c’est nul ». Si cela ne vous convient pas, passez votre chemin. Pourquoi faudrait-il que quelqu’un prouve quelque chose à quelqu’un ? Ce n’est qu’un outil.
Ce genre d’articles est important pour refroidir les attentes. Quand les gens vendent des LLM, ils ne parlent généralement pas de résumer des appels au support client, mais essaient de vendre l’idée qu’on peut licencier les employés du support client.
Pendant des années, la plupart des traductions sur le Web n’avaient aucun contexte. Maintenant, elles peuvent en avoir.
Des figures crédibles et raisonnables du monde de la tech, connues pour leurs positions prudentes, ont rapporté avoir obtenu des améliorations significatives dans leur travail de programmation en utilisant diverses formes d’IA générative.
Que veut dire significatif ici ? Entre 5 % et 100 %, c’est-à-dire un niveau non négligeable.
On peut au moins dire sans trop de risque que l’IA générative est, ou peut être, un outil nettement bénéfique pour un nombre important de personnes.
Pour qu’un tel jugement soit raisonnable, il n’est pas nécessaire de publier tous les détails comme le nombre de CPU, le nombre de lignes de code ou le nombre d’octets traités.