Paraître productif au travail
(nooneshappy.com)- L’IA générative permet la production inter-domaines, où une personne non formée crée des livrables relevant d’un autre domaine d’expertise, donnant à des débutants l’apparence d’un gain de productivité sans le discernement nécessaire pour évaluer les résultats
- Au travail, les livrables qui ressemblent à des progrès — code, systèmes de données, documents — se multiplient, mais les utilisateurs sont incapables d’expliquer leur fonctionnement réel, ou bien se trompent dès le départ sur le schéma et les objectifs
- L’IA rompt le lien entre la qualité d’un livrable et la compétence de son auteur, créant un découplage entre livrable et compétence, et transformant l’utilisateur en simple conduit qui transmet un résultat sans pouvoir l’évaluer
- Les documents internes et les mises à jour deviennent plus longs à mesure que leur coût de génération baisse, alors que leur coût de lecture ne diminue pas, ce qui rend plus difficile de trouver le signal dans l’organisation et crée une nouvelle forme d’AI slop produite par des salariés
- L’IA générative convient aux brouillons, exemples, résumés, brainstormings et corrections lorsque l’humain reste le juge final et que le feedback est rapide ; la capacité à fournir un travail fiable demeure un avantage compétitif pour les entreprises
Le problème des livrables IA qui ressemblent à de la productivité
- L’IA générative peut produire des résultats qui ont l’air professionnels sans expertise réelle, et l’échec prend deux formes
- un débutant dans un domaine produit des résultats qui paraissent plus rapides ou plus sophistiqués que son propre jugement
- une personne sans formation dans un domaine produit des livrables relevant d’un autre domaine d’expertise
- Les recherches existantes mesurent surtout la première forme, mais la plus dangereuse est la production inter-domaines, où des personnes non formées génèrent des livrables d’autres disciplines
- Sur des canaux publics, on voit des collègues coller tel quel des réponses qui semblent venir de Claude, en donnant l’impression de manier avec assurance des techniques qu’ils ne comprennent pas réellement
- Dans ces situations, l’interlocuteur n’est plus vraiment de l’autre côté de la conversation, mais fonctionne plutôt comme un relais de la sortie du modèle
Production inter-domaines
- Des personnes qui ne savent pas coder construisent des logiciels, et des personnes qui n’ont jamais conçu de système de données conçoivent des systèmes de données
- la plupart ne seront jamais mis en production, mais ils sont partagés en interne avec enthousiasme ou utilisés discrètement, et finissent parfois visibles côté client
- il existe aujourd’hui quelques praticiens capables d’utiliser correctement des outils agentiques pour des tâches complexes, mais ils restent rares et on les trouve surtout dans la génération de code
- les capacités individuelles avec l’IA ont progressé, mais elles ne passent pas correctement à l’échelle dans le travail réel
- Un collègue occupant un poste non technique a passé deux mois, plus tôt cette année, à construire un système qui aurait dû être conçu par quelqu’un ayant reçu une formation formelle en architecture de données
- selon les critères actuels d’évaluation de l’usage des outils IA, il utilisait bien l’outil, et a produit beaucoup de code, de documentation et de livrables donnant l’apparence d’un avancement
- mais lorsqu’on lui posait des questions, il était incapable d’expliquer le fonctionnement réel du système
- le schéma et les objectifs étaient erronés dès le premier jour, avec des erreurs qu’une personne ayant deux ans d’expérience dans le domaine aurait repérées
- plusieurs personnes le savaient, l’information est remontée jusqu’au niveau V.P., mais les managers avaient déjà investi dans l’apparence d’élan et ne voulaient pas la remettre en cause
- L’outil n’a pas fait de lui un pire collègue ; il lui a permis de simuler de manière crédible pendant des mois une discipline pour laquelle il n’était pas formé
- les incitations de l’organisation penchent vers la poursuite de cette simulation
- on peut y voir un échec managérial, mais la volonté des dirigeants d’adopter l’IA les conduit à accepter ce risque
- On pourrait atténuer le problème si les modèles évaluaient honnêtement les livrables, mais ce n’est pas le cas
- l’étude de Stanford par Cheng et al., Sycophantic AI decreases prosocial intentions and promotes dependence, montre que les grands modèles sont environ 50% plus complaisants que des répondants humains et valident les utilisateurs même sans fondement
- selon Berkeley CMR, Seven Myths About AI and Productivity: What the Evidence Really Says, même les utilisateurs compétents avec l’IA surestiment souvent leurs performances
- selon le NBER, Generative AI at Work, l’IA générative a augmenté d’environ un tiers la productivité des agents de support débutants, mais n’a presque pas aidé les experts
- la Harvard Business School, dans Navigating the Jagged Technological Frontier, observe le même schéma dans le travail de conseil
- Au final, les débutants peuvent accroître leur productivité individuelle dans des domaines hors de leur expertise, tout en restant incapables de vérifier si les livrables sont corrects
Le problème du conduit
- Ce phénomène est de plus en plus désigné comme un découplage entre livrable et compétence (output-competence decoupling)
- autrefois, la qualité d’un livrable signalait en général la compétence de son auteur
- l’écrit d’un débutant se lisait comme celui d’un débutant, et le code d’un débutant échouait de façon typique d’un débutant
- l’IA rompt ce lien, permettant à un débutant de produire des livrables qui ne révèlent plus son niveau réel
- La compétence reflétée dans le livrable n’est plus celle de l’utilisateur, mais celle du système
- l’utilisateur peut transmettre le résultat au destinataire, mais il ressemble davantage à un conduit incapable d’évaluer ce qu’il fait passer
- La capacité à produire et la capacité à juger ont toujours été distinctes, mais l’exécution concrète du travail développait normalement le discernement
- la première capacité, produire des livrables, passe désormais en grande partie à la machine
- la seconde, juger, reste humaine, mais de moins en moins de personnes apprennent à l’exercer ou cherchent à l’utiliser
- Autrefois, une critique d’architecture venait de quelqu’un formé ou ayant déjà construit et vu casser plusieurs systèmes comparables
- désormais, cette critique provient d’un modèle sans mémoire incarnée de la construction ni de la casse
- la lenteur n’était pas seulement le coût attaché au travail réel ; elle faisait partie du processus même par lequel le travail s’améliorait, les personnes devenaient compétentes, et l’entreprise pouvait promettre un certain niveau de qualité à ses clients
- La génération actuelle de systèmes agentiques est conçue autour de l’hypothèse que l’humain est le goulot d’étranglement
- l’idée est que plus on réduit le délai lié à la lecture et au jugement humains de ce qui va arriver, plus la boucle devient rapide et propre
- dans bien des cas, c’est l’inverse : l’humain dans la boucle n’est pas un vestige du passé, mais le seul composant ayant un intérêt réel dans le résultat
- retirer l’humain de l’HITL n’est pas une optimisation ; c’est abandonner le seul mécanisme permettant au système de se corriger lui-même
L’AI slop interne
- Les documents de travail s’allongent rapidement
- un document d’exigences qui faisait une page en fait maintenant 12
- une mise à jour d’état qui tenait en trois phrases devient un document en puces résumant un résumé de résumé
- rétrospectives, rapports d’incident, notes de conception, decks de lancement, et tout livrable susceptible de s’allonger s’allonge
- Le coût de production est devenu proche de zéro, mais le coût de lecture n’a pas baissé et augmente même
- le lecteur doit filtrer un contexte synthétique pour retrouver ce que le document voulait dire au départ
- pour chaque individu, le choix d’allonger un document paraît rationnel et est récompensé indépendamment
- selon Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling, les lecteurs accordent davantage de confiance à des explications plus longues générées par IA, indépendamment de leur exactitude
- En conséquence, il est plus difficile qu’avant de trouver le signal dans l’entreprise
- les points de contrôle se cachent dans les documents, et les gens finissent noyés dans le travail documentaire même lorsqu’ils essaient réellement d’être concis
- C’est une nouvelle forme de slop, plus coûteuse encore que l’AI slop qui envahit le marché public
- parce que ceux qui le produisent sont payés
- le travail qui enseignait le discernement est désormais fait par l’outil, et les postes juniors où cet apprentissage se produisait diminuent parce que l’outil semble pouvoir faire le travail
- Dans beaucoup de bureaux, il y a énormément de mouvement, mais moins de résultats concrets que ce mouvement produisait auparavant
- le débat public s’est surtout concentré sur l’AI slop déversé sur le marché ouvert, et l’Université de Floride, avec Generative AI and the market for creative content, traite de cette dynamique
- mais la même mécanique apparaît aussi à l’intérieur des organisations
- du temps est consacré à des tâches qui n’avaient pas besoin d’IA, à des livrables que personne ne lira, et à des processus nés parce que les outils les rendent bon marché à produire
- il devient plus fréquent de transformer en deck des choses qui auparavant n’avaient même pas besoin d’être dites, ou allaient simplement de soi
Comment réagir
- La discipline nécessaire dans cet environnement ressemble à des méthodes plus anciennes
- n’utiliser l’outil que là où l’on peut vérifier précisément ce qu’il produit
- ne pas demander au modèle de confirmer
- l’outil est d’accord avec tout le monde, et un accord qui ne coûte rien à celui qui l’accorde n’a aucune valeur
- Les tâches adaptées à l’IA générative sont celles où le feedback est rapide, où une justesse approximative suffit, et où l’humain reste juge final
- rédaction d’un brouillon de note
- génération d’exemples
- résumé de documents que le lecteur peut vérifier s’il le souhaite
- La Generative AI Guidance de l’Université de l’Illinois et l’article de PLOS Computational Biology, Ten simple rules for optimal and careful use of generative AI in science, recommandent notamment les usages suivants
-
brainstorming
-
correction
-
reformulation de ses propres idées
-
détection de motifs dans des données que l’on comprend déjà
-
- Dans tous les usages recommandés, l’humain apporte le jugement et l’outil apporte le débit
- c’est une position plus forte qu’un simple humain dans la boucle
- l’outil doit rester à l’extérieur du travail, n’intervenir que lorsqu’il est explicitement invité, et rester silencieux le reste du temps
- c’est l’inverse de la direction prise actuellement par beaucoup de systèmes agentiques
- Pour les entreprises, la capacité à fournir un travail fiable demeure un avantage compétitif
- plus les concurrents se transforment en pipeline de génération de contenu en espérant que le client ne s’en apercevra pas, plus la valeur d’un travail digne de confiance augmente
- Les problèmes remontent déjà à la surface
- Deloitte a remboursé une partie d’honoraires de 440000 dollars après un rapport gouvernemental contenant des hallucinations d’IA
- le prochain problème pourrait être un système opérationnel fondé sur des spécifications hallucinées, ou un ingénieur senior réalisant qu’il a nominalement validé, pendant un an, un travail qu’il ne pouvait pas réellement examiner
- les entreprises qui travaillent correctement peuvent se placer en position de faire payer ce travail à sa juste valeur
- celles qui se sont vidées de leur substance découvriront que c’était précisément cette substance que les clients payaient
- Les malentendus et les mauvais usages de l’IA au travail sont omniprésents
- l’expertise subit la pression de livrer plus vite, de produire davantage, d’intégrer plus profondément les outils et de ne pas gêner les collègues qui « font avancer les choses »
- les livrables s’empilent, mais pas le travail réel
- et à l’autre bout de ces livrables, le client peut ouvrir la livraison, lire la liste de résumés, puis décider de vérifier lui-même
1 commentaires
Commentaires sur Hacker News
L’inflation verbeuse des livrables — par exemple quand un document d’exigences qui tenait autrefois sur une page en fait désormais douze — m’a profondément parlé
Ça m’a rappelé l’époque où j’allongeais volontairement mes phrases pour atteindre le minimum de 1 000 mots d’une dissertation au lycée, et aujourd’hui une mise en forme professionnelle, de la longueur et des phrases claires ne sont plus forcément des signaux de soin et de qualité
Du coup, le goulot d’étranglement actuel de la hausse de productivité semble toujours être les gens qui y prêtent encore assez attention pour relire eux-mêmes
Aujourd’hui, même des documents de spécification de 10 à 30 pages bourrés de mise en forme et de schémas ASCII ont de fortes chances d’être en réalité de simples idées lancées à la va-vite, donc il faut s’habituer à les lire comme telles
Les managers vont probablement résumer et évaluer ce que j’envoie via un chatbot ou un agent, mais si c’est moi qui envoie directement le résumé, ce n’est pas acceptable
C’est comme s’il me fallait aussi un vérificateur IA pour mes écrits, comme les ATS pour les CV, et au final des textes écrits par une IA seront analysés par une autre IA, ce qui ressemble à un gaspillage d’énergie énorme
J’aimerais qu’il existe des règles, structures, standards et procédures partagés pour communiquer plus efficacement
Le résultat de tous ces contenus qui rallongent n’importe quoi pour remonter dans les résultats de recherche
Les gens qui envoient ça ne feront de toute façon aucun suivi, donc le problème disparaît de lui-même
La situation décrite ici ressemble énormément à ce que j’ai vécu aussi
Dans mon entreprise, il y a beaucoup de managers qui n’ont pas écrit de code depuis des années, et l’architecte embauché il y a 18 mois a tout conçu avec de l’IA
Pour les développeurs seniors, il était évident que tout était massivement surconçu, mais comme il utilisait toute la bonne terminologie, il paraissait plus compétent que les autres senior managers aux yeux de la direction, et quand on le reprenait il répondait par des attaques personnelles
Au bout d’environ six mois, plusieurs personnes sont parties, celles qui restaient se sont mises à fond sur l’IA, et depuis 12 mois elles construisent des workflows agentiques pour combler le vide laissé par le départ des employés compétents
Résultat : rien de valable n’a été livré depuis 18 mois, après avoir gaspillé énormément de coûts cloud sur des solutions mal conçues, l’entreprise réduit maintenant les dépenses via un gel des embauches
Quand l’économie change fortement, c’est comme enlever un barrage : le reste du système subit beaucoup plus de stress
Si les dirigeants ne voient pas ces effets secondaires potentiels et ces risques, ils peuvent se faire très mal
Même si cette technologie a été vendue comme une amélioration universelle, j’ai l’impression qu’on va voir proliférer ce type d’entreprises avant de les voir s’effondrer
Les entreprises qui survivront diffuseront la manière de dompter cette bête sauvage, et idéalement on en apprendra quelque chose à l’avenir
Mais l’enthousiasme naïf actuel est frappant, et cet éternel septembre de gens surexcités par leurs nouvelles capacités de vibe coding semble parti pour durer un moment
Il y a deux postes, le vibe coding n’était même pas encore vraiment praticable, mais certains étaient déjà tellement absorbés par l’idée de tout gonfler avec des LLM qu’il devenait difficile d’obtenir une réponse par oui ou non à n’importe quelle question
À un message Slack d’une ligne, une question de 20 secondes, on recevait en réponse un billet de blog flou de deux pages sans conclusion, et les questions de suivi faisaient encore perdre plus de temps
Dans mon dernier poste, j’ai vu un PM devenir petit à petit le vibe manager des vibe coders
Il s’invitait dans les discussions techniques et donnait la direction à chaque étape via l’IA, et quand on contestait, on finissait à se battre contre la traduction par l’IA d’un sujet qu’il ne comprenait pas lui-même, ce qui était épuisant
Il n’était même plus permis de s’y opposer, et on nous mettait la pression en disant que l’IA menaçait nos emplois
Ensuite, le vibe coding a été rendu obligatoire pour tout le monde et sa quantité a commencé à être surveillée, et comme ce PM faisait à la fois le PM, l’ingénieur et l’architecte, il créait plusieurs tickets pour la même tâche avec des exigences totalement contradictoires
Du coup, un membre de l’équipe vibe-codait d’une manière et un autre implémentait autrement
C’était très dur à voir : une équipe rentable de 20 personnes qui générait presque 100 millions de dollars de bénéfices par an se faire démolir par un travail inutile et vide de sens, et j’ai fini par partir
J’essaie de ne pas devenir cynique face à ces évolutions du logiciel, mais c’est vraiment difficile
Un manager, avec une compréhension incomplète du domaine, utilise Claude pour produire des conseils et recommandations d’expert, pendant que divers profils non techniques de l’entreprise construisent des outils logiciels internes destinés à être diffusés à toute l’organisation, dans l’espoir d’obtenir reconnaissance et récompenses grâce à ces démos
La direction, sans surprise, est impressionnée par ces preuves de concept et les valide
Des collègues hyperactifs présentent des démos qui donnent l’apparence de l’expertise sans rien comprendre au fond, et le leadership l’accepte
Je ne savais pas comment formuler ce problème, et ce texte le pointe très bien
Bien sûr, avec l’IA on peut encore moins produire
Ça ressemble à un environnement extrêmement toxique
Les équipes les plus productives qui utilisent les LLM pour produire du bon logiciel s’en servent probablement de cette façon
La complétion intelligente est l’usage originel des LLM où le code généré reste dans le contexte du code sur lequel le développeur travaille et agit comme une extension du raisonnement, au lieu de sous-traiter la pensée elle-même au LLM
Pour le brainstorming, ça peut développer des concepts, idées ou directions encore flous et stimuler la créativité
Pour la résolution de problèmes, c’est assez utile pour déboguer des conflits de packages, des exceptions aléatoires ou des bug reports, et ça peut aider à remonter jusqu’à la cause racine quand on n’a pas de collègue à côté
En revue de code, ça attrape parfois quelques points manqués par un humain, un peu comme une étape de lint plus intelligente, mais ça ne remplace pas la revue de code humaine
En preuve de concept, ça peut générer différentes approches d’un problème et servir d’inspiration pour une solution élaborée plus soigneusement
Ces usages accélèrent le développement tout en maintenant la responsabilité du développeur de savoir ce qu’il construit et pourquoi
À l’inverse, les équipes qui misent tout sur le coding agentique semblent très susceptibles de dégrader involontairement leur produit et leur équipe sur le long terme
Ces derniers temps, plusieurs fois, les réponses étaient parfaitement plausibles mais complètement fausses, et parfois même hors sujet
En revue de code, il y a énormément de faux positifs, et je ne vois pas bien pourquoi ça s’améliorerait
Cela dit, il y a peut-être quand même un potentiel d’aide dans cette direction
Personnellement, je l’ai désactivée il y a environ un an pour revenir à l’autocomplétion traditionnelle des IDE JetBrains
Dans mon expérience, les suggestions IA prédisaient exactement ce que je voulais dans moins de 1 % des cas, n’étaient utiles qu’environ 10 % du temps, et le reste du temps elles étaient soit fausses, soit agaçantes
Les fonctionnalités standard de l’IDE qui permettent de rechercher ou parcourir rapidement méthodes, variables, etc. m’ont été bien plus utiles pour transformer ma pensée en code
Notre équipe a aussi testé quelques outils, mais la plupart des remarques soulevées étaient très superficielles, voire pas des problèmes du tout
Quand ils passaient sur le code de membres plus faibles de l’équipe, ils rataient des problèmes plus profonds, alors qu’un reviewer humain repérait des changements incorrects sur des sujets qu’on pouvait résoudre bien mieux
Notre manager a utilisé ces résultats comme preuve confirmant son biais selon lequel nous ne savions pas ce que nous faisions
Il copiait-collait dans les commentaires de PR la sortie d’outils de revue de code remplie d’emojis, et quand on corrigeait des détails mineurs, il postait « deuxième tour de revue de code »
Le moral a fortement chuté et certains membres de l’équipe ont fini par abandonner toute revue sérieuse et approuver les PR telles quelles
Pour relire son propre code, pourquoi pas, mais ça ne devrait pas devenir une contrainte obligatoire du processus
Le but initial de la revue de code était d’investir du temps pour aider les autres à progresser, et si on sous-traite cela à une machine, le contrat social de l’équipe s’effondre
Il y a deux ans, on disait que ce n’était que de l’autocomplétion pure et un Google amélioré
Les pessimistes de l’IA ont tort année après année, tout en faisant comme s’ils n’avaient jamais affirmé que l’IA actuelle serait absolument incapable de ce qu’elle sait faire aujourd’hui
Le génie logiciel semble particulièrement propice à ce genre de situation pour plusieurs raisons
Beaucoup d’ingénieurs logiciel n’ont jamais fait de vraie ingénierie de toute leur carrière, et c’est encore pire dans les grandes entreprises
Ils entrent comme petit rouage dans une grosse machine, apprennent un langage de configuration créé parce que quelqu’un voulait être promu, réorganisent et refactorisent cette configuration, puis « corrigent » le résultat d’un autre framework interne à grands coups de réglages de knobs, et cinq ans plus tard ils font toujours ça
L’industrie compte aussi beaucoup de métiers quasi-ingénierie
Des gens qui disent avoir arrêté de coder parce qu’ils aiment travailler avec des humains, ou parce qu’ils sont fascinés par le produit et le travail des utilisateurs, remplissent les postes en .*M dans des entreprises grandes et petites
Dans les grandes entreprises, le train avance lentement : il faut des mois pour qu’un commit arrive en production, et six mois n’ont rien d’inhabituel
Dans beaucoup de systèmes importants et de grande taille, le code agentique n’est même pas encore arrivé en production
Donc l’IA remplace certains emplois de façade, les gens qui gravitaient autour du code se mettent soudain à adorer le vibe coding, et dans les entreprises lentes les conséquences n’ont pas encore explosé
Vu de l’extérieur, cela ressemble à un boom de productivité
Le passage « des gens qui ne savent pas coder construisent du logiciel, et des gens qui n’ont jamais conçu de systèmes de données conçoivent des systèmes de données » m’a rappelé « comment lancer un projet dans une grande entreprise tech »
En particulier la phrase « un lancement est une construction sociale au sein de l’entreprise. Plus précisément, un projet est lancé lorsque des personnes importantes de l’entreprise croient qu’il a été lancé »
https://news.ycombinator.com/item?id=42111031
C’était un bon texte, et il avait aussi suscité une discussion intéressante sur le fait de sauver les apparences et sur l’importance du paraître, souvent bien plus grande qu’on ne le pense
Au début de l’adoption de l’IA au travail, j’ai remarqué que certains collègues utilisaient cette technologie pour afficher une proactivité excessive
Chaque semaine apparaissaient de nouveaux TOD, de nouvelles idées de refactorisation, de nouvelles manières de résoudre d’anciens problèmes avec un algorithme brillant et tout neuf
Aujourd’hui, le phénomène a doublé d’ampleur : à la volonté de paraître plus actif s’ajoute la peur des licenciements liés à l’IA, si bien que des solutions sont construites avant même que le problème soit vraiment défini
Par exemple, on m’a confié l’étude d’un problème d’architecture particulier à l’échelle de l’entreprise, et je pensais être reconnu si je proposais une solution solide, mais il était déjà trop tard
Un stagiaire avait déjà trouvé une solution et rédigé un TOD, et je suis désormais trop épuisé pour entrer en compétition
Hier, j’ai passé la majeure partie de mon temps à supprimer et remplacer du code généré par un LLM
En général, l’aide des LLM m’a été bénéfique, mais cette fois il a pondu un tas de code à base de threads délirant, et pour la première fois depuis des années mon application s’est mise à planter
Mon application ne plante pas
Elle peut avoir plein d’autres problèmes, mais les crashes n’en font pas partie, et je suis assez obsessionnel là-dessus
D’après mon expérience, il y a très rarement une bonne raison de dispatcher vers de nouveaux threads
Je laisse souvent le SDK de l’OS le faire quand il le juge nécessaire et je respecte ce choix, mais lancer moi-même des threads workers apporte rarement plus que des souffrances de débogage
Ça ne vaut pas pour tous les types d’applications, mais ça vaut pour celles que j’écris
Les LLM adorent les threads, probablement parce qu’ils ont beaucoup vu de code d’apprentissage publié par des gens surexcités qui s’entichent de technologies brillantes
Au final, dès que j’ai arraché ce code d’interface et remis du code écrit par moi-même, les performances se sont nettement améliorées et les crashes ont cessé
La leçon, c’est caveat emptor
Je me suis reconnu dans le passage sur le fait d’hésiter à discuter avec quelqu’un quand il est évident qu’il copie-colle directement depuis un modèle
J’ai parfois trouvé un petit plaisir à répondre à ces gens de la même manière
Je colle leur sortie d’IA dans ma propre IA, puis je recolle sa réponse
Deux humains se comportent comme des machines pour que deux machines fassent du cosplay de communication humaine
C’était assez spectaculaire
À une simple question sur mon orientation de senior concernant pourquoi, pour une preuve de concept entre amis, il valait mieux lancer vite sur Vercel que surarchitecturer sur AWS, il m’a envoyé un diagramme fourre-tout généré par IA
Il était tellement enfermé dans l’idée que son frère utilise AWS et qu’il voulait lui-même faire carrière là-dedans qu’au lieu de réfléchir directement à pourquoi cette approche serait adaptée à une preuve de concept entre amis, il a externalisé sa réflexion à l’IA
Quand il m’a demandé si je l’avais lu, je lui ai répondu que je l’avais lu sous forme résumée par une IA, mais que je n’y avais pas répondu, et la conversation s’est arrêtée très vite
Dire que « ça n’aide pas les experts » est un peu court
Même les personnes très compétentes ont des zones de faiblesse ou des tâches ennuyeuses qu’on peut automatiser
Dans mon cas, ce qui freinait ma carrière auparavant, c’était d’organiser beaucoup de tâches à la fois, de communiquer efficacement les changements à l’échelle de l’organisation, ainsi que la documentation et la gestion des tickets dans Jira et consorts
Aujourd’hui, ce n’est plus une source d’inquiétude, et le gain d’efficacité sur ce point a été énorme
Dans mon cœur de métier, ça ne m’aide pas énormément au-delà du fait de taper beaucoup plus vite à ma place, mais c’est déjà très appréciable
Et quand on me demande de faire quelque chose que je maîtrise moins, l’outil le fait généralement mieux que moi, ou au moins m’oriente vers des décisions mieux informées
Je suis d’accord avec l’idée « ne demandez pas au modèle de confirmer. L’outil est d’accord avec tout le monde »
Si je lui dis arbitrairement qu’il y a quelque chose de faux, le LLM finit toujours par trouver un défaut, même dans du code dont je sais qu’il est correct
Le problème, c’est que les LLM ont souvent tendance à prendre les choses trop littéralement
Même quand on leur demande un plan, je n’ai jamais vu un LLM réussir à concevoir de façon autonome tout un système
Quand un LLM a généré du code, si on lui demande ensuite de plusieurs manières si c’est correct, il arrive assez souvent à détecter de vrais problèmes