I'm Not Reading All of That: Understanding Software Engineers' Level of Cognitive Engagement with Agentic Coding Assistants

Cette étude révèle que l'engagement cognitif des ingénieurs logiciels diminue au fur et à mesure de l'interaction avec des assistants de codage agents, soulignant la nécessité de concevoir de nouveaux mécanismes d'interaction qui favorisent la réflexion critique et la vérification pour éviter une dépendance excessive.

L'essentiel

🧠 Le Titre : « Je ne vais pas tout lire ! »

De quoi parle l'article ?
Les chercheurs de Samsung et de l'Université York ont étudié comment les développeurs de logiciels (les « architectes du code ») interagissent avec de nouveaux assistants intelligents appelés ACAs (comme un robot très doué qui écrit du code pour vous).

Leur constat principal ? Plus le robot travaille, moins les humains réfléchissent vraiment. Ils deviennent des « passagers » plutôt que des « pilotes ».

---

🚗 L'Analogie du Chauffeur et du GPS Autonome

Imaginez que vous êtes un chauffeur de taxi expérimenté (le développeur). Vous avez un nouveau GPS ultra-intelligent (l'assistant IA) qui ne vous donne pas juste un itinéraire, mais qui conduit la voiture pour vous.

1. Au début (La Planification) :
   Le GPS dit : « Bonjour, je vais vous emmener au centre-ville. Je vais prendre l'autoroute, éviter les travaux, et faire un détour par le parc. »

   • Ce que font les humains : Ils écoutent attentivement. Ils vérifient la carte. Ils disent : « D'accord, mais attention à la rue X, il y a des embouteillages ». C'est le moment où le cerveau est très actif.

2. Au milieu (L'Exécution) :
   Le GPS se met à conduire. Il parle sans arrêt : « Je tourne à gauche, je freine, je change de vitesse, je parle au feu rouge... »

   • Ce que font les humains : Ils regardent par la fenêtre, pensent à leur dîner, ou disent : « Arrête de me dire tout ça, je ne vais pas tout lire ! ». Ils arrêtent de suivre les détails parce que le flux d'informations est trop dense. C'est comme si le GPS leur jetait un déluge d'eau froide : ils se ferment.

3. À la fin (L'Arrivée) :
   Le GPS s'arrête. « On est arrivés. »

   • Ce que font les humains : Ils regardent juste le bâtiment. « Ok, on est bien là. » Ils ne regardent pas comment le GPS a conduit. Ils ne vérifient pas si le moteur a surchauffé ou si une roue a touché un trottoir. Ils sont satisfaits du résultat, mais ils ont oublié le voyage.

---

🔍 Ce que les chercheurs ont découvert

En observant quatre développeurs (du débutant au vétéran), ils ont vu deux problèmes majeurs :

1. La fatigue de l'attention : Plus la tâche avance, moins les humains réfléchissent. Au début, ils sont super concentrés. À la fin, ils sont en mode « pilote automatique ».
2. L'obsession du résultat (Le chemin « Heureux ») : Les développeurs ne regardent que si le résultat final est correct (la voiture est arrivée). Ils ne s'intéressent pas au processus (comment la voiture est arrivée).
   • Le danger : Si le GPS a pris un raccourci dangereux ou a volé un objet en route, le développeur ne le saura jamais tant que le résultat final semble correct.

⚠️ Pourquoi c'est dangereux ?

Dans le monde du logiciel, si vous ne comprenez pas comment le code a été créé, vous risquez de :

• Laisser passer des bugs cachés.
• Accepter du code malveillant (comme un virus).
• Devenir dépendant du robot au point de perdre votre propre capacité à réfléchir et à résoudre des problèmes.

C'est comme si un étudiant laissait un robot faire ses devoirs. Il a la bonne note, mais il n'a rien appris. Si l'examen change un peu, il est perdu.

---

💡 Les Solutions Proposées : Comment réveiller le cerveau ?

Les chercheurs proposent de changer la façon dont ces robots parlent aux humains pour les forcer à rester éveillés.

1. Arrêter de tout dire en texte :
   Au lieu de faire défiler des centaines de lignes de texte (ce qui est ennuyeux et fatiguant), le robot devrait utiliser des dessins, des schémas ou même sa voix.

   • Analogie : Au lieu de vous lire un livre entier de 500 pages, le robot vous montre un dessin animé ou vous raconte l'histoire avec des intonations. C'est plus facile à comprendre et à retenir.

2. Le « Coup de pied dans le derrière » cognitif (Cognitive Forcing) :
   Le robot devrait parfois ralentir ou poser des questions pièges.

   • Analogie : Imaginez un professeur qui, au lieu de vous donner la réponse, vous dit : « Attends, avant que je te donne la solution, explique-moi pourquoi tu penses que c'est la bonne. »
   • Cela force le développeur à passer du mode « réflexe rapide » (System 1) au mode « réflexion profonde » (System 2). Cela rend le travail plus long, mais beaucoup plus sûr et intelligent.

🏁 En résumé

Cette étude nous dit : « Ne laissez pas l'IA conduire toute la voiture sans vous. »

Si nous voulons que l'intelligence artificielle nous aide vraiment sans nous rendre bêtes, nous devons concevoir ces outils pour qu'ils nous obligent à réfléchir, à vérifier et à comprendre, plutôt que de simplement nous donner le résultat final tout prêt. L'IA doit être un partenaire de réflexion, pas un exécutant silencieux.

Résumé technique

1. Problématique et Contexte

L'article aborde le risque croissant de sur-dépendance des ingénieurs logiciels (SE) envers les systèmes d'intelligence artificielle, en particulier les assistants de codage agents (ACAs) tels que Cline, Claude Code ou Codex. Ces systèmes, capables de planifier, de générer et de modifier du code de manière autonome, accélèrent les flux de travail mais posent une menace critique : l'érosion de la pensée critique et de l'engagement cognitif des développeurs.

Le problème central est que les ACAs actuels fonctionnent souvent comme de simples exécutants de tâches, déplaçant la charge cognitive de l'humain vers la machine. Cela peut entraîner :

• Une complaisance où les développeurs ne vérifient pas les sorties générées.
• Une incapacité à évaluer les compromis, à raisonner sur la correction du code ou à anticiper les modes de défaillance.
• Un risque accru de laisser passer des erreurs, des biais algorithmiques ou des vulnérabilités (comme des attaques par empoisonnement de modèles), car les humains ne s'engagent pas suffisamment dans le processus de « sensemaking » (construction de sens).

L'objectif de l'étude est de comprendre comment les ingénieurs logiciels s'engagent cognitivement avec ces agents et d'identifier des opportunités de conception pour transformer les ACAs en véritables « outils de pensée » (Tools for Thought) qui soutiennent, plutôt que de remplacer, le raisonnement humain.

2. Méthodologie

Les auteurs ont mené une étude formative qualitative et quantitative auprès de quatre ingénieurs logiciels (SE) issus d'une grande entreprise technologique aux Philippines, couvrant un spectre d'expérience professionnelle allant de moins d'un an à plus de dix ans.

• Outil utilisé : L'agent Cline, choisi pour ses capacités de planification autonome, de discussion avec l'utilisateur et d'appel d'outils externes.
• Tâche : Les participants devaient générer un script (dans le langage de leur choix) pour analyser des fichiers Excel, extraire des données spécifiques et créer un nouveau classeur. La tâche a été conçue en s'appuyant sur la Taxonomie de Bloom pour évaluer différents niveaux de processus cognitifs (mémorisation, compréhension, analyse, évaluation).
• Déroulement :
  1. Phase de Planification : L'ingénieur et l'agent définissent l'approche.
  2. Phase d'Exécution : L'agent génère le code et exécute les outils.
  3. Phase d'Évaluation : L'ingénieur vérifie le résultat.
• Collecte de données :
  • Observation directe et notes d'un modérateur (pensée à voix haute autorisée).
  • Sondage auto-rapporté administré immédiatement après la tâche, divisé en cinq parties : expérience, rappel, compréhension, analyse et évaluation. Les questions étaient calibrées sur la Taxonomie de Bloom pour mesurer la profondeur de l'engagement cognitif.
  • Vérification des réponses de rappel par rapport aux dossiers de travail réels.

3. Résultats Clés

L'analyse des données a révélé deux motifs dominants concernant l'engagement cognitif :

A. Déclin de l'engagement cognitif au fil de la tâche

L'engagement n'est pas constant ; il suit une courbe descendante marquée :

• Phase de Planification : L'engagement est maximal. Les participants consacrent des ressources cognitives importantes à la compréhension du prompt, à la vérification des fichiers et à la validation du plan de l'agent. Ils traitent cette phase comme une charge cognitive pertinente (germane load).
• Phase d'Exécution : L'engagement chute drastiquement. Le volume d'informations textuelles générées par l'agent (logs, appels d'outils, code brut) crée une surcharge cognitive (extraneous load). Les participants se détournent de l'écran, lisent superficiellement ou déclarent explicitement : « Je ne vais pas lire tout ça ». Ils perçoivent ces flux de données comme du bruit inutile.
• Phase d'Évaluation : L'engagement est minimal. Les participants se concentrent presque exclusivement sur le résultat final (le fichier Excel généré) plutôt que sur le processus (le code source). Si le résultat semble correct, la tâche est considérée comme terminée, sans vérification approfondie du code sous-jacent.

B. Biais vers le « Happy Path » (Chemin de succès)

Les participants tendent à se souvenir, comprendre et évaluer uniquement le scénario idéal menant à un résultat correct :

• Rappel et Compréhension : Aucun participant ne pouvait rappeler correctement le nombre de fonctions générées. Seuls la moitié comprenaient la fonctionnalité de la première fonction ou pouvaient la résumer.
• Analyse et Évaluation : Seuls la moitié des participants se sentaient capables d'analyser le code pour des cas limites (edge cases).
• Conséquence : Cette focalisation sur le résultat immédiat empêche la détection de vulnérabilités potentielles ou de code malveillant. Les ingénieurs adoptent une stratégie « avare » de ressources cognitives : ils ne s'engagent dans un raisonnement profond que si le résultat final échoue visiblement.

4. Contributions et Opportunités de Conception

Sur la base de ces constats, les auteurs proposent des directions de conception pour les ACAs afin de maintenir l'engagement cognitif et favoriser la pensée critique :

1. Communication au-delà du texte (Multimodalité) :

   • Pour contrer la surcharge textuelle, les ACAs devraient intégrer des visualisations (diagrammes de flux, graphes, cartes mentales) pour synthétiser les plans et le raisonnement.
   • L'utilisation de la voix (synthèse vocale naturelle) pourrait agir comme un indice social favorable, réduire la charge cognitive perçue et améliorer la rétention de l'information, comme le suggèrent des études antérieures en apprentissage.

2. Conceptions de « Forçage Cognitif » (Cognitive Forcing) :

   • Inspirées par la théorie du double processus (Système 1 vs Système 2), ces designs visent à interrompre le flux automatique de l'IA pour forcer l'utilisateur à passer d'une pensée intuitive (Système 1) à une pensée analytique (Système 2).
   • Mécanisme : Ralentir la prise de décision de l'IA ou exiger que l'utilisateur analyse une démonstration ou un problème avant de recevoir la suggestion de l'IA. Cela force l'ingénieur à exercer son expertise avant de valider la solution de l'agent, augmentant ainsi la précision de l'évaluation et la confiance dans le système.

5. Signification et Conclusion

Cette étude met en lumière un paradoxe critique dans l'adoption des ACAs : bien qu'ils augmentent la productivité, ils risquent de détériorer la compétence critique des ingénieurs logiciels s'ils sont conçus uniquement pour l'efficacité.

La signification principale réside dans le changement de paradigme proposé : les ACAs ne doivent pas être vus comme de simples exécutants autonomes, mais comme des partenaires de programmation (pair programmers) qui doivent soutenir le « sensemaking ». Pour garantir la sécurité et la fiabilité des logiciels déployés dans des contextes réels à haut risque, les futures générations d'ACAs doivent intégrer des mécanismes de conception qui :

• Préservent l'attention de l'utilisateur face à la complexité.
• Encouragent la vérification active du processus, pas seulement du résultat.
• Provoquent intentionnellement la réflexion plutôt que de fournir des solutions immédiates et passives.

Les auteurs concluent que l'avenir de l'interaction humain-IA en ingénierie logicielle dépend de notre capacité à concevoir des systèmes qui soutiennent la cognition humaine plutôt que de la remplacer.