Je crois faire un burn-out des LLM
(alecscollon.com)- En utilisant chaque jour Claude Code, Codex, ChatGPT et Gemini pour le travail comme pour des projets personnels, le temps passé à lire du texte généré par l’IA a fortement augmenté par rapport à il y a quelques années
- Le flux de développement est passé d’une approche où l’on concevait et implémentait directement à explication de la conception → revue du code par le LLM → corrections manuelles, ce qui facilite aussi le travail dans des domaines moins familiers
- Le projet actuel aussi repose principalement sur un framework de génération de code non supervisée à grande échelle et sur la revue des sorties de l’agent Qwen, ce qui impose de lire en continu du contenu produit par des LLM
- Après environ un an d’usage continu, ces derniers mois, des schémas récurrents comme les fausses hypothèses, les hallucinations, les phrases courtes et péremptoires, ou l’usage excessif d’emojis se sont accumulés jusqu’à devenir pesants
- Le cœur de la fatigue vient moins des LLM eux-mêmes que de la répétition du même style et du même type d’erreurs ; même avec des fonctions de personnalisation, il reste difficile de contrôler le style des contenus IA générés par d’autres personnes
Les LLM profondément intégrés au flux de développement
- Mon niveau d’utilisation des LLM est aujourd’hui moyen pour un développeur, et ma manière de les utiliser reste encore assez rudimentaire
- Je traite une tâche à la fois ; au travail, j’utilise Claude Code, et chez moi je discute actuellement avec Codex
- Même quand je demande à l’assistant d’écrire du code, je lis attentivement sa sortie, je la comprends, puis je la modifie moi-même
- Je n’en suis pas au stade d’utiliser en profondeur des agents autonomes ou de l’orchestration d’agents
- Ma façon de travailler est passée d’un mode centré sur la conception et l’écriture du code à une forme où j’explique la conception au LLM, je relis le code qu’il produit, puis je réécris du code
- Dans ce processus, je découvre des approches que je n’avais pas envisagées ou que je ne connaissais pas
- Je travaille aussi plus confortablement dans des domaines où je n’ai pas de connaissances approfondies
- Mon projet principal actuel consiste à mettre en place, dans une base de code, un framework de génération de code non supervisée à grande échelle
- Quand je ne construis pas d’outils avec Claude, je relis les sorties de Qwen, un agent non supervisé
- Dans les deux cas, je finis par lire en permanence du contenu produit par des LLM
- Quand je cherche des informations, si je ne connais pas déjà un site précis, il m’arrive souvent de demander à ChatGPT ou de lire l’aperçu de Gemini
- Si la réponse du LLM est incorrecte, il faut revenir à la navigation web classique
- Quand les résultats de recherche contiennent beaucoup d’articles inutiles générés par IA, je considère que les réponses des LLM sont suffisamment correctes pour les questions du quotidien
La fatigue née du même style et des mêmes erreurs qui s’accumulent
- Cette manière de travailler dure depuis environ un an, et je n’ai pas l’intention de l’arrêter tout de suite
- J’ai l’impression d’être plus productif avec les LLM
- Je pense aussi qu’il est utile de continuer à apprendre à les utiliser efficacement
- Ces derniers mois, ma perception de la lecture des sorties de LLM a changé
- Avant même de lire, j’ai l’impression de déjà savoir quel style et quelles erreurs je vais rencontrer, et cela devient pesant
- Les éléments qui reviennent sans cesse sont les fausses hypothèses, les hallucinations, les phrases courtes et péremptoires, et l’usage excessif d’emojis
- Pris séparément, chacun de ces désagréments est supportable, mais leur répétition combinée finit par me lasser très vite de l’écriture produite par les LLM
- Le point essentiel n’est pas d’accuser les LLM d’être pires que les humains, mais leur répétitivité
- Les humains aussi peuvent être peu fiables ou agaçants
- Les LLM écrivent dans le même style et répètent les mêmes types d’erreurs
- Quand l’interface le permet, on peut utiliser des fonctions de personnalisation, mais certains tics stylistiques demeurent
- On ne peut pas contrôler directement le style des contenus générés par d’autres personnes
- Je ne sais pas encore comment gérer ce sentiment ; au-delà de la frustration face à des outils instables, ce sont les schémas mêmes de l’écriture qui continuent à m’irriter
2 commentaires
Moi aussi, j’ai souffert des fausses prémisses dans les réponses des LLM, des hallucinations, des phrases courtes et catégoriques, et de l’usage excessif des émojis.
J’ai donc créé et appliqué la règle ELI5, ce qui m’a permis de sortir de cette souffrance :)
https://github.com/amebahead/explain-like-iam-five-rules
Réactions sur Hacker News
Pas au point du burnout, mais les LLM sont vraiment épuisants à cause de la pression qu’ils créent. Personne ne pousse explicitement à augmenter la charge de travail, mais à chaque instant il y a quelque chose que mon « clanker » ou celui de quelqu’un d’autre a produit, et que je peux débloquer si je m’y mets
C’était déjà difficile de suivre avant les LLM, mais maintenant j’ai l’impression qu’il y a en permanence 10 fois plus de travail en attente, et ça pourrait encore être multiplié par 10 si tout le monde « optimise » pour alimenter plus vite l’IA en parallèle. C’est fatigant d’être constamment le goulot d’étranglement de tout
J’aime concrétiser de petits side projects et des idées, mais j’ai réalisé que les LLM alimentent encore plus cette mentalité malsaine selon laquelle « se reposer, c’est perdre son temps », et j’ai senti qu’il fallait corriger ça
Le grief central du billet devait sans doute déjà exister à l’époque de l’automatisation des usines. Comme quand des métiers manuels variés et qualifiés ont été remplacés par une place sur une chaîne d’assemblage à répéter le même geste toute la journée, les LLM ont pris la partie créative et changeante pour ne laisser qu’un tamponnage de QA répétitif. On peut peut-être retrouver aujourd’hui les mesures d’atténuation qu’on utilisait alors
Récemment, un collègue m’a envoyé un fichier zip contenant environ 30 documents générés par LLM et m’a demandé de les relire immédiatement ; une bonne partie était répétitive ou contenait des manipulations sorties de nulle part et des hallucinations. La génération va bien plus vite que la relecture
Avant, un chef de projet passait une bonne partie de sa journée à rédiger un document de cadrage, mais maintenant il peut en produire un en quelques minutes et le balancer en relecture, et c’est vraiment épuisant
Le « centaure inversé » n’a rien de nouveau. Il suffit de demander au mouvement ouvrier du siècle dernier
C’est sans doute encore plus vrai parce que je suis un software engineer qui aime fabriquer des produits plus que d’utiliser des logiciels complexes. Ce qui me motive, c’est la sensation de créer quelque chose, et j’ai envie qu’une fonctionnalité soit parfaite et réellement finie. Mais, sur de l’UI, le passage de 95 % à 100 % prend longtemps
Donc malheureusement, mes journées de travail sont beaucoup plus longues en ce moment
Du coup, je dois arrêter de faire du travail productif et réserver un certain pourcentage de mon temps à « faire de l’IA pour montrer ma consommation de tokens ». La charge de travail reste la même ou augmente, mais le temps réel pour travailler diminue de N % parce qu’il faut apaiser les dieux de l’IA
D’après mon expérience, il y a trois grandes causes au burnout. La première, et de loin la plus importante, c’est le multitâche. Il faut souvent passer d’une fenêtre d’agent à une autre, 3 à 5, chacune sur un sujet différent, et quand chaque tour prend plusieurs minutes, c’est extrêmement épuisant
Avant l’ère des agents de code, la plupart des développeurs avaient probablement la possibilité de se concentrer plus de deux heures d’affilée sur une seule chose. Maintenant, les agents de code ont élargi l’étendue de la stack technique qu’on peut couvrir, mais pas la bande passante pour travailler en profondeur
Deuxièmement, les agents savent faire en sorte que tout tourne sans conflit, mais ça ne garantit pas qu’ils produisent du code correct. C’est très différent d’un expert humain qui maîtrise les bases
Troisièmement, relire des tas de PR médiocres générées par IA est frustrant. La concentration est une ressource limitée. Je n’ai pas envie de dépenser trop d’énergie sur le travail des autres, mais si je n’y mets pas davantage d’attention, du code IA irresponsable, produit sans la réflexion ni la conception soigneuse d’un auteur humain, détériore vite l’ensemble du projet. C’est déjà pénible de travailler avec des gens qui manquent de rigueur, mais à l’ère des agents de code ils produisent 10 fois plus de déchets, donc c’est 10 fois plus douloureux, et c’est un problème de culture d’équipe qu’on ne peut pas facilement imposer
Après avoir lu pendant des heures les sorties d’Opus, je commence à ressentir comme un malaise physique. Ce texte me parle vraiment.
J’ai commencé à m’en plaindre à l’équipe aussi, mais il faut au minimum ajouter un guide de style personnel aux règles de l’agent pour éliminer les tirets cadratins, les tournures du type « ce n’est pas X, c’est Y », la façon d’empiler de longs modificateurs devant les noms, l’usage de « land » au sens d’achever quelque chose, etc. J’espère que ce n’est qu’une phase de maturité incomplète des LLM.
En tant qu’humain, on sait qu’un gate est une « porte » qui peut être ouverte ou fermée, verrouillée ou non, et qu’il peut y avoir ou non un passage au-delà. Le simple fait qu’il y ait un gate ne dit pas s’il est ouvert ou fermé.
Or, dans le langage des bots, gate désigne seulement une barrière forte et infranchissable. Ils l’emploient comme si c’était une clôture, un mur, voire même une douve de lave.
Pourtant, un gate est à l’origine un objet conçu pour qu’on puisse passer, mais les bots utilisent le même mot même pour des obstacles pensés pour être infranchissables. À l’aune de plusieurs décennies passées à avoir affaire à des gates dans le monde réel, c’est un mauvais usage. En général, quand on tombe sur un gate fermé, il suffit de l’ouvrir et de passer.
Même si on leur demande d’éviter ce mot, ils l’ignorent parfois. Aujourd’hui, le mot qui me saute aux yeux est gate ; hier, c’en était un autre, et demain ce sera encore un mot totalement différent.
Le schéma d’ensemble, c’est dès le départ un jargon répétitif, irritant et bas de gamme qui ne colle même pas.
Contrairement à l’explication selon laquelle ce ne serait que de « l’anglais nigérian de travailleurs contractuels », j’ai l’impression que les modèles sont en train de développer leur propre dialecte ultra-concis et excessivement formaté sous la pression du reinforcement learning. Ça donne de plus en plus l’impression d’écrire en code, mais pas au sens de code informatique. Les mots ne signifient pas exactement la même chose que pour les humains.
arc landest gravé dans mon cerveau à cause de Phabricator, donc je sais bien que ce terme existait avant les LLM, mais ça n’empêche pas que ça m’agace au plus haut point.Ce glissement linguistique est irréversible. Même si on pouvait filtrer à 100 % les entrées issues des LLM, les gens eux-mêmes sont en train d’apprendre à dire plus souvent « land ».
En ce moment, je travaille sur un projet avec quelqu’un qui n’utilise que des LLM, et c’est épuisant et mentalement usant.
Quand je fais un retour sur quelque chose, la réponse est simplement : « je vais demander à Claude ». Cette personne ne comprend pas comment l’ensemble fonctionne, et la majeure partie du code le reflète.
Il y a quelques jours, comme elle ne savait même pas configurer un environnement local et définir des variables d’environnement, elle a codé en dur un mode démo. Je suis aussi perplexe devant le fait que Claude ne l’ait pas su, mais c’est peut-être un problème de prompt.
J’essaie de limiter mon usage des LLM, et même quand j’en utilise, c’est uniquement pour des tâches extrêmement spécifiques. Pour moi, il n’y a que cette méthode qui fonctionne.
Franchement, je ne comprends pas comment les entreprises peuvent pousser à ce point la génération de code par IA. Même sur de petits projets, la compréhension du projet prend très vite du retard.
Maintenant, avec le code produit par LLM, on encourage les gens sans curiosité et on pénalise ceux qui réfléchissent en profondeur, ce qui permet à ce type de personnes de tenir.
À l’inverse, un ami dépense 10 000 dollars par jour en tokens d’agent pour essayer de construire quelque chose. C’est quelqu’un de très intelligent et un ancien développeur, donc ce n’est pas juste une psychose simpliste liée à l’IA.
J’essaie encore de comprendre. Évidemment, moi, je n’ai pas 10 000 dollars.
Vraiment épuisant. Depuis que j’ai commencé à travailler avec des LLM, ma production en tant que développeur solo a facilement été multipliée par 20. Je boucle même des projets clients qui, autrefois, auraient été trop ambitieux pour être pris en charge seul
Des fonctionnalités qui, dans d’anciennes bases de code, auraient traîné pendant des mois, voire seraient restées encore plus longtemps au stade de la planification, sont maintenant effectivement intégrées. La qualité globale a aussi énormément progressé, la couverture de tests est plus complète et, franchement, meilleure
Je construis aussi des projets perso à une vitesse folle. Les rôles se sont inversés : je traite l’agent comme si j’étais le client, et l’agent agit comme si c’était moi. Bien sûr, je suis un client plus technique, donc je donne la direction architecturale. J’utilise tous les jours des applis et des outils créés par l’agent, et grâce aux outils que j’ai faits, j’ai même résilié des abonnements SaaS
En regardant les appels d’outils, j’ai aussi eu le sentiment que je devais mieux maîtriser les principaux outils en ligne de commande, donc je me suis fait un plan d’apprentissage pour rattraper ça petit à petit chaque jour. Je revisite aussi d’anciens réglages que j’avais mis en place à l’époque où j’ai commencé à utiliser vim et tmux sans vraiment savoir ce que je faisais
En théorie, je pourrais garder ma productivité à son niveau d’avant et lire plus de livres, mais ça ne semble pas réaliste. Contrairement à la promesse selon laquelle « le travail diminue », j’ai l’impression qu’on est dans une énorme période de transition où la productivité et les attentes augmentent, et la révolution industrielle me semble être une comparaison assez juste
La hausse des attentes se manifeste à petite comme à grande échelle. Les agents polissent tellement bien la présentation des données que j’envoie désormais comme si c’était normal des rapports propres et visuellement percutants qui, auparavant, m’auraient demandé un temps considérable
Mais je suis fatigué. Je sprinte à fond pour abattre autant de travail que possible avant que Fable ne passe d’une offre par abonnement à un accès réservé à l’API. Et je ne comprends pas non plus comment les gens font pour consommer autant de tokens. Même en dormant à peine et en faisant tourner sur Fable autant de code que possible, je n’approche presque jamais la limite du forfait 20x max
Je me disais que je ralentirais quand ça baisserait, mais maintenant ça a été prolongé jusqu’au 12 et la fenêtre a été réinitialisée, donc je peux encore liquider du backlog pendant quelques jours. J’ai l’impression de devoir faire tourner les robots toute la nuit pour avoir quelque chose à relire dès le réveil. Même donner des consignes à l’agent depuis mon téléphone me paraît bizarre
Vu de l’extérieur, ça ressemble à mon père qui travaillait comme mécanicien dans un moulin. Son travail consistait surtout à surveiller les machines pendant qu’elles travaillaient, puis à les réparer quand elles tombaient en panne, et 90 % du temps tout tournait bien
Passer d’un travail manuel à de la simple surveillance de machines peut vraiment sembler ennuyeux, et sous cet angle je peux comprendre l’hostilité envers l’IA qu’on voit ici
On peut tous convenir qu’examiner des tas de code généré par IA dans le cadre du travail est épuisant, alors je me demande pourquoi étendre volontairement cette situation désagréable à l’ensemble de la journée
Soit tu codes simplement à la main, tu réfléchis devant un tableau blanc quand ça devient complexe, et tu t’épuises plus lentement, à un rythme plus humain, comme le fait l’ingénierie logicielle depuis plus de 50 ans
Je ne comprends pas pourquoi ce serait le choix à faire. Sérieusement, as-tu un minimum d’estime de toi ? Je m’attends à entendre l’excuse du « mais mon manager s’attend à ce que j’utilise l’IA ». Il est évident que la plupart des gens n’ont jamais vécu un vrai burnout. Quand ça te tombe dessus, la souffrance est immense. Il ne faut pas se transformer soi-même en machine. Les humains ne sont pas des machines
Je ne suis pas en burnout, mais je travaille de façon similaire à l’auteur. Je n’ai toujours pas réussi à construire un workflow où relire du code généré par LLM serait plus rapide que l’écrire moi-même
En réalité, il n’y a que deux façons de sortir de ce dilemme : faire aveuglément confiance à ce qui est généré, ou créer un ensemble anormalement vaste de tests unitaires pour valider tous les scénarios possibles
Donc j’écris moi-même la logique métier, et je laisse beaucoup d’autres parties au LLM. Le boilerplate fait aussi partie de cette seconde catégorie
Les tests adversariaux sont la meilleure façon de garder l’IA sur les rails et de rendre les modifications à lire propres et faciles. Ça vaut aussi bien dans une approche TDD du type « écris un test qui montre ce bug » qu’après coup avec « prouve via un nouveau test que ce patch est incorrect »
Une meilleure approche encore consiste à verrouiller davantage avec des langages à typage plus fort, mais les tests peuvent être écrits dans n’importe quel langage. Avoir une culture TDD et ce réflexe de « tout écrire en tests » ressemble à une sauce secrète quand on travaille avec l’IA
Je survole les tests, les templates, certains éléments d’UI, les détails cosmétiques, ce qui me fait gagner du temps. Mais la majeure partie du code qui entre dans un système backend doit être lue
Personnellement, les gens les plus enthousiastes à propos de la magie des LLM sont ceux qui ne savaient pas coder. Maintenant, ils peuvent au moins produire quelque chose qui fonctionne, même si ce n’est pas le meilleur code. Comme ils sont désormais capables de sortir du code fonctionnel, ils pensent que ça va rendre tout le monde meilleur, mais ils ne savent même pas si ce déchet est maintenable, ni même si c’est bel et bien un déchet
La raison pour laquelle je ressens un burnout lié aux LLM, c’est que je dois composer avec le fait que les modèles haut de gamme sont manifestement castrés et rétrogradés de façon opaque
Il y a encore 12 mois, les entreprises d’IA étaient obsédées par l’idée d’arracher les meilleurs résultats possibles à des modèles ordinaires
Mais à mesure que les modèles haut de gamme ont progressé, ces mêmes entreprises ont déplacé leurs efforts vers la réduction maximale de la quantité de calcul, donc du coût de production de chaque résultat, tant que cela ne se voyait pas trop
Ces 36 derniers mois, la courbe de qualité des résultats a grimpé de façon exponentielle, mais maintenant elle est presque plate
À mon avis, si les résultats stagnent, ce n’est pas parce que les modèles sont beaucoup moins compétents qu’il y a un an. C’est parce qu’économiser l’énorme coût de traitement d’une base d’utilisateurs surchargée passe avant l’objectif de suivre explicitement les instructions des utilisateurs et de produire le meilleur résultat possible. Surtout quand suivre ces instructions coûte plus cher en calcul
Avant, ils pouvaient rester plus de 7 minutes en mode réflexion. Par exemple, si je disais « trouve-moi des sources pour cette affirmation », ils cherchaient, analysaient et ajustaient eux-mêmes leurs requêtes. Aujourd’hui, même en mode « Pro », impossible de les pousser à travailler plus de 30 secondes, et ils ne sortent que des réponses génériques
Le moment Opus 4.5, c’était en novembre dernier, et c’est à ce moment-là que le code agentique et la plupart des outils CLI de codage sont devenus de vraies options de premier ordre. C’est un changement de paradigme énorme. GPT-5 n’était même pas encore sorti, et la plupart des gens utilisaient 4o. Ce qui est proposé aujourd’hui est bien supérieur à 4o pour le code
C’est comme être coincé à travailler avec des collègues qui ne sont pas ouvertement hostiles, mais qui répètent les mêmes erreurs tous les jours, qu’il faut constamment prendre par la main, et qui ne peuvent même pas être sincèrement désolés
Ce n’est pas parce qu’on travaille avec des ordinateurs qu’on échappe aux dommages sociaux. Dans ce cas, c’est peut-être plus proche de dommages parasociaux
C’est sérieusement la raison pour laquelle j’envisage de quitter la programmation
J’ai commencé à programmer parce que les problèmes de programmation m’intéressaient. Mais si le problème passe de « comprendre pourquoi une calculatrice a un écart de 1 en France » à « empêcher ce LLM de parsemer partout de mignons emojis », c’est peut-être le moment de changer de métier
En ce moment, je suis à fond dans l’eau pétillante et je construis moi-même un carbonateu continu. C’est un build complet, de la source d’eau jusqu’au robinet, avec pompes, pression, niveau d’eau et ventilateurs de refroidissement contrôlés par ESP32
Ça m’a aidé à repérer plein d’erreurs dans mon panier. Par exemple, le homebrew préfère du tube 8 mm, alors que les systèmes de filtration d’eau utilisent du 9,5 mm. J’ai optimisé le projet d’une simple pompe on/off avec interrupteur à flotteur vers une version proche d’un système PLC complet. J’ai eu beaucoup d’itérations en discutant avec « quelqu’un de plus expérimenté ». Dès que les pièces arrivent, je pourrai tout assembler et faire tourner le logiciel en moins d’une heure
Ça ne rapporte rien, mais c’est vraiment amusant
Le mieux que tu puisses faire, c’est empiler les hacks sur les hacks pour empêcher des sorties indésirables, mais au final, si le LLM décide qu’il n’a pas envie de suivre les instructions, il ne reste pas grand-chose à faire à part ajouter
*IMPORTANT*et espérer que le modèle suivant corrige çaCette expérience ressemble beaucoup plus au fait de travailler avec une API externe qu’on ne contrôle pas et qui ne se comporte pas comme la documentation l’annonce. Ça a toujours été l’un des aspects les plus frustrants de la programmation, mais avant, on pouvait au moins rétroconcevoir l’implémentation réelle pour contourner les bugs. Aujourd’hui, cette « frontière » change aléatoirement tous les jours, donc même ça devient impossible
Il suffit de 5 secondes pour mettre un petit guide de style dans
CLAUDE.mdouAGENTS.md, ou simplement écrire « interdiction des emojis », et les sorties des LLM deviennent tout de suite beaucoup plus supportables. Un petit guide de style avec des mots et expressions interdits aide aussiBien sûr, ça ne corrige pas les hypothèses erronées. Ça, il faut toujours les repérer à l’ancienne en lisant attentivement et en gardant un esprit critique
En revanche, si je lui demande de l’analyse de données ou de la modélisation, les emojis partent dans tous les sens
Vu ce que j’ai vu sur GitHub depuis un an, je ne laisserais absolument jamais un LLM rédiger sans supervision le README ou la documentation d’un projet