Bravo bravo bravo :)

Face à la phrase « X est l’avenir », ne faudrait-il pas avoir la sagesse de la filtrer spontanément comme « j’aimerais que X soit l’avenir » ?

Je compatis vraiment sur plein de points lol. À force d’être trop frustré, je me suis juste résigné et je suis passé en mode « je ne bosse qu’à hauteur de ce pour quoi on me paie », et ils trouvent même que, du coup, le travail avance plus fluidement. En réalité, ça veut juste dire que, même si je vois une orientation de développement risquée, je suis passé en mode « pas mon problème ».

https://fr.news.hada.io/topic?id=21170
C’est un bon complément à lire avec cet article.

> Cependant, le modèle d’autorisation n’étant pas implémenté, il est impossible de contrôler les permissions du token (merci de me corriger si je me trompe)

C’est actuellement pris en charge.

https://code.visualstudio.com/updates/v1_107/…

1. « La rapidité est un moteur » (camp positif)

• Position : l’IA prend rapidement en charge les tâches ennuyeuses, ce qui redonne au contraire de l’énergie, et elle réduit aussi le coût d’apprentissage de nouvelles stacks techniques, ce qui est perçu positivement.
• Exemple : lors de l’utilisation d’un langage ou d’un framework peu familier, l’agent IA a permis de sauter l’étape d’apprentissage fastidieuse pour se concentrer directement sur l’implémentation.

2. « Débat sur la définition du vibe coding » (confusion terminologique)

• Débat : les avis divergent sur le fait que le « vibe coding » désigne simplement le recours à l’aide de l’IA, ou bien le fait de ne vérifier que le résultat sans relire le code généré.
• Point d’accord : à l’origine, le terme avait une connotation négative, celle de « code non relu », mais son sens s’est aujourd’hui élargi pour désigner plus largement le coding assisté par IA.

3. « La vitesse sans vérification, c’est de la dette technique » (camp prudent)

• Critique : faire confiance uniquement au résultat généré par l’IA sans comprendre le code est risqué. Les bugs futurs ou les coûts de maintenance (dette technique) risquent d’être plus importants par la suite.
• Métaphore : c’est « comme monter dans une voiture autonome sans savoir où elle va » ; implémenter sans comprendre finit par affaiblir la capacité à résoudre les problèmes.

4. « La fatigue du changement de contexte » (camp empathique)

• Accord : pendant que l’IA génère du code, les changements de contexte fréquents (Context Switching) augmentent brutalement la charge cognitive.
• Symptômes : à force de relire et de corriger les résultats de l’IA, la dépense mentale devient plus lourde qu’en codant soi-même. Quatre heures de travail donnent l’impression d’avoir travaillé toute la journée.

5. « La perte du plaisir de coder » (manque de dopamine)

• Expérience : le sentiment d’accomplissement (dopamine) ressenti quand on résout soi-même un problème disparaît. C’est comme regarder un produit fini au lieu d’avoir le plaisir d’assembler soi-même des Lego.
• Résultat : produire rapidement des livrables sans le plaisir du processus finit par épuiser les développeurs.

6. « Un poison pour les débutants, un remède pour les experts » (différences selon le niveau)

• Analyse : les développeurs expérimentés repèrent et corrigent vite les erreurs de l’IA, ce qui augmente leur productivité ; les débutants, eux, risquent davantage de reprendre tel quel du code erroné, de perdre des occasions d’apprentissage et de produire du mauvais code en série.

7. « Passage forcé à un rôle de manager » (changement de rôle)

• Phénomène : le développeur passe de « créateur » qui écrit directement le code à « manager/relecteur » chargé d’examiner et corriger le flot de code produit par l’IA.
• Charge : cela provoque un stress intense, comparable au fait de relire en temps réel, seul, le code écrit par cinq développeurs juniors (IA).

8. « L’absence de compréhension de la logique métier » (mise en lumière des limites)

• Problème : l’IA sait bien écrire du code, mais elle ne comprend ni le contexte métier ni l’architecture d’ensemble.
• Réalité : au final, l’ajustement des exigences métier au code et le traitement des edge cases restent des tâches complexes qui incombent toujours aux humains, ce qui crée des goulets d’étranglement dans ce processus.

9. « Disparition des pauses et de la marge de manœuvre » (temps machine)

• Métaphore : comme autrefois les ouvriers d’usine devaient suivre le rythme des machines, les humains se retrouvent enfermés dans un « temps machine », entraînés par la vitesse de génération de l’IA.
• Nécessité : les « pauses forcées » comme le temps d’attente de compilation disparaissent, et le cerveau n’a plus le temps de traiter l’information ni de se reposer. Des pauses intentionnelles deviennent indispensables.

10. « Un problème transitoire de l’outil » (perspective d’avenir)

• Diagnostic : la fatigue actuelle vient du décalage entre la vitesse de génération de l’IA et des outils de validation (tests, lint, etc.) qui ne suivent pas.
• Solution : si des outils capables d’automatiser la validation au même rythme que la génération progressent, le problème de fatigue pourrait être résolu.

1. Réactions partagées sur la forme (« une esthétique LinkedIn ? »)

• Critiques majoritaires : beaucoup jugent que le format avec un retour à la ligne à chaque phrase ressemble à un « post prétentieux d’influenceur LinkedIn » ou à un « texte généré par IA ». Ils reprochent un emballage tapageur sans véritable contenu.
• Quelques défenses : pour certains, c’est une mise en page plus lisible, adaptée à la faible capacité d’attention contemporaine, ou un style visant un certain rythme poétique.

2. Témoignages de mise en pratique du « désir épais »

• Cas de réussite : certains racontent avoir surmonté leur déprime et redonné de la densité à leur vie grâce à des loisirs physiques et chronophages comme la sculpture, la conception de circuits analogiques ou l’écriture de cartes postales.
• Débat sur la cuisson du pain : à propos de l’exemple de la « cuisson inefficace du pain » dans le texte, des ingénieurs ont partagé des astuces d’« optimisation du temps de fermentation » au four, déclenchant un sous-débat paradoxal.

3. Analyse des origines philosophiques et religieuses

• Rebranding d’une sagesse ancienne : certains estiment que cela ne fait que reconditionner, avec des termes modernes (Thin/Thick), des concepts comme les « Hungry Ghosts » du bouddhisme ou des thèmes classiques de la philosophie occidentale (Augustin, etc.).
• Validité de l’intuition : même si ce n’est pas nouveau, plusieurs s’accordent à dire qu’il s’agit d’une réflexion bien formulée pour la société contemporaine.

4. Les limites d’une logique binaire

• Attention à la simplification des concepts : le schéma « consommation = superficialité, création = profondeur » est jugé dangereux. Une lecture approfondie (consommation) peut aussi être épaisse, et une création commerciale peut être superficielle.
• La valeur du repos : certains soulignent que des activités « apparemment superficielles » comme ne rien faire ou jouer peuvent aussi constituer un repos nécessaire à la récupération.

5. Mise en cause de causes structurelles et environnementales

• Ce n’est pas qu’une affaire individuelle : le vrai problème serait le système de récompense dopaminergique conçu intentionnellement par les entreprises IT.
• Contraintes du réel : d’autres contestent l’idée que « nous sommes déjà prospères ». Avec le coût du logement, de la santé et d’autres menaces pesant sur la survie, il est en réalité difficile de poursuivre sereinement un « désir épais ».

N’est-on pas dans un état d’illettrisme du genre « le blanc, c’est du code ; le noir, c’est le terminal » ? Un peu comme quelqu’un qui est totalement incapable de développer s’il ne sait pas lire les logs ou faire du copier-coller.

Il semble qu’il y ait aussi cet article, Part 1 examined why senior engineers leave, ainsi que Part 2 The Economic Intervention That Stops Engineer Attrition.

https://codegood.co/writing/…

J’ai justement vu hier sur Facebook un post disant que c’était très pratique pour libérer de l’espace sur tout le Mac (en demandant à Claude de supprimer des choses tout seul)…

On ne pourrait pas faire en sorte que les dirigeants voient cet article..?

C'est super.

Quand je vois ce genre de choses, je retiens surtout l’importance du prompt système de l’outil. À l’heure actuelle, quand je l’utilise dans Cursor, personnellement je dirais opus >= gpt 5.2 > gemini 3. Le reste, Sonnet, 5.1, etc. : personnellement, je ne les utilise plus. Cela dit... avec gpt5.2, l’écart selon le niveau d’effort est assez marqué... Mais un effort élevé n’est pas toujours forcément meilleur. Du coup, j’utilise surtout opus et gemini. Quand je tombe parfois sur un problème très difficile, je fais coder les trois, je leur fais ensuite évaluer mutuellement leur code, puis je vérifie moi-même avant d’appliquer le résultat.

J’ai l’impression qu’il y a vraiment beaucoup de gens qui n’exécutent pas --dangerously-skip-permissions dans un environnement sandbox. Ils ne savent pas ce que signifie « danger », ou quoi ? sanglots

C’est tout à fait juste.

Hum, à l’inverse, j’ai aussi vu des juniors écrire du code bizarre puis se cacher derrière GPT en disant que c’est GPT qui l’avait fait, donc j’ai l’impression que ça dépend des cas.

Les agents qui utilisent des outils sont vraiment dangereux. Mieux vaut juste écouter ce qu’ils disent.

En effet. Je ne savais pas, car je n’utilise pas beaucoup le Bloc-notes intégré de Windows 11. Merci.

Il suffit d’appuyer sur F5 dans le Bloc-notes.