Cognitive Surrender

Article original : addyosmani.com Lire en 🇫🇷 via Google Translate

Auteur: Addy Osmani
Thème: IA
Mots-clés: cognition, IA, jugement, code review, Wharton
Ton: opinion

Résumé

Addy Osmani s'empare d'un terme issu d'un papier de Wharton (Steven Shaw et Gideon Nave) — cognitive surrender — pour décrire ce qui arrive quand le résultat de l'IA devient silencieusement votre résultat. Sur 1 372 participants, l'étude montre que face à une mauvaise réponse de l'IA, 73% des gens l'acceptent quand même — et leur confiance augmente. Osmani applique le concept aux ingénieurs : la PR de 600 lignes scannée en diagonale, la validation de boundary qu'on n'effectue plus, le code "qui a l'air propre". On est tous en train de franchir la ligne sans le voir.

💡 Pourquoi ça compte

Ce papier nomme un phénomène que beaucoup d'ingénieurs commencent à ressentir sans le mettre en mots : la perte progressive du jugement indépendant face à des assistants qui parlent toujours avec assurance. À retenir pour toute pratique d'engineering responsable de la qualité, de la sécurité, ou de la formation des juniors.

Analyse approfondie

Il y a un terme entendu récemment qu'Osmani veut discuter : cognitive surrender. Il vient d'un papier récent de la Wharton School (UPenn) — Steven Shaw et Gideon Nave : Thinking - Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender. La formule a des racines théologiques anciennes, mais son cadre IA est neuf et il frappe quiconque code avec un agent à son coude.

La distinction qui mérite d'être mémorisée :

Cognitive offloading : c'est la calculatrice, le moteur de recherche, le GPS. Tu délègues le comment et tu gardes le quoi. Tu juges encore si le résultat a du sens, et tu interviens quand ce n'est pas le cas.
Cognitive surrender : c'est ce qui arrive quand tu cesses de construire la réponse. Le résultat de l'IA devient ton résultat. Il n'y a plus rien à corriger, parce que tu n'as jamais formé une opinion indépendante à comparer.

Sur trois expériences impliquant 1 372 participants, Shaw et Nave ont trouvé que la simple disponibilité d'une IA suffisait à provoquer la capitulation. Sur les essais où l'IA se trompait, 73% du temps les participants acceptaient la mauvaise réponse. Pire : leur confiance augmentait quand l'IA était disponible, alors même que la moitié des réponses étaient délibérément incorrectes. Ils empruntaient la confiance du modèle (toujours assez haute) et la traitaient comme la leur.

Cet effet de confiance empruntée est précisément l'endroit où l'histoire cesse d'être une histoire de cognition générale et devient une histoire de software engineering.

Où la capitulation se manifeste dans notre travail

La plupart d'entre nous ne capitulent pas sur les choses faciles. On remarque quand un agent invente une API ou fabrique un import. La capitulation se produit plus profond dans la stack, dans les moments où le coût de former une opinion indépendante semble disproportionné par rapport à la tâche.

Quelques endroits où Osmani l'a vue se produire, surtout chez lui :

Lire le diff. L'agent produit une PR de 600 lignes. Tu la scannes. Les noms de variables sont raisonnables. Les tests sont verts. Tu approuves. Quelque part au milieu, il y a un changement subtil dans l'ordre d'une boundary de transaction, ou un default qui flippe pour un edge case. Tu n'as pas formé l'opinion : tu as récupéré la confiance.

Valider une trust boundary. L'agent te propose de désactiver un check de sécurité avec une explication plausible. Tu acceptes — l'explication paraît cohérente. Mais tu n'as pas formé indépendamment l'argument selon lequel ce check est inutile.

Lire les tests générés. Les tests passent. Tu n'as pas regardé s'ils testent les bons invariants ou s'ils sont juste alignés mécaniquement avec l'implémentation. Le tests qui valident le code généré par le même modèle que celui qui a écrit le code sont une boucle fermée.

Décider de l'architecture. Tu demandes à l'agent comment structurer un nouveau module. La proposition arrive, soignée, plausible. Tu suis. Tu n'as pas comparé à deux ou trois alternatives mentales — l'agent t'en a apporté une, et tu l'as adoptée.

Pourquoi c'est insidieux

L'élément manquant, dans tous ces cas, n'est pas la connaissance. C'est l'effort. Former une opinion indépendante prend du temps, demande de la friction, oblige à se tromper en chemin. L'IA fournit une réponse polie, structurée, immédiate. La pente la plus douce est de l'accepter — et la pente la plus douce, en ingénierie comme dans la vie, c'est celle qu'on prend.

Le risque cumulé est que les ingénieurs perdent peu à peu la pratique du jugement indépendant — précisément la chose qui les rend irremplaçables. L'IA produit un code qui marche ; ce qui distingue le bon ingénieur du moyen, c'est sa capacité à interroger ce code, à anticiper ses échecs, à voir ce qu'il ne fait pas. Cette capacité s'entretient comme un muscle.

Que faire

Osmani propose quelques garde-fous pratiques :

Forme l'opinion d'abord, demande à l'IA ensuite. Avant d'accepter une suggestion, formule mentalement (ou par écrit) ce que tu aurais fait. Compare.
Pose des questions indépendantes. Ne demande pas seulement à l'agent de coder ; demande à un autre agent (ou à toi-même) d'évaluer le résultat selon des critères que tu as définis avant.
Lis le code, pas juste le diff. Quand l'enjeu est élevé (sécurité, persistance, transactions), prends le temps de relire au-delà du delta.
Mesure ta confiance. Si tu te sens 100% confiant après avoir scanné une PR de 600 lignes en deux minutes, c'est probablement de la confiance empruntée.