Tours bancales, malaise du vibe et bobsleigh du vibe

• À mesure que se répand une façon de développer où l’on confie de nouveau à un LLM l’interprétation de code qu’un humain ne comprend pas, la frontière autrefois nette entre agentic engineering et vibe coding s’estompe rapidement
• Le bobsleigh du vibe désigne une trajectoire prédéfinie qui mène de l’autocomplétion à la génération de code, puis à l’abandon de la revue, et enfin à l’abandon du prompt ; plus on exploite la vitesse de génération, plus on s’éloigne des rôles essentiels du programmeur que sont la construction de théorie et la revue
• Dans l’expérience Pvote, des experts en sécurité, bien qu’ils connaissent à l’avance l’emplacement des bogues, n’ont pas trouvé le bogue difficile parmi trois après avoir passé environ 20 heures à examiner 100 lignes de code, montrant que l’hypothèse selon laquelle des humains pourraient relire intégralement de grands volumes de sorties de LLM est irréaliste
• Le malaise du vibe se répand à mesure que du code et des productions non compris s’infiltrent dans des affiches de restaurants, des chatbots de support client, du code de vérification d’âge, ainsi que des issues et PR open source ; même les personnes qui n’utilisent pas ces outils sont affectées, car elles doivent examiner les productions des autres
• L’IA générative peut être utile pour détecter des problèmes, mais elle est particulièrement fragile lorsqu’il s’agit de générer ; même si des systèmes incompréhensibles remplacent le monde existant, il ne faut pas renoncer à la capacité humaine de construire directement de meilleurs environnements

---

La tour de code incompréhensible

• The Tower Keeps Rising observe un état dans lequel, même dans des situations qui auraient autrefois nécessité une discussion entre membres d’une équipe, il est désormais possible de continuer à avancer grâce à des agents
  • Armin ne juge pas cela bon ou mauvais, et ne le défend pas non plus comme un état durable
  • Il se trouve toutefois en position de faire progresser cette tendance, puisqu’il dirige une entreprise de vibe coding
• Les systèmes de vibe coding peuvent continuer à empiler du code et des abstractions jusqu’à atteindre finalement un état où aucun humain ne comprend plus la base de code
  • Une nouvelle façon de fonctionner apparaît : même les parties qu’un humain ne comprend pas peuvent être réinterprétées par un LLM, ce qui permet de poursuivre le développement
• Même les partisans de cette approche reconnaissent le point d’arrivée où les humains ne comprennent plus le système, et un glissement apparaît qui consiste à accepter cet état comme la manière dont le développement se fera à l’avenir

L’effondrement de la frontière entre agentic engineering et vibe coding

• Simon Willison a d’abord clairement distingué l’agentic engineering du vibe coding
  • Dans un article de mars 2025, il posait le principe selon lequel, pour de la programmation assistée par IA de qualité production, il fallait lire tout le code committé dans le dépôt et pouvoir l’expliquer précisément à quelqu’un d’autre
  • Même si le code est écrit par un LLM, il distinguait cela du vibe coding et le qualifiait de développement logiciel si un humain le relit, le teste rigoureusement et peut en expliquer le fonctionnement
• Environ un an plus tard, dans Vibe coding and agentic engineering are getting closer than I’d like, il explique que la fiabilité croissante des agents de codage l’a conduit à ne plus relire chaque ligne, même pour du code de production
  • Il fait confiance à Claude Code pour créer correctement un endpoint d’API qui exécute une requête SQL et renvoie du JSON, et pour ajouter les tests et la documentation
  • Dans le même temps, il éprouve de la culpabilité et s’interroge sur la responsabilité qu’implique l’utilisation en production de code qu’il n’a pas relu
• L’écart entre ces deux positions n’est que d’un peu plus d’un an
• L’idée selon laquelle l’agentic engineering serait le bon usage s’est largement répandue, mais les utilisateurs réels, Simon compris, semblent être attirés vers le vibe coding

Le bobsleigh du vibe

• Le bobsleigh est un sport où l’on descend très vite une piste de glace, mais où il n’existe en pratique qu’une seule direction possible
  • Les athlètes peuvent mesurer leur maîtrise et ressentir des sensations fortes, mais les passagers ont peu de latitude pour choisir le trajet lui-même
• Dans le bobsleigh du vibe, le LLM est le véhicule et l’utilisateur le passager
  • Le contrôle réel est bien moindre que ce que l’utilisateur ressent ; il s’agit moins d’une simple pente glissante que d’un parcours préparé à l’avance
• Le développeur se retire du processus de production de code en passant par les étapes suivantes
  • Au début, il pense ne l’utiliser que comme autocomplétion avancée
  • Ensuite, il lance un agent pour explorer des idées, tout en affirmant qu’il écrira le code lui-même
  • Puis l’agent génère le code, mais il se promet d’en relire tous les résultats
  • Bientôt, il relit à peine le code et commence à croire que l’agent pourrait être un meilleur développeur que lui
  • Enfin, il peut aller au-delà du « je ne code plus » vers l’étape où « je n’écris même plus de prompts »
• Chaque étape est un déplacement vers une production de code fondée sur la confiance, où l’on suppose que le LLM comprend son travail et le mène bien

Le conflit entre vitesse de génération et revue

• Dans le codage, ce qui est lent n’est pas la génération mais la construction de théorie et la revue ; des résultats plausibles mais incorrects sont très difficiles à déboguer et à comprendre
• La propriété la plus puissante des LLM est leur vitesse de génération ; si un humain relit tous les résultats, il devient difficile d’exploiter pleinement cette vitesse
• En revanche, la construction de théorie et la revue sont les rôles les plus importants du programmeur : plus on maximise l’avantage des LLM, plus on s’éloigne donc du cœur du métier
• L’article de Ka-Ping Yee, Building Reliable Voting Machine Software, identifie quatre facteurs qui rendent la vérification logicielle difficile
  • Le nombre de composants
  • Les interactions complexes
  • L’ampleur des effets
  • La non-linéarité
• Ces quatre problèmes peuvent être aggravés par la manière dont les LLM génèrent du code

L’expérience de revue des bogues de Pvote

• Ka-Ping Yee et David Wagner ont inséré dans la machine de vote modèle Pvote un bogue facile, un bogue moyen et un bogue difficile, chacun pouvant être exploité pour modifier le résultat d’une élection
• Les trois bogues ont tous été placés dans une zone de 100 lignes, les lignes 11 à 109 de Navigator.py
  • C’était une partie intéressante du point de vue de la logique du programme, et un choix tenant compte du temps limité des relecteurs
  • Les relecteurs ont été informés de la zone à examiner, mais pas du nombre de bogues
• Les résultats de la revue du troisième jour ont été les suivants
  • Dan Sandler, très à l’aise avec Python, a trouvé le bogue facile et le bogue moyen en environ 70 minutes
  • Yoshi Kohno et Mark Miller ont trouvé le bogue facile après environ 4 heures
  • Personne n’a trouvé le bogue difficile
• Le quatrième jour, Ian Goldberg a trouvé le bogue facile en environ 2 heures, mais n’a pas découvert les autres
• Ces experts en sécurité chevronnés connaissaient pourtant l’emplacement, mais même avec environ 20 heures-relecteur au total, ils n’ont pas trouvé les trois bogues
• Mark S. Miller a ensuite été surpris de constater qu’après avoir vu les bogues, tout le monde s’accordait à dire qu’ils étaient évidents et qu’ils auraient dû les trouver
• Si même des programmeurs de tout premier plan ratent des bogues dont ils savent qu’ils existent dans 100 lignes, une approche consistant à demander à des humains de relire l’énorme volume de sorties des LLM devient ingérable
  • Au bout du compte, les utilisateurs abandonnent la revue et se retirent progressivement du processus de production du code

Psychose IA et malaise du vibe

• « AI psychosis » est largement employé pour désigner toutes sortes de mauvais comportements ou résultats causés par l’IA générative, mais à l’origine le terme renvoyait plutôt à un état proche d’une psychose réelle et d’une perte délirante de contact avec la réalité, provoqué par l’interaction avec des chatbots excessivement flatteurs envers l’utilisateur
• Pour le malaise plus diffus causé par l’IA générative, sans relever d’une psychose clinique, malaise du vibe (vibe sickness) convient mieux
• Dans le retour de Glyph sur PyCon US 2026, les situations suivantes apparaissent simultanément
  • Un malaise du vibe généralisé
  • Une crise massive et durable de soutenabilité de l’open source
  • Une inondation de PR de sécurité de mauvaise qualité
  • De l’espoir, de l’énergie et des efforts pour la compréhension mutuelle, ainsi que de la gratitude pour le travail accompli

Des productions qui se répandent dans le quotidien et l’open source

• Les gens se plaignent des productions de mauvaise qualité, du slop, mais les utilisateurs d’IA générative ne qualifient pas leurs propres résultats de slop
• Des productions plausibles mais incompréhensibles apparaissent partout dans le quotidien
  • Des affiches de restaurants locaux au design difficile à comprendre
  • Des chatbots de support client qui frustrent les utilisateurs
  • Du code de vérification d’âge
  • Des issues et PR de mauvaise qualité soumises à des projets open source
• Ces outils sont utiles pour certaines tâches, et il existe une marge pour les évaluer différemment lorsqu’il s’agit de détecter des problèmes
• Mais la génération, mise en avant par le nom « genAI », est justement ce que ces outils font le moins bien
  • Le problème ne porte pas seulement sur la qualité des productions, mais aussi sur le fait que personne ne comprend la manière dont les systèmes sont construits, structurés et maintenus

Un environnement dont on ne peut pas s’extraire

• Même sans utiliser directement l’IA générative, des collègues ou des contributeurs open source peuvent envoyer comme « contribution » des productions qu’eux-mêmes ne comprennent pas
  • Le relecteur doit se demander s’il serait impoli de demander si elles ont été générées par un LLM
  • En répondant à des issues ou des PR, il interagit indirectement avec un agent et se retrouve malgré lui intégré à un flux de travail de vibe coding
• Glyph compare le refus de tout logiciel contenant un LLM au fait de retenir son souffle jusqu’à ce que tout le monde cesse d’utiliser l’essence sans plomb pour protester contre son introduction dans les voitures
  • En pratique, il faut bien l’accepter jusqu’à un certain point et se fixer une ligne éthique personnelle, mais cela ne signifie pas attendre ou accueillir avec enthousiasme l’environnement de l’IA générative
• L’uncanny valley envahit le monde réel, tandis que des systèmes que personne ne comprend remplacent le monde existant
• Le coût à payer pour se remettre de cet état n’est pas encore connu, et les projets qui choisissent de ne pas participer à l’IA générative actuelle méritent le respect

Choisir de construire un meilleur terrain

• Le travail ou l’environnement peuvent empêcher de refuser totalement de contribuer aux problèmes posés par l’IA générative
• Même si des automobilistes s’énervent contre les cyclistes sur la route, lorsque les infrastructures cyclables manquent, les cyclistes sont mis en danger par les portières de voitures stationnées ou par des conducteurs impatients
• Si un vélo se trouve devant vous lorsque vous conduisez, vous pouvez être reconnaissant de sa présence et réfléchir à la manière de changer le terrain et les infrastructures pour que les vélos puissent participer plus en sécurité
  • Ce type de changement facilite la conduite automobile et rend aussi plus facile le choix du vélo selon les situations
• Plutôt que de s’en remettre aux trajectoires imposées par la technologie, il ne faut pas renoncer à l’idée que les humains peuvent participer directement à la construction d’un monde meilleur

[GN⁺]

Commentaires sur Lobste.rs

• De loin l’un des meilleurs textes récents sur les évolutions inquiétantes du secteur de l’ingénierie logicielle

• Il y a encore un an, l’ingénierie agentique semblait être une direction souhaitable, mais la plupart des utilisateurs réels de ces outils semblent pencher vers le vibe coding, même s’ils rechignent à l’admettre. La peur que les LLM rendent mes compétences et mon attachement au métier inutiles a beaucoup diminué après que j’ai posé deux principes.
  Premièrement, pendant mon temps libre, je n’utilise ni LLM ni agents de codage, et je refuse aussi les fonctions IA des moteurs de recherche. Je ne les utilise qu’en cas de besoin assez pressant pour accepter le risque d’hallucinations. Faire comme si la technologie n’existait pas ne résoudra pas le monde, mais comme je ne peux ni attaquer des développeurs individuels ni faire changer les grandes entreprises, ne pas la laisser envahir mes loisirs est un choix réaliste.
  Deuxièmement, même au travail, où l’usage de l’IA est fortement encouragé, je ne m’en sers que pour la revue de code et les petites courses. Je lui demande surtout des choses que je pourrais trouver moi-même dans la base de code, mais qui seraient pénibles à chercher ; tout le code, je l’écris moi-même. C’est ainsi que je garde une compréhension intuitive de son fonctionnement et que je peux travailler au niveau attendu par moi-même et mes collègues.
  Les LLM sont un bon outil d’appoint pour repérer des erreurs de motifs que les linters déterministes ne détectent pas. Ils donnent aussi des réponses absurdes, mais comme j’écris et comprends le code moi-même, je ne leur fais pas confiance aveuglément. Filtrer les erreurs logiques évidentes et les mauvaises hypothèses avant la revue humaine permet aux collègues de se concentrer sur les parties plus complexes, et évite aussi l’impolitesse qui consiste à faire dialoguer des machines à la place des gens sur des canaux publics.
  Récemment, mon entreprise a strictement limité l’usage des tokens, mais mon flux de travail ne coûtant qu’un ou deux euros par jour, cela ne m’inquiète pas. Ceux qui s’en remettaient entièrement à leur intuition peuvent être anxieux à l’idée de devoir de nouveau utiliser le raisonnement humain, mais pour les autres, il suffit de faire le travail directement avec les collègues.

  • La critique du type « est-ce que mettre la tête dans le sable va vraiment résoudre le problème ? » n’est pas formulée par un tiers réel, mais par un critique imaginaire que l’on fait parler soi-même. Plus je fais des choix en tenant compte de ce genre de critique, plus ma vie se dégrade, donc j’essaie moi aussi de m’en méfier.
    Il y a aussi là-dessous une épistémologie masochiste, l’idée qu’il faudrait regarder la vérité en face d’autant plus qu’elle est douloureuse. Éviter des informations pénibles peut donner l’impression de manquer de vertu, mais notre attention est limitée ; mieux vaut l’employer à ce qui nous rend plus heureux et plus épanouis, et nous donne la force de continuer demain.
  • Cela ressemble moins à mettre la tête dans le sable qu’à « je n’aime pas aller au bureau, donc pendant mes loisirs j’évite le bureau ». S’il est possible d’éviter quelque chose de désagréable, il est rationnel de le faire.
    Ceux qui traitent chaque aspect de leur vie comme un travail à optimiser et dans lequel il faut être le meilleur finissent plutôt par y perdre. Si vous aimez coder, faites-en aussi pendant vos loisirs ; si vous n’aimez pas ça, vous pouvez le garder comme simple métier. Pendant le temps libre, il est parfois acceptable d’être inefficace ; sinon, ce temps libre devient un deuxième emploi et l’on ne se repose jamais vraiment.

• Le fait que l’orthographe de Fawlty soit incorrecte ici me dérange beaucoup trop.

  • Il me semble que c’est volontaire, comme un jeu de mots sur une tour de Babel « fautive » qui cause des problèmes.

• Comme toujours, l’article est excellent, mais je ne pense pas qu’il faille se demander s’il serait impoli de demander si c’est une production de LLM. Que le processus de création ait utilisé ou non un LLM, si l’on reçoit un résultat médiocre, on peut dire que la qualité est mauvaise et que cela ne nous plaît pas.

  • S’il s’agit d’un nouveau contributeur qu’on ne connaît pas, il est raisonnable de pointer les problèmes de qualité de la PR et de lui renvoyer la responsabilité de les corriger. Cela dit, si je me souviens bien, le projet Zig avait adopté une politique anti-IA parce qu’il voulait accompagner directement les humains, et non les LLM, afin de transformer de nouveaux contributeurs en contributeurs de long terme.
    En revanche, avec un collègue ou une personne avec qui l’on échange depuis longtemps en ligne, on peut vouloir éviter autant que possible d’être impoli afin de préserver la relation. Il faut savoir comment la contribution a été produite pour pouvoir en discuter, et le résultat peut aussi avoir volontairement un effet important sur la relation. Accepter le risque d’être impoli, ou au contraire éviter par défaut le conflit pour préserver la relation, relève d’un choix de tempérament.
    Comme j’ai moi-même plutôt tendance à éviter les conflits, je comprends le contexte de cette phrase, et je ne suis pas vraiment en désaccord avec l’argument de fond.

• J’aime bien la métaphore du bobsleigh. Je ne suis pas d’accord avec l’idée que les utilisateurs de LLM finissent nécessairement par descendre jusqu’en bas, mais elle décrit mieux les comportements observés dans le secteur que toutes les autres métaphores que j’ai vues jusqu’ici.

• La « métaphore du bobsleigh » est plus connue comme le sophisme de la pente glissante. Il y a un an, la part du vibe coding était de 0 %, et Simon Willison a publié plusieurs textes décrivant comment il introduisait prudemment des agents de codage et augmentait progressivement sa confiance.
  Pourtant, on s’en sert pour conclure qu’« il n’y a qu’une seule destination possible ». Il est plus raisonnable de considérer que Willison et les autres utilisateurs ont eux aussi des préférences et du discernement.