Analyse de la fatigue du « vibe coding » chez les développeurs, provoquée par une IA plus rapide que la pensée

Points clés :

• L’usage d’outils d’IA (Claude Code, Cursor) a accéléré le développement, mais ce rythme de travail très rapide dépasse les limites de traitement du cerveau et provoque de la fatigue
• Les changements de contexte fréquents, l’excès de dopamine et le basculement vers un rôle de gestionnaire alourdissent la charge cognitive
• Un phénomène de « temps machine », où l’humain se laisse entraîner par la vitesse de l’IA, apparaît, d’où la nécessité de reprendre la main sur le rythme

---

Introduction

• Utilité et effets secondaires des outils d’IA : Un développeur fort de 40 ans d’expérience a utilisé Claude Code et Cursor pour développer un gestionnaire de paquets (Marvai), avec à la clé un gain de productivité, mais aussi une fatigue inédite.
• Problème posé : Alors que l’implémentation de fonctionnalités et la correction de bugs se font plus vite, le cerveau ne parvient pas à suivre la cadence de l’IA, ce qui conduit à un épuisement même après une courte session de travail (environ une heure).

Développement

1. Explosion de la charge cognitive et pression du « temps machine »

• Application de la théorie de la charge cognitive : Selon la théorie Team Topologies, un excès de responsabilités et les changements de sujet augmentent la charge cognitive. Le coding avec l’IA pousse cette charge jusqu’à sa limite.
• Rythme imposé par la machine : À l’image du stress autrefois subi par les ouvriers contraints de s’adapter à la cadence des machines, les développeurs vivent un phénomène de poursuite d’un rythme de coding piloté par l’IA (« temps machine »).
• Disparition du processus de réflexion : Dans le coding traditionnel, la vitesse d’exécution et la vitesse de réflexion coïncidaient, laissant au cerveau un temps d’assimilation (« baking time »). Avec l’IA, des architectures complexes et des chaînes de décision sont traitées en un instant, ce qui perturbe la synchronisation mentale.

2. Coexistence d’un excès de dopamine et des hormones du stress

• Accélération de la boucle dopaminergique : Le cycle de récompense « coder-erreur-résolution-réussite » est fortement accéléré par l’IA.
• Épuisement émotionnel : Les décharges fréquentes de dopamine et les hormones du stress liées à la vitesse agissent en même temps, provoquant fatigue et sentiment d’être dépassé, au lieu du plaisir de coder.

3. Hausse du coût des changements de contexte (Context Switching)

• Surcharge du cache mental : Un changement de contexte est une opération à forte dépense énergétique, comparable au fait de vider puis de recharger le cache du cerveau.
• Micro-changements de contexte (Micro-Context Switching) : L’IA modifie simultanément plusieurs modules ou, même lors d’un simple usage de l’autocomplétion par onglet (touche Tab), impose de fréquents micro-basculements entre le « mode rédaction » et le « mode relecture », ce qui épuise rapidement l’énergie mentale.

4. Transformation fondamentale du rôle du développeur

• De rédacteur à gestionnaire : Le rôle évolue, passant de l’implémentation de besoins en code à celui de « chef d’équipe » ou de « coordinateur » chargé de gérer et de relire les résultats d’un « coéquipier rapide » qu’est l’IA.
• Asymétrie de responsabilité : Tandis que l’IA produit l’équivalent du travail de cinq personnes, le développeur conserve l’entière responsabilité finale de la qualité du code, ce qui alourdit la charge de supervision.

Conclusion

Recommandations pour un coding avec IA durable

• Régulation intentionnelle du rythme (Pacing) : Le développeur doit piloter lui-même le tempo de travail au lieu de se laisser emporter par la vitesse de l’IA.
• Adoption de nouvelles formes de rétrospective : De nouvelles routines de travail, comme une rétrospective quotidienne (Retrospective), sont nécessaires pour resynchroniser l’IA et le cerveau.
• Changement de perception du rôle : Il faut réduire la microgestion visant à contrôler dans le détail les sorties de l’IA, et faire évoluer son style de travail vers une plus grande confiance dans l’IA.
• Perspective d’avenir : L’avenir du coding ne réside peut-être pas dans l’accélération à tout prix, mais dans une « lenteur intentionnelle » et de nouvelles limites tenant compte des capacités cognitives humaines.

[dbs0829]

Même pour les tâches répétitives un peu ingrates, je préfère encore créer une macro, ça me rassure davantage...

[fantajeon]

C’est pareil entre les personnes.

Entre les gens aussi, ce genre de problème arrive souvent.
Si la personne qui réfléchit lentement est le manager,
elle dira :
« Tout va trop vite, c’est épuisant et difficile de travailler ensemble »,
et si cette personne est le subordonné,
elle dira :
« Il comprend mal ce qu’on lui dit, donc c’est difficile de travailler ensemble ».

Au final, pour pouvoir travailler ensemble, il faut que l’alchimie entre les personnes fonctionne.

[bakyeono]

La souffrance de devoir se contenter de la revue de code et des tests, après s’être fait retirer le codage...

[colus001]

En dehors de mes projets personnels, j’utilise le vibe coding de manière limitée. Avec l’autocomplétion de Cursor, je m’en sers surtout pour l’idéation et pour coder des répétitions d’un même schéma. Dans un projet de long terme, tout résoudre avec le vibe coding me paraît être, en tant que développeur, une attitude irresponsable.

[tested]

On a l’impression que plus on est du côté de ceux qui comprennent, vérifient et relisent le code produit que de ceux qui se contentent d’écrire un prompt pour obtenir un résultat, plus la fatigue se fait sentir.
C’est aussi indiqué dans l’article original.

[onixboox]

Je pense simplement : « Tant mieux si j’ai moins de travail à faire grâce à l’IA », donc je n’ai jamais ressenti ce genre de fatigue. J’utilise zed + claude, et il arrive parfois qu’en cours de route le contexte change et que ça se mette à fonctionner bizarrement ; dans ce cas, je restaure le code avec git et je lui demande de « réécrire en synthétisant ce qui précède », et il me produit quelque chose de plus propre. Ce n’est pas qu’on ne code plus directement au clavier ; c’est juste que le processus qui consiste à transformer les idées qu’on a en tête en code a changé, non ? Au contraire, le fait de saisir un prompt m’aide aussi à clarifier mes idées.

[caniel]

Le processus de création en code devenant une boîte noire, n’a-t-on pas besoin de temps pour resynchroniser le code avec ce qu’on avait en tête ?
Avec l’écriture de code classique, on a la garantie que le code correspond à ce qu’on avait à l’esprit, mais avec le codage via des LLM, cette garantie n’existe pas.

[onixboox]

On a seulement la logique en tête, et il suffit de vérifier si le code généré par l’IA est correct ; il n’est plus nécessaire d’écrire le code mentalement, non ? Il suffit surtout de réfléchir à la précision des données qu’on transmet au prompt, donc au contraire, mon travail s’est beaucoup accéléré.

[caniel]

Je pense que cela peut varier selon le degré de précision du prompt. Si on transmet à la LLM quelque chose au niveau du pseudocode, je comprends ce que vous voulez dire.

[choihyojun]

Avant, même après avoir passé toute la journée à écrire du code, je finissais le travail avec un vrai sentiment d’accomplissement. Maintenant, je passe la majeure partie de mes journées de travail à converser, et il m’arrive souvent de ne pas écrire moi-même une seule ligne de code, et pourtant je fais un burn-out… Je m’y reconnais parfaitement.

[ds2ilz]

Moi aussi, ma fatigue a augmenté exactement pour cette raison. Je m’y attendais, donc le fait d’être fatigué en soi ne me dérange pas, mais vu de l’extérieur, comme il n’y a plus ces moments où l’on martèle frénétiquement le clavier en codant, on dirait apparemment que je travaille avec énormément de marge. Et quand je dis que je suis plus fatigué qu’avant, les gens ont du mal à le comprendre....

[reagea0]

Ah, j’ai l’impression qu’on vient enfin d’expliquer clairement à ma place pourquoi je ressens cette fatigue.

[baeba]

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.

[aura01]

J’ai eu une expérience similaire, donc voici comment je procède.

Par exemple, si je fais du refactoring,

« Donne pour consigne d’analyser le code existant puis de proposer des alternatives »
« Donne pour consigne de résumer et d’expliquer les différences entre l’alternative et le code existant, ainsi que leurs avantages et inconvénients »
« Donne pour consigne de proposer une méthode pour vérifier si l’alternative est réellement meilleure »
« Vérifier directement l’alternative »
« Donne pour consigne d’appliquer l’alternative puis de rédiger la documentation et les tests »

Le problème, c’est que l’utilisation de tokens augmente énormément, donc le coût devient élevé...