AiBrain 
Résumé exécutif
Constat : les workflows de coding avec l’IA ne fatiguent pas tous de la même façon. Le vibe coding use l’attention en continu, l’agent autonome déplace l’effort à la review, et le plan mode concentre le jugement humain plus tôt.
Thèse : le problème central n’est ni le coût des tokens ni la qualité brute de l’outil. C’est la répartition de l’attention humaine dans le cycle planification, génération, implémentation et review.
Point critique : quand l’attention arrive trop tard ou reste diffuse trop longtemps, les développeurs tamponnent, ratent les signaux faibles, ou finissent par ne plus avoir le sentiment de construire.
Implication : un bon workflow IA ne cherche pas à supprimer le jugement du développeur. Il le place au bon moment, sur les décisions qui méritent vraiment une attention haute.
Les vibe coders purs commencent à en parler ouvertement. Pas du coût des tokens, pas de la dette technique. De la fatigue. Après six heures de prompt-résultat-re-prompt, le cerveau tourne à vide. Les signaux faibles passent. Les failles s’accumulent sans que personne ne les voie.
De l’autre côté, les développeurs à qui on demande de “juste review” le code d’un agent autonome détestent leur quotidien. Relire 500 lignes qu’ils n’ont pas écrites, sans contexte sur les décisions prises, c’est la tâche la plus ingrate du métier. Alors ils tamponnent. Et les régressions passent.
Le problème commun n’est ni le coût ni l’outil. C’est la répartition de l’attention.
Trois modes, trois patterns d’attention
“Coder avec l’IA” recouvre aujourd’hui trois approches distinctes. Elles n’ont pas le même coût, pas la même fiabilité, mais surtout, elles n’imposent pas le même effort cognitif au développeur.
Le vibe coding, c’est décrire ce qu’on veut en langage naturel, accepter le code généré en se fiant au résultat plutôt qu’à une relecture ligne par ligne, et itérer par essais successifs. Rapide, intuitif, et cognitivement épuisant sur la durée.
Le plan mode, c’est demander à l’agent de produire d’abord un plan structuré (étapes, fichiers concernés, risques) avant d’exécuter quoi que ce soit. Tu valides le plan, puis l’agent implémente. Plus lent, mais l’attention est concentrée au bon moment.
L’agent autonome, c’est l’agent qui planifie, implémente, teste et corrige en boucle, sans intervention humaine à chaque étape. Tu donnes l’objectif, tu récupères le résultat. Zéro effort pendant l’exécution, mais tout l’effort à la review.
| Vibe coding | Agent autonome | Plan mode | |
|---|---|---|---|
| Pendant la génération | Diffuse et permanente | Zéro (délégation totale) | Haute mais courte (validation du plan) |
| Pendant l’implémentation | Moyenne : “est-ce que ça marche ?” | Zéro | Basse : monitoring passif |
| À la review | Faible (pas de review formelle) | Mur cognitif (diff massif sans contexte) | Ciblée (écarts au plan, pas tout le code) |
| Risque principal | Fatigue → les vrais problèmes passent | Tamponage → review cosmétique | Dépend de la qualité du plan initial |
| Charge cognitive totale | 🔴 Élevée en continu | 🔴 Faible puis pic brutal | 🟢 Distribuée et ciblée |
Pourquoi le vibe coding épuise
La recherche en psychologie cognitive appelle ça le vigilance decrement : la capacité humaine à détecter des signaux faibles dans un flux continu s’effondre avec le temps, typiquement en 20 à 30 minutes. Des travaux récents vont plus loin : la vigilance parfaite est théoriquement impossible. Le vibe coding prolongé place le développeur exactement dans cette situation. Un flux continu où le code correct et le code dangereux se ressemblent.
Et quand la fatigue gagne, il y a un stade que beaucoup de devs reconnaîtront sans oser en parler : le moment où l’attention s’éteint complètement. Le cycle prompt-résultat-re-prompt fonctionne sur un principe de récompense variable, le même mécanisme que les slot machines. L’imprévisibilité du résultat maintient l’engagement tout en réduisant progressivement l’esprit critique. Au bout de quelques heures, le dev ne réfléchit plus vraiment. Il relance, il accepte, il relance. C’est le point où le vibe coding cesse d’être un outil et devient un pilote automatique. Et c’est précisément là que les vraies erreurs s’installent en silence.
Les vibe coders qui parlent de burnout ne sont pas fragiles. Ils se heurtent à des contraintes biologiques que la discipline seule ne compense pas.
Pourquoi la review d’agent autonome est un piège
L’effort n’a pas disparu avec l’agent autonome. Il s’est déplacé à la fin.
L’agent livre un diff de 300 à 800 lignes. Le développeur n’a aucun contexte sur les micro-décisions prises en cours de route. La psychologie cognitive appelle ça de la charge extrinsèque : la complexité ne vient pas de la tâche elle-même, mais de la façon dont l’information est présentée. Une étude CHI 2026 mesure le phénomène : le stress et la fatigue augmentent avec l’usage répété, même quand la productivité s’améliore. Résultat prévisible : soit le dev passe 2 heures à reverse-engineer les décisions de l’agent, soit il tamponne, et les régressions passent en production.
Et il y a un problème plus profond : à force de ne faire que relire du code généré par des agents, les développeurs ne construisent plus rien. On transforme des artisans en contrôleurs qualité à temps plein sur du code qu’ils n’ont pas choisi d’écrire. Le plaisir de construire disparaît, la motivation s’effondre, et les meilleurs finissent par partir.
Le plan mode enhanced : mieux distribuer l’attention (pas la supprimer)
Le plan mode classique est déjà un progrès : il sépare la réflexion de l’implémentation. On peut aller plus loin. Mais soyons clairs : aucun workflow ne supprime le problème. Il le rend plus gérable.
Voici le workflow que j’utilise au quotidien. Il distribue l’attention en cinq phases, et il a ses propres limites, que je mentionne aussi.
Phase 1. Validation du plan (attention haute, sans limite de temps). C’est la phase la plus importante de tout le workflow. L’agent produit un plan structuré : fichiers concernés, étapes, risques identifiés. Mais valider ne veut pas dire lire et approuver. Ça veut dire itérer : poser des questions, challenger les choix, demander des alternatives, vérifier que les cas limites sont couverts. Ne passez à la suite que quand vous êtes convaincu que le plan couvre le périmètre réel, pas le périmètre que l’agent a compris. Tout ce que vous laissez passer ici, vous le paierez en review. Limite : la qualité du plan dépend de la qualité de cet échange. Un brief flou suivi d’une validation rapide donne un plan flou, et tu ne le vois qu’à la review.
Phase 2. Implémentation par l’agent (attention basse). L’agent exécute le plan. Un artifact de tâche est créé et mis à jour au fil de l’implémentation, il trace les décisions prises et les écarts par rapport au plan. Limite : l’artifact ne capture pas tout. L’agent dérive quand même, et certaines dérives sont silencieuses.
Phase 3. Review fonctionnelle via l’artifact (attention moyenne, ciblée). L’artifact te donne une vue synthétique de ce qui a été fait vs ce qui était prévu. Tu vérifies les dérives plutôt que de relire tout le diff. Limite : tu passes quand même plus de temps que prévu à rattraper les écarts. C’est moins pire qu’un diff brut, mais c’est pas gratuit.
Phase 4. Review humaine finale (attention haute, ciblée). Tu valides les points critiques : sécurité, gestion des données, cohérence architecturale. Le plan et l’artifact ont filtré une partie du bruit. Ta review porte sur moins de code, pas sur zéro code.
Phase 5. Agent de review automatique sur la PR (filet de sécurité). Avant le push, un agent de review classique passe sur la PR : conventions, failles connues, dépendances suspectes, couverture de tests. Quel que soit le mode utilisé en amont, cette étape ne se négocie pas. Le coût est négligeable, le bénéfice systématique.
Le résultat n’est pas un workflow parfait. C’est un workflow où l’attention haute est concentrée sur deux moments (plan + review critique) plutôt que diluée sur toute la session. C’est cette alternance qui rend le travail tenable dans la durée. Pas l’illusion que l’agent fait tout bien du premier coup.
Par où commencer
Si vous faites du vibe coding : chronométrez vos sessions. Au-delà de 2-3 heures continues, votre vigilance chute. C’est biologique, pas un problème de discipline. Imposez-vous des pauses et une review des points critiques (sécurité, données) en fin de session.
Si vous utilisez un agent autonome : ne faites pas de review de diff brut. Exigez que l’agent documente ses décisions au fil de l’implémentation. Si votre outil ne le permet pas, cantonnez l’agent à des tâches assez petites pour que le diff reste lisible (< 100 lignes).
Si vous voulez tester le plan mode enhanced : commencez par séparer explicitement la phase plan de la phase implémentation. Le changement le plus impactant est le premier : ne plus laisser l’agent décider et exécuter en même temps.
Si vous managez une équipe qui code avec l’IA : arrêtez de mesurer uniquement la vélocité. “L’IA va plus vite” ne veut rien dire si vos devs passent 8 heures par jour à relire du code généré sans jamais rien construire eux-mêmes. Vous aurez des métriques de productivité en hausse et une équipe en burnout silencieux, suivie d’un turnover que vous n’aurez pas vu venir. Mesurez aussi la charge de review, le ratio code écrit vs code relu, et demandez régulièrement à vos devs s’ils ont encore le sentiment de construire quelque chose.
Dans tous les cas : la question n’est pas quel outil vous utilisez. C’est à quel moment vous placez votre attention, et si ce moment est le bon.
L’IA ne remplace pas le jugement du développeur. Elle change le moment où ce jugement est sollicité, et chaque mode le sollicite différemment. Ce ne sont pas des faiblesses individuelles. Ce sont des contraintes biologiques. Un workflow qui les intègre travaille avec le cerveau plutôt que contre lui.
Ressources
Recherche scientifique
- When Help Hurts: Verification Load and Fatigue with AI Coding Assistants (CHI 2026). Étude N=60 développeurs mesurant la charge de vérification avec les assistants IA.
- The Sustained Attention Paradox (Sharpe & Tyndall, Cognitive Science 2025). Pourquoi la vigilance parfaite est biologiquement impossible.
- CognitIDE: Capturing Developers’ Cognitive Load (Stolp et al., 2025). Mesure physiologique de la charge cognitive pendant le coding, debug et review.
Terrain et données industrie
- Why Developers Using AI Are Working Longer Hours (Scientific American, mars 2026). L’IA supprime les speed limits naturels du développement.
- Agentic Fatigue Meets Vibe Coding (explainx.ai, avril 2026). Le paradoxe productivité/fatigue, avec données Ramp.
- AI Writes Better Code. We’re Getting Worse at Reviewing It. (Atomic Robot, février 2026). L’analogie aviation appliquée à la review IA.
- Harness State of DevOps 2026 (Enquête 700 ingénieurs). L’IA accélère le code, le burnout augmente.
Fondements théoriques
- Sweller, J. (1988) Cognitive Load Theory : intrinsic / extraneous / germane load.
- Skinner, B.F. (1953) Variable ratio reinforcement schedules.
- Baumeister, R.F. (2008) Decision fatigue.