L’humain dans la boucle est épuisé

 (pydantic.dev)
2 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La programmation avec les LLM accroît la productivité tout en accentuant la fatigue de supervision, car les développeurs doivent continuer à contrôler l’intention et la qualité, ce qui fragilise la satisfaction et la durabilité du travail
  • Les modèles produisent rapidement du code plausible, mais peuvent perdre l’intention cohérente d’un changement complexe ; l’humain devient alors la porte de contrôle qualité chargée de relire et corriger un volume accru de résultats
  • Même si le nombre de tâches que l’on peut lancer explose, le volume de tâches que l’on peut terminer avec soin reste limité par le cerveau et l’attention humains ; les petites récompenses du codage diminuent tandis que la charge cognitive de la revue augmente
  • Dans les domaines que l’on comprend en profondeur, on peut guider efficacement les LLM ; dans ceux où l’expertise est superficielle, ils privilégient le plausible à l’exact, ce qui rend le goût et le jugement architectural encore plus importants
  • Le génie logiciel ne disparaît pas tant qu’il se réduit et se recompose ; la ressource rare n’est plus l’écriture de code elle-même, mais l’attention humaine, le jugement d’ingénierie et la capacité à maintenir une vision cohérente du système

Une programmation avec les LLM utile, mais instable

  • La programmation avec les LLM est réellement utile tout en étant instable, et ignorer cette instabilité peut conduire les développeurs au burn-out
  • L’équipe Pydantic traverse la même confusion en développant des outils de validation de données, de création d’agents IA et d’observabilité en production
  • Le point central n’est pas de savoir si l’IA remplace les programmeurs, mais comment l’expérience actuelle de développement a changé et ce qui peut l’améliorer

La sensation de fabriquer à la main

  • La programmation a longtemps offert une sensation de création : construire quelque chose uniquement par la logique et manipuler directement de profondes couches d’abstraction
  • Pour quelqu’un qui a appris le génie logiciel par essais et erreurs plutôt que par une formation classique en informatique, les principes d’architecture et de qualité du code ressemblent moins à des règles de manuel qu’à des cicatrices accumulées
  • Les outils low-code/no-code des années 2010 et des produits comme Dreamweaver promettaient déjà de créer sans code, mais généraient en interne du code spaghetti et n’ont jamais pleinement tenu leurs promesses
  • Les outils d’IA actuels ont, contrairement au passé, réduit de manière significative l’écart entre promesse et réalité, et c’est précisément ce qui les rend plus inquiétants

L’expérience réelle du « code qui s’écrit tout seul »

  • Le code s’écrit dans une certaine mesure tout seul, mais l’expérience humaine consistant à le relire, le diriger et corriger sa trajectoire peut, elle, se dégrader
  • Douwe, mainteneur de Pydantic AI, devait chaque matin relire environ 30 PR produites pendant la nuit par les IA d’autres personnes et juger chacune immédiatement
    • La tentation est forte de confier aussi la revue à l’IA, mais cela laisse ouverte la question de ce que fait encore l’humain
  • Même après presque deux jours passés à rédiger et clarifier à plusieurs reprises un plan à exécuter par un LLM, le modèle peut déplacer des hooks React dans des fichiers de stories Storybook, ou lire un mauvais plan et créer des composants inexistants
  • Ces échecs relèvent moins d’un simple manque de capacité que d’un manque de cohérence
    • Le modèle est assez intelligent pour produire du code plausible, mais peut ne pas maintenir une intention unique sur l’ensemble d’un changement complexe
  • L’humain doit conserver l’intention en tête tout en jugeant en continu une grande quantité de résultats « pour la plupart corrects », ce qui crée une nouvelle forme de fatigue de supervision
  • Dans l’open source, la récompense de construire des fonctionnalités avec de vraies personnes et d’aider l’autre à progresser diminue aussi
    • Quand le travail entre dans la boîte noire de l’IA, il n’y a personne de l’autre côté pour apprendre, et la satisfaction de la collaboration disparaît

Le piège qui intensifie le travail

  • L’étude de Berkeley Haas présentée par Simon Willison estime que l’usage de l’IA ne réduit pas la charge de travail, mais augmente plutôt l’intensité du travail
    • En fin de journée, la pression persiste d’entrer encore un prompt ou de terminer encore une fonctionnalité
    • Le sentiment que le plan est presque terminé peut mener à continuer à prompter jusqu’à près de 2 h du matin
  • Marcelo, chez Pydantic, plaisante en disant que si une session Claude Code se bloque, il faut en ouvrir cinq
    • Autrement dit, si l’on est occupé à donner du feedback à d’autres sessions, on ne remarque même pas qu’une session s’est arrêtée
  • Le travail en parallèle augmente fortement le nombre de choses que l’on peut commencer, mais pas le nombre de choses que l’on peut terminer avec soin
    • Terminer exige une ressource impossible à paralléliser : le cerveau humain

La panne de la fonction de récompense humaine

  • Tout comme la fonction de récompense du machine learning définit les bons résultats pour un agent, le codage manuel offrait ses petites récompenses : résoudre un problème, comprendre une logique complexe, réussir une compilation, ressentir un contrôle
  • La programmation assistée par LLM automatise les tâches qui produisaient ces récompenses dopaminergiques et les remplace par la charge cognitive de la revue et de la supervision
    • Les parties satisfaisantes diminuent
    • Les parties épuisantes augmentent
    • Il n’existe pas encore de nouvelle récompense pour combler le vide
  • Le fait que la productivité augmente tandis que la satisfaction baisse n’est pas un défaut individuel, mais une panne de la boucle de feedback, à traiter comme un problème d’ingénierie à part entière

Isolement et récompense variable

  • La programmation avec les LLM peut devenir une activité très solitaire, où l’humain et la machine répètent prompts, corrections et revues
  • Les moments où l’on posait une question à un collègue, où l’on verbalisait un problème ensemble et où l’on partageait la petite joie d’une solution sont remplacés par un prompt supplémentaire
  • Dans les équipes dont la culture de collaboration est déjà faible, la communication entre personnes peut encore se contracter, et il devient plus difficile de vérifier que les autres rencontrent aussi des difficultés
  • Le fait que les résultats soient parfois excellents et parfois mauvais, sans qu’on puisse le savoir à l’avance, crée une structure de récompense variable comparable à une boîte de Skinner
  • On peut toujours écrire directement du code quand c’est nécessaire, mais le travail assisté par LLM et le travail manuel reposent sur des modes de pensée très différents, ce qui rend le passage de l’un à l’autre inconfortable
    • S’autoriser à alterner entre les deux demande de la maturité et de la confiance en soi

Une analogie avec la transition vers le responsive design

  • Vers 2009, quand le Web est passé des mises en page à largeur fixe, au pixel près, au responsive design fluide, les designers ont eux aussi vécu une perte de contrôle
  • Pour ceux qui avaient construit leur identité et leur expertise sur des mises en page précises et des grilles parfaites, l’idée qu’un design s’adapte à des largeurs d’écran et des appareils arbitraires représentait un changement fondamental
  • Les designers qui se sont adaptés à cette transition n’ont pas abandonné leurs compétences existantes, ils les ont reconfigurées
    • Le sens des proportions et la compréhension de la hiérarchie restaient importants
    • L’obsession du contrôle au pixel près l’était moins
    • La conception de systèmes, d’adaptabilité et d’incertitude devenait plus importante
  • La transition actuelle vers l’IA est beaucoup plus rapide que celle du responsive design, et les enjeux sont différents
    • Le changement du responsive design s’est étalé sur des années, alors que le changement actuel se joue en quelques mois
    • À l’époque, des agences perdaient des clients et des designers perdaient du travail, mais cela ne s’accompagnait pas de la même anxiété existentielle qu’aujourd’hui
  • Malgré tout, le schéma selon lequel les compétences évoluent plutôt que de disparaître, et où les capacités clés deviennent plus importantes, s’applique aussi au codage basé sur les LLM
  • Même si un ingénieur n’écrit pas chaque ligne de code lui-même, sa valeur ne diminue pas nécessairement ; mais comme il devient la porte de contrôle qualité d’un volume de résultats bien plus élevé, sa capacité à distinguer le bon résultat devient plus nécessaire

L’expertise qui survit et les nouvelles façons de travailler

  • Dans un environnement où tout le monde peut produire une UI plausible et du code qui compile, le goût et la nuance, un jugement architectural mûr et des décisions non consensuelles fondées sur une vraie expertise deviennent des différenciateurs
  • Plus on comprend en profondeur le code, les décisions et les compromis d’un domaine, plus on peut guider un LLM avec succès
  • Plus l’expertise est superficielle, plus les résultats s’éloignent du niveau prêt pour la production et se rapprochent d’un état impressionnant mais simplement plausible plutôt que réellement correct
    • Le modèle ne sait pas ce qu’il ignore et comble les trous avec assurance, un mode d’échec qui existe aussi chez les humains
  • Pour les plans complexes, on peut utiliser un pré-mortem
    • On demande à une nouvelle session LLM de supposer que le plan a échoué de façon catastrophique, puis d’en diagnostiquer les causes
    • Cela aide à repérer des lacunes dans les spécifications que la personne plongée dans les détails pendant deux jours a pu manquer
  • Un ingénieur de Pydantic a développé un outil qui extrait des règles à partir de milliers de commentaires de revue de code passés pour en faire des consignes initiales dans un fichier AGENTS.md
    • Cela revient à une distillation de l’expertise : transformer des années de jugement d’ingénierie accumulé tacitement en consignes qu’un LLM peut suivre
  • Les personnes qui s’adaptent à ce changement disposent de critères de jugement solides acquis dans la pratique, et savent distinguer les principes encore valables des habitudes nées d’anciennes contraintes de bande passante
  • Elles sont prêtes à changer leur flux de travail sans abandonner leurs standards

La ressource rare révélée dans la boucle

  • La vague actuelle d’IA ne mettra pas fin au métier d’ingénieur logiciel, mais elle peut provoquer une contraction sévère et une reconfiguration fondamentale du secteur
  • Les craintes d’être évincé, de voir ses compétences s’atrophier ou d’être dépassé si l’on n’avance pas assez vite sont légitimes
    • La dernière inquiétude est parfois exagérée, mais elle n’est pas totalement infondée
  • Le véritable goulot d’étranglement n’était pas le code, mais l’attention humaine, le jugement d’ingénierie et la capacité à maintenir une vision cohérente du système
  • Parce que l’écriture de code semblait être la partie difficile, ce goulot d’étranglement était auparavant peu visible ; à mesure que l’écriture s’automatise, il devient clair que les capacités humaines sont la véritable ressource rare
  • Les développeurs peuvent être plus productifs tout en étant moins heureux et plus instables, et les équipes qui créent les outils traversent les mêmes problèmes en ajustant leur fonction de récompense en temps réel
  • Le code et les façons de développer changent, mais l’humain reste dans la boucle ; l’état central du moment est la fatigue du participant humain

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires sur Hacker News

  • Plus le codage manuel était difficile, plus les petites récompenses comme résoudre le problème, comprendre la logique, réussir la compilation et garder le contrôle étaient fortes. À l’inverse, le codage par agent demande en permanence une supervision similaire quelle que soit l’ampleur de la fonctionnalité ; au début, c’est grisant, comme surfer sur une vague de productivité, mais les aspects satisfaisants diminuent, la charge cognitive de la relecture augmente, et on s’épuise vite

    • J’ai plus peur de finir par détester le travail lui-même que de perdre mon emploi. Les tâches pour lesquelles donner des instructions à un LLM ne fait guère gagner de temps, je les fais moi-même, et je retravaille aussi la structure de sortie pour qu’elle soit plus facile à comprendre humainement, afin de garder le contrôle
    • Ma motivation vient moins de la manière dont le code a été produit que du fait que davantage de gens utilisent utilement le produit créé. J’ai toujours privilégié l’utilisateur et pris des raccourcis si nécessaire, et je peux encore trouver l’équilibre entre code maintenable et vitesse de livraison même en utilisant un LLM
    • Le développement pourrait passer d’un métier du savoir à un travail d’usine peu rémunéré. Guider un LLM demande bien moins de connaissances et d’expérience qu’écrire soi-même, et sur LinkedIn, on voit déjà recruter comme ingénieurs IA des gens avec très peu d’expérience ou un niveau junior
    • Je ressens de la dopamine quand l’IA crée elle-même une boucle pour tester sa sortie. Plus l’automatisation façon Rube Goldberg était poussée — faire en sorte que Codex pilote à distance un dongle clavier réseau-USB-C, un Fingerbot et même une webcam pour activer l’hibernation sur un portable précis et un noyau Linux précis — plus c’était satisfaisant
    • Sur des projets personnels, je peux créer des fonctionnalités plus facilement tout en obtenant des résultats plus soignés et cohérents, ce qui augmente au contraire ma satisfaction. En me concentrant un mois sur un projet, j’obtiens des résultats plutôt bons, et comme les réécritures et réorganisations structurelles coûtent moins cher, je peux en réalité explorer bien plus largement l’espace de conception. Cela reste souvent frustrant : pour moitié un problème de contexte que je fournis, pour moitié une limite intrinsèque du modèle

  • J’utilise Claude avec plaisir au travail et sur des projets personnels, et l’essentiel est d’éviter la tentation de l’agent et de le traiter comme un générateur de code. Je n’ouvre qu’une seule session, j’affine suffisamment le plan, puis je regarde l’exécution étape par étape ; si je révise et redirige à la fin de chaque étape, je garde aussi une bonne vision de l’état du code à la fin
    Pour l’utiliser de façon proche du one-shot, il faut détailler à l’étape de planification non seulement l’architecture, mais aussi le code réel qui déterminera les décisions majeures. Comme le coût du refactoring n’a jamais été aussi bas, je corrige immédiatement avec le LLM ce qui est difficile à comprendre, mais en veillant à ce que un seul LLM ne fasse qu’une seule chose à la fois et en restant impliqué en permanence

    • Après plusieurs mois de travail avec Claude, j’ai appris un flux où l’on discute suffisamment des détails au début, quitte à construire l’ossature si nécessaire, puis on lance l’exécution ; j’ai résumé cela dans https://github.com/ctomkow/claude/blob/main/README.md. Je refactorise avec succès du code legacy longtemps repoussé vers une nouvelle architecture
      Donner carte blanche à Claude crée inévitablement un désordre et des difficultés qui finissent par épuiser. Si je code moi-même quand j’en ai envie et que je passe la main à Claude quand je suis fatigué, je peux aussi garder une sensation de contrôle sur la base de code
    • Je colle uniquement les extraits de code nécessaires dans une conversation complètement séparée de l’éditeur, j’y discute des contraintes et des idées, puis, si le résultat me convient, je le transfère dans l’éditeur pour retravailler davantage les noms et l’implémentation. Je fais moi-même les tâches claires ou agréables, et je dois aussi participer aux décisions d’architecture pour me sentir lié au projet et le comprendre en profondeur
    • Le vibe coding, même avec plusieurs boucles d’agents, épuise plus facilement que l’approche en outil d’assistance où l’on observe la sortie de près
    • Même en travaillant progressivement, quand quelqu’un d’autre relit, il doit considérer le résultat complet d’un seul coup avec un regard neuf, donc la charge de revue ne diminue pas
    • Je peux jongler entre deux flux de travail au maximum, mais au-delà, le changement de contexte m’épuise complètement mentalement

  • Quand je relis le code de collègues ou de subordonnés, l’essentiel de mon énergie mentale part à prendre en compte non seulement la validité technique du retour, mais aussi l’ego, les différences de point de vue architectural, le ton poli, la charge de travail supplémentaire et la dynamique d’équipe. À l’inverse, avec un LLM, pas besoin de se soucier de l’impact émotionnel, donc la revue et le recadrage sont bien plus faciles

    • Si je sais qu’un collègue va renvoyer mon feedback à une IA, j’écris alors davantage à destination de l’IA que d’une personne, et je transmets une liste de corrections bien plus courte et directe
    • En tant que lead technique, j’ai toujours dû affronter des réactions du type « ça suffit largement » sur chaque PR, alors qu’avec un LLM, je peux simplement exiger de refaire correctement sans résistance, ce qui est confortable

  • Au travail, on a commencé à parler de Human on the hook plutôt que de human in the loop. L’expression décrit plus précisément une structure où, si tout se passe bien, l’humain n’est pas crédité, mais si ça tourne mal, il en porte la responsabilité — autrement dit, l’humain ne compte vraiment que quand il y a un problème

  • Écrire du code en soi n’a jamais été la partie difficile pour moi. Dactylographie rapide, édition modale de Vim, commandes Unix, scripts et raccourcis, Git, refactoring via l’IDE, Java : quand je sais quoi construire, je travaille à la vitesse de la pensée
    Les moments où je bloque ne viennent ni de la frappe ni de la syntaxe, mais du fait de réfléchir à la forme du code et au bon changement à apporter ; et quand ça se complique, je crée de meilleures abstractions, de meilleurs outils IDE ou des pipelines Unix incluant sed. Donc le goulot d’étranglement n’était pas l’écriture du code mais la réflexion et le jugement
    Si le codage par IA ressemble à un si grand bond, c’est peut-être parce qu’il y a plus de développeurs qu’on ne l’imagine qui n’ont jamais rencontré de très bons outils ou ne les ont pas vraiment maîtrisés. Si j’avais eu 20 ans aujourd’hui, j’aurais sans doute passé moins de temps à apprendre ces techniques, mais le moment où le génie logiciel est devenu fascinant pour moi, c’est quand j’ai compris que rien de tout cela n’était magique

    • La formule « l’IA semble bien faire les choses auxquelles on n’est pas soi-même très bon » sonne juste. Si on maîtrise mal la programmation, la sortie de l’IA paraît rapide et excellente ; mais pour un développeur expérimenté, une fois additionnés les instructions, l’attente, la persuasion, les corrections et le refactoring, ce n’est pas forcément plus rapide que de le faire soi-même
      De la même façon que je suis mauvais en dessin et que l’art généré par IA me paraît impressionnant, la programmation par IA peut être évaluée selon le même principe

  • La fatigue que ressentent beaucoup de gens vient d’une perte de contrôle née de la combinaison entre une accélération plus forte et une confusion plus grande. Les LLM se situent quelque part entre le génie et le nourrisson, et les regarder depuis la banquette arrière est à la fois excitant et effrayant
    Après avoir roulé vite pendant un moment, on finira peut-être par se rendre compte que marcher n’était pas si mal, et qu’on avait même plus de chances d’arriver à la destination voulue

  • Le code avec un LLM donne l’impression d’actionner le levier d’une machine à sous comme un rituel, puis de recommencer en espérant que ça marche cette fois. Dans la programmation classique, les erreurs ont des causes cohérentes, et tout est conçu pour comprendre ces causes et les éliminer si possible de façon permanente. Un développeur expérimenté n’essaie pas au hasard puis, si ça marche, ne classe pas ça comme un succès dont il ignore la raison
    Si vous êtes déjà épuisé à force de gérer des parties prenantes incapables de se mettre d’accord ne serait-ce que sur ce qu’est le système, vous saviez peut-être depuis longtemps que l’attention humaine et le jugement d’ingénierie étaient le véritable goulot d’étranglement

    • Quand j’ai appris à coder et que je créais des applis web, je restais accroché à mon ordinateur jusqu’au bout de la nuit à me demander à l’aveugle « si j’essaie ça, est-ce que ça va marcher ? ». Puis, avec l’expérience, les langages typés, les compilateurs et les LSP, j’ai compris ce qui allait fonctionner, et j’ai pu entrer dans un état de flow satisfaisant au lieu de cette dépendance aux suppositions
      Coder avec Claude donne l’impression de revenir à cette phase de tâtonnement, donc je n’en veux pas. En revanche, dans des domaines où les suppositions à l’aveugle étaient déjà nombreuses, comme les tâches de type DevOps qui consistent à raccorder des API complexes et plusieurs composants, le dialogue avec un LLM est le plus utile
    • Désormais, au lieu de se mettre d’accord, les parties prenantes utilisent des LLM pour produire des plans mal dégrossis et des objectifs de branchement, puis confient entièrement aux LLM la conception, les user stories, les détails techniques, l’implémentation et même la revue de code. Tout au long du processus, la pensée critique et la vérification disparaissent, et ne s’accumulent plus que des documents de conception et du code aux objectifs flous, devenus difficiles à suivre
      Les plans peuvent changer à tout moment, et il devient aussi bien plus probable que tout soit réécrit sur un coup de tête

  • Je comprends l’idée centrale du texte, mais on sent partout le style propre à Claude, et lire un texte que quelqu’un a écrit avec l’IA est encore plus fatigant

    • Plus qu’un texte directement écrit par une IA, il a probablement subi de l’édition et de la relecture pour correspondre à un style d’entreprise. Les LLM eux-mêmes ont aussi été entraînés sur ce type de style
    • La majeure partie a été écrite par une IA, mais il y a bien plus d’intervention humaine que dans un texte d’IA ordinaire, donc ça me gêne moins que d’habitude
    • À voir des tics de style comme la répétition de “It’s not” et l’usage des tirets, j’en conclus que c’est écrit par une IA
    • Si quelqu’un n’a pas pris la peine de l’écrire lui-même, moi non plus je n’ai pas envie de prendre la peine de le lire

  • Cela me rappelle le texte de 2021 The Animal is Tired : https://www.robinhobb.com/blog/archives/2021-05

    • Le site original bloque les IP, donc on peut le lire sur un miroir moins restrictif : https://archive.is/RWxXP. Sentir son propre déclin est peut-être la plus grande des tristesses, et cela arrive à tout le monde
      Même si l’on avait davantage ménagé son corps, on aurait peut-être fini au même point en perdant au passage de précieux souvenirs. Il faut prendre soin de son corps, mais sans le traiter comme une potion de jeu vidéo qu’on n’utilise jamais jusqu’au bout au cas où il en faudrait pour le prochain combat. Chaque partie de notre corps ne peut être sacrifiée qu’une seule fois pour un but plus grand, ou pas du tout
      Rien que d’y penser me fait pleurer ; je suis encore en pleine crise émotionnelle

  • La communication de recherche de Berkeley Haas selon laquelle l’usage de l’IA augmente l’intensité du travail est frappante, mais plus de 5 mois après la publication de l’article HBR https://hbr.org/2026/02/ai-doesnt-reduce-work-it-intensifies... et du dossier de presse https://newsroom.haas.berkeley.edu/ai-promised-to-free-up-wo..., il reste impossible de trouver l’article scientifique lui-même ou même un preprint
    À ce stade, tout ce que l’on sait, c’est qu’il s’agit d’environ 40 entretiens qualitatifs menés dans une seule entreprise d’un seul secteur ; sans vérifier la méthode, il est difficile d’évaluer la fiabilité des conclusions