Imaginez deux groupes de chirurgiens en formation. Le premier apprend en opérant : des incisions, des erreurs, des corrections, de la sueur. Le second regarde un robot chirurgical effectuer chaque geste, parfaitement, en temps réel. Au bout de six mois, les deux groupes réussissent les opérations de formation. Mais si le robot tombe en panne pendant une procédure réelle, à qui préféreriez-vous faire confiance en salle d’opération ?
Ce scénario n'est pas hypothétique. Il est en train de se jouer, silencieusement, dans des milliers d'équipes de développement logiciel à travers le monde. Et en 2026, deux chercheurs ont eu l'idée — inconfortable — de le mesurer.
Une question que personne ne voulait poser
Judy Hanwen Shen et Alex Tamkin, dans leur étude "How AI Impacts Skill Formation", ont posé une question simple en apparence : quand un développeur utilise l'IA pour résoudre un problème, est-ce qu'il apprend le problème — ou juste à utiliser l'IA ?
La question dérange. L'industrie technologique a massivement investi dans les outils de génération de code. Les gains de productivité sont réels, documentés, vendus. Remettre en question l'apprentissage derrière ces gains, c'est questionner un paradigme entier.
Shen et Tamkin l'ont fait quand même. Et ce qu'ils ont trouvé a un nom dans leur rapport : le "learning tax" — l'impôt sur l'apprentissage. La facture cachée de la délégation cognitive.
L'expérience : 52 développeurs, une bibliothèque inconnue, et un chronomètre
Le protocole est élégant dans sa simplicité. 52 développeurs professionnels. Tous expérimentés en Python. Aucun n'a jamais touché à Trio — une bibliothèque de programmation asynchrone choisie précisément parce qu'elle introduit des concepts genuinement nouveaux : la concurrence structurée, les nurseries, un modèle d'exécution qui oblige à reconstruire son modèle mental de zéro.
Les participants sont divisés en deux groupes au hasard. Le groupe traitement a accès à GPT-4o pendant 35 minutes pour résoudre deux problèmes complexes avec Trio. Le groupe contrôle n'a que la documentation et le web. Puis, les deux groupes répondent au même quiz sans IA — compréhension conceptuelle, lecture de code, débogage.
L'hypothèse implicite de l'industrie : le groupe avec IA finira plus vite et apprendra au moins autant.
Les résultats ont invalidé les deux parties de cette hypothèse.
Les chiffres qu'on n'attendait pas
Sur la vitesse d'abord. L'IA n'a pas accéléré significativement la complétion des tâches.
Temps moyen avec IA : 23–24 minutes. Sans IA : 26–28 minutes. Écart statistiquement insignifiant (p = 0,391). Les enregistrements d'écran expliquent pourquoi : certains participants ont passé jusqu'à 11 minutes — plus du tiers du temps disponible — à composer des requêtes ou à tenter de comprendre les réponses de l'assistant. L'IA n'est pas automatiquement rapide. Elle est rapide quand on sait lui parler.
Sur l'apprentissage ensuite. Là, les chiffres sont nets.
| Groupe | Score moyen au quiz |
|---|---|
| Avec IA | 50% |
| Sans IA | 67% |
Dix-sept points d'écart. L'équivalent de deux paliers de notation. Taille d'effet : d = 0,738 — ce que les chercheurs qualifient de "large", c'est-à-dire difficilement attribuable au hasard (p = 0,010).
Et l'élément peut-être le plus troublant : cet écart est uniforme, indépendamment de l'expérience préalable. Qu'il ait un an ou sept ans de Python, le développeur qui a utilisé l'IA pour déléguer la résolution de problèmes a systématiquement moins bien retenu les concepts de Trio.
L'IA n'a pas aidé les moins expérimentés à rattraper les seniors. Elle a réduit la rétention de tous, de manière égale.
Où l'écart est le plus grand : le débogage
L'évaluation décomposait trois types de compétences. Les résultats ne sont pas uniformes.
La lecture de code — comprendre ce que fait un bloc sans l'exécuter — affiche le plus petit écart entre les deux groupes. Normal : pendant la tâche, les deux groupes ont dû lire du code, avec ou sans assistance.
La compréhension conceptuelle — saisir pourquoi Trio fonctionne comme il fonctionne, ce que sont les nurseries, comment la concurrence structurée change le modèle d'exécution — montre un écart significatif. Les utilisateurs de l'IA ont contourné le moment de construction du modèle mental.
Mais c'est sur le débogage que l'écart est le plus abyssal.
Ce résultat n'est pas anodin. Le débogage est la compétence qui consiste à comprendre pourquoi quelque chose ne marche pas — à lire une erreur, à remonter sa trace, à diagnostiquer la cause profonde. C'est aussi la compétence la plus critique pour superviser un code qu'on n'a pas soi-même écrit.
En d'autres termes : c'est exactement la compétence dont vous avez besoin pour vérifier ce que l'IA produit.
Six façons d'utiliser l'IA — et ce qu'elles font à votre cerveau
L'un des apports les plus originaux de l'étude est la classification des comportements observés en six patterns distincts, identifiés par analyse des enregistrements d'écran et des 147 requêtes adressées à l'IA.
Les trois patterns à faible score (apprentissage compromis) :
Le premier, la Délégation totale, est le plus radical : le développeur confie l'intégralité de la tâche à l'IA. Il finit le plus vite. Il obtient environ 24% au quiz. Il a résolu le problème sans jamais comprendre comment.
Le second, la Confiance progressive, commence prometteur : le développeur essaie seul, bute sur la difficulté, puis abandonne et délègue tout à l'IA pour la seconde moitié. Le problème est résolu. La compréhension est fragmentée, exactement là où les concepts devenaient intéressants.
Le troisième, le Débogage itératif, est peut-être le plus répandu : copier-coller l'erreur dans l'IA, coller la solution proposée, recommencer. Aucun moment d'arrêt pour comprendre pourquoi le code a échoué. Score moyen : 39%.
Les trois patterns à haut score (apprentissage préservé) :
L'Enquête conceptuelle est le pattern le plus performant de l'étude entière — et il est contre-intuitif. Ces développeurs ne demandent pas à l'IA d'écrire du code. Ils lui posent des questions sur les principes : "Comment fonctionne une nursery ?" "Quelle est la différence entre Trio et asyncio ?" Puis ils écrivent le code eux-mêmes. Score moyen : 86% — supérieur au groupe sans IA.
La Génération puis compréhension : l'IA génère, mais le développeur s'arrête sur chaque ligne, pose des questions de suivi, valide sa compréhension avant de soumettre. L'effort cognitif reste présent, juste réorienté.
L'Hybride code-explication : demander à l'IA le code accompagné d'une explication détaillée. La lecture forcée de l'explication maintient l'engagement cognitif, même si l'IA a produit le code.
La conclusion de cette classification est précise : ce qui distingue un usage enrichissant d'un usage appauvrissant de l'IA n'est pas la quantité d'IA utilisée. C'est la direction dans laquelle l'effort cognitif est orienté. Interroger les principes préserve l'apprentissage. Déléguer les solutions le détruit.
La difficulté n'est pas un bug. C'est exactement ce qu'on évitait.
Le groupe sans IA a fait plus d'erreurs. En médiane, 3 erreurs sur l'ensemble de la tâche, contre 1 pour le groupe avec IA. Et c'est précisément pour ça qu'il a mieux appris.
Il faut distinguer les types d'erreurs. Les erreurs de syntaxe Python — une faute de frappe, un nom de variable oublié — sont corrigées en secondes et n'apprennent rien sur Trio. Les erreurs spécifiques à Trio, en revanche — une coroutine jamais attendue avec await, une mauvaise utilisation d'une fonction asynchrone — sont des portes d'entrée dans le fonctionnement profond de la bibliothèque. Elles forcent à consulter la documentation, à comprendre le modèle d'exécution asynchrone, à reconstruire son raisonnement.
Le groupe sans IA a rencontré ces erreurs, les a résolues de manière autonome, et a ancré dans sa mémoire à long terme les modèles mentaux correspondants. Le groupe avec IA a souvent reçu un code correct dès le premier essai — sautant l'étape cruciale de la résolution de problèmes.
La friction n'était pas un obstacle à l'apprentissage. Elle était l'apprentissage. L'IA l'a effacée. Et avec elle, la trace mnésique.
Ce phénomène est bien documenté en sciences cognitives : la difficulté désirable (desirable difficulty) est un principe selon lequel les conditions d'apprentissage qui semblent difficiles et inconfortables produisent une rétention à long terme supérieure aux conditions facilitées. L'IA, dans ses usages les plus délégateurs, optimise pour le confort immédiat — exactement ce qui nuit à la mémorisation durable.
Le piège de la supervision
Voici où les implications dépassent le domaine de l'apprentissage individuel pour devenir un enjeu systémique.
À mesure que l'IA prend en charge la rédaction du code, le rôle de l'ingénieur évolue vers celui d'un vérificateur. Or, vérifier un code complexe exige une expertise au moins égale à celle nécessaire pour l'écrire. C'est ce que le rapport nomme le "Supervision Trap" — le piège de la supervision.
Les chercheurs tracent un parallèle avec le système Full Self-Driving de Tesla. La quasi-perfection du système pendant de longues périodes crée une baisse de vigilance chez le conducteur. Quand l'IA commet enfin une erreur dans une situation critique, le conducteur — déconnecté de la boucle de contrôle — met en moyenne 5 à 8 secondes à réagir. Ces secondes font la différence.
Un ingénieur habitué à accepter le code "parfait" de l'IA développe le même réflexe. Il perd la mémoire musculaire du débogage — cette capacité à sentir qu'quelque chose cloche, à savoir instinctivement où chercher, à reconnaître le pattern d'une erreur avant même de lire le message.
Les conséquences pour les organisations sont concrètes. Les hallucinations silencieuses — contrairement à un code qui plante avec un message d'erreur, une faille de sécurité ou une erreur logique subtile ne déclenche aucune alerte immédiate. Seul un expert peut la repérer. Et si les experts ont été formés avec l'IA plutôt que malgré elle, cette expertise est creuse.
Les entreprises pourraient accumuler ce que le rapport appelle une dette de vérification : un stock de code qui "fonctionne" en apparence, mais que personne dans l'équipe n'est capable de maintenir ou de réparer sans assistance externe. Invisible jusqu'au moment où elle ne l'est plus.
Atrophie contre forclusion : deux maux très différents
L'étude distingue deux phénomènes qu'on a tendance à confondre, mais qui ont des implications radicalement différentes.
Pour un développeur senior qui possède déjà des modèles mentaux solides, l'utilisation de l'IA est une forme de délégation. S'il cesse d'exercer certaines compétences, il subit une atrophie : la capacité s'affaiblit par manque d'usage, mais les chemins neuronaux existent toujours. Si nécessaire, il peut les réactiver. C'est inconfortable, mais réversible.
Pour un étudiant ou un développeur junior, le mécanisme est fondamentalement différent. Déléguer à l'IA ne revient pas à automatiser une tâche connue — c'est substituer le processus d'apprentissage lui-même. Les chercheurs appellent ça la foreclosure — la forclusion cognitive : les chemins neuronaux pour l'évaluation critique, la résolution d'erreurs, la compréhension profonde des systèmes ne sont jamais formés. Pas affaiblis. Jamais construits.
Un individu qui n'a jamais appris à déboguer par lui-même ne pourra jamais "retrouver" cette compétence — parce qu'elle n'a jamais existé dans son répertoire cognitif.
L'atrophie, ça se soigne. La forclusion, non. C'est pourquoi la question de l'IA dans l'éducation est fondamentalement différente de la question de l'IA dans le travail.
Il y a aussi un risque de dimension collective. En s'appuyant sur les mêmes modèles de langage, formés sur des données dominantes, les nouvelles générations de développeurs risquent de converger vers des solutions génériques, formatées selon les biais statistiques de l'IA. L'industrie logicielle a été construite sur la diversité des approches architecturales, sur les solutions non-conventionnelles qui émergent de la lutte individuelle avec un problème. Cette lutte est exactement ce que l'IA peut effacer.
Ce que ça change, concrètement
Les recommandations du rapport sont pragmatiques, pas idéologiques. L'enjeu n'est pas de bannir l'IA du développement — c'est de comprendre quand et comment l'utiliser pour ne pas troquer la compétence contre la vitesse.
Pour les individus, la leçon est dans les six patterns. Demander à l'IA pourquoi une chose fonctionne plutôt que de faire la chose — c'est le pattern qui obtient 86% au quiz, supérieur au groupe sans IA. L'IA peut être un meilleur professeur qu'un moteur de recherche, à condition de lui poser les bonnes questions.
Pour les équipes, la notion de zones sans IA mérite d'être prise au sérieux. Réserver certaines tâches fondamentales au codage manuel — pas par nostalgie, mais pour garantir que l'expertise reste ancrée dans l'équipe. Mesurer non seulement la vitesse de livraison, mais la santé des compétences.
Pour l'éducation, différer l'usage de l'IA jusqu'à ce que les concepts de base soient maîtrisés manuellement. Concevoir des outils avec un "mode étude" qui guide par des questions plutôt que des réponses. Forcer la vérification de compréhension avant de permettre la soumission d'un code généré.
Pour les designers d'outils, le défi le plus intéressant : concevoir des interfaces qui rendent l'effort cognitif inévitable. Pas des barrières — des frictions désirables intégrées dans l'expérience.
L'avance de trésorerie
Shen et Tamkin concluent avec une métaphore financière qui résume tout. L'IA, dans ses usages délégateurs, fonctionne comme une avance de trésorerie sur l'expertise future. Vous obtenez la solution maintenant. Mais vous payez plus tard — avec des intérêts — sous forme de lacunes conceptuelles et de vulnérabilités de supervision.
Sur une tâche isolée, l'arbitrage peut sembler raisonnable. Sur une carrière entière, ou sur une génération entière de développeurs formés à l'IA, les intérêts composés de ce manque d'expertise sont difficiles à calculer — et plus difficiles encore à rembourser.
Le défi du XXIe siècle ne sera pas de construire des IA plus performantes. Ce sera de concevoir une collaboration humain-IA qui préserve ce que l'IA ne peut pas remplacer : la compréhension profonde, forgée dans la friction de la résolution de problèmes, qui seule permet de détecter les défaillances invisibles des systèmes automatisés.
Retour aux deux groupes de chirurgiens. L'un a regardé le robot opérer. L'autre a appris en opérant. Dans dix ans, quand le robot sera omniprésent et parfait à 99,7% du temps, le seul médecin capable de gérer les 0,3% restants sera celui qui a transpiré sur les cas difficiles — sans filet.
Picture two groups of surgeons in training. The first learns by operating: incisions, mistakes, corrections, sweat. The second watches a surgical robot perform each gesture, perfectly, in real time. After six months, both groups pass their training procedures. But if the robot fails mid-operation during a real procedure, who do you want in the operating room?
This scenario isn't hypothetical. It's playing out silently in thousands of software development teams worldwide. And in 2026, two researchers had the uncomfortable idea to measure it.
A question nobody wanted to ask
Judy Hanwen Shen and Alex Tamkin, in their study "How AI Impacts Skill Formation", asked a deceptively simple question: when a developer uses AI to solve a problem, do they learn the problem — or just how to use AI?
The question is uncomfortable. The tech industry has massively invested in code generation tools. Productivity gains are real, documented, sold. Questioning the learning happening behind those gains means questioning an entire paradigm.
Shen and Tamkin did it anyway. And what they found has a name in their report: the "learning tax" — the hidden cost of cognitive delegation.
The experiment: 52 developers, an unfamiliar library, and a stopwatch
The protocol is elegant in its simplicity. 52 professional developers. All experienced in Python. None had ever touched Trio — an asynchronous programming library chosen precisely because it introduces genuinely new concepts: structured concurrency, nurseries, an execution model that forces you to rebuild your mental model from scratch.
Participants are randomly split into two groups. The treatment group has access to GPT-4o for 35 minutes to solve two complex Trio problems. The control group has only documentation and the web. Then both groups take the same quiz without AI — conceptual understanding, code reading, debugging.
The implicit industry assumption: the AI group finishes faster and learns at least as much.
The results invalidated both halves of that assumption.
The numbers nobody expected
On speed first. AI didn't significantly accelerate task completion.
Average time with AI: 23–24 minutes. Without AI: 26–28 minutes. Statistically insignificant gap (p = 0.391). Screen recordings explain why: some participants spent up to 11 minutes — more than a third of the available time — composing queries or trying to understand the assistant's responses. AI isn't automatically fast. It's fast when you know how to talk to it.
On learning, the numbers are unambiguous.
| Group | Average quiz score |
|---|---|
| With AI | 50% |
| Without AI | 67% |
A seventeen-point gap. The equivalent of two grade levels. Effect size: d = 0.738 — what researchers classify as "large," meaning it's difficult to attribute to chance (p = 0.010).
And perhaps the most troubling element: this gap is uniform, regardless of prior experience. Whether the developer had one year or seven years of Python, those who used AI to delegate problem-solving systematically retained less of Trio's concepts.
AI didn't help less experienced developers catch up with seniors. It reduced everyone's retention, equally.
Where the gap is widest: debugging
The evaluation decomposed three skill types. The results aren't uniform.
Code reading — understanding what a block does without running it — shows the smallest gap between groups. Makes sense: during the task, both groups had to read code, with or without assistance.
Conceptual understanding — grasping why Trio works the way it does, what nurseries are, how structured concurrency changes the execution model — shows a significant gap. AI users bypassed the moment of mental model construction.
But it's debugging where the gap is most pronounced.
This isn't a minor detail. Debugging is the skill of understanding why something doesn't work — reading an error, tracing its origin, diagnosing the root cause. It's also the most critical skill for supervising code you didn't write yourself.
In other words: it's exactly the skill you need to verify what AI produces.
Six ways to use AI — and what they do to your brain
One of the study's most original contributions is classifying observed behaviors into six distinct patterns, identified through analysis of screen recordings and the 147 queries sent to the AI.
The three low-score patterns (compromised learning):
Total Delegation is the most radical: the developer hands the entire task to AI. They finish fastest. They score around 24% on the quiz. They solved the problem without ever understanding how.
Progressive Trust starts promisingly: the developer tries alone, hits a wall, then delegates everything to AI for the second half of the task. The problem is solved. The understanding is fragmented, precisely at the point where concepts were becoming interesting.
Iterative Debugging is perhaps the most widespread: copy-paste the error into AI, paste the proposed solution, repeat. No pause to understand why the code failed. Average score: 39%.
The three high-score patterns (preserved learning):
Conceptual Inquiry is the most performant pattern in the entire study — and it's counter-intuitive. These developers don't ask AI to write code. They ask about principles: "How does a nursery work?" "What's the difference between Trio and asyncio?" Then they write the code themselves. Average score: 86% — higher than the no-AI group.
Generate then understand: AI generates, but the developer pauses on each line, asks follow-up questions, validates their understanding before submitting. Cognitive effort remains present, just reoriented.
Hybrid code-explanation: asking AI for code along with a detailed explanation. The forced reading of the explanation maintains cognitive engagement, even though AI produced the code.
The classification's conclusion is precise: what distinguishes enriching AI use from impoverishing AI use isn't the quantity of AI used. It's the direction in which cognitive effort is oriented. Interrogating principles preserves learning. Delegating solutions destroys it.
Difficulty isn't a bug. It's exactly what we were avoiding.
The no-AI group made more errors. Median 3 errors across the entire task, versus 1 for the AI group. And that's precisely why they learned more.
It's important to distinguish error types. Python syntax errors — a typo, a forgotten variable name — are corrected in seconds and teach nothing about Trio. Trio-specific errors, however — a coroutine never awaited with await, a misuse of an async function — are entry points into the library's deep workings. They force documentation consultation, force understanding of the asynchronous execution model, force reasoning reconstruction.
The no-AI group encountered these errors, resolved them autonomously, and embedded the corresponding mental models in long-term memory. The AI group often received correct code on the first try — skipping the crucial problem-solving step that anchors understanding.
Friction wasn't an obstacle to learning. It was the learning. AI erased it. And with it, the memory trace.
This phenomenon is well-documented in cognitive science: desirable difficulty — the principle that learning conditions that feel hard and uncomfortable produce superior long-term retention compared to facilitated conditions. AI, in its most delegating uses, optimizes for immediate comfort — exactly what harms durable memorization.
The supervision trap
Here's where the implications extend beyond individual learning to become a systemic issue.
As AI takes over code writing, the engineer's role evolves toward that of a verifier. But verifying complex code requires expertise at least equal to that needed to write it. This is what the report calls the "Supervision Trap".
The researchers draw a parallel with Tesla's Full Self-Driving system. The near-perfection of the system over long periods creates driver vigilance decay. When AI finally makes an error in a critical situation, the driver — disconnected from the control loop — takes an average of 5 to 8 seconds to react. Those seconds make the difference.
An engineer accustomed to accepting AI's "perfect" code develops the same reflex. They lose the muscle memory of debugging — that capacity to sense something is wrong, to instinctively know where to look, to recognize an error's pattern before even reading the message.
The organizational consequences are concrete. Silent hallucinations — unlike crashing code with an error message, a security vulnerability or subtle logical error triggers no immediate alert. Only an expert can spot it. And if experts were trained with AI rather than despite it, that expertise is hollow.
Companies could accumulate what the report calls a verification debt: a stock of code that "works" in appearance, but that nobody on the team can maintain or repair without external assistance. Invisible until it isn't.
Atrophy versus foreclosure: two very different problems
The study distinguishes two phenomena that tend to get conflated, but which have radically different implications.
For a senior developer who already has solid mental models, using AI is a form of delegation. If they stop exercising certain skills, they experience atrophy: the capacity weakens from disuse, but the neural pathways still exist. If needed, they can be reactivated. Uncomfortable, but reversible.
For a student or junior developer, the mechanism is fundamentally different. Delegating to AI doesn't mean automating a known task — it means substituting the learning process itself. The researchers call this cognitive foreclosure: the neural pathways for critical evaluation, error resolution, deep system understanding are never formed. Not weakened. Never built.
An individual who never learned to debug on their own can never "recover" that skill — because it never existed in their cognitive repertoire.
Atrophy can be treated. Foreclosure cannot. That's why the question of AI in education is fundamentally different from the question of AI in professional work.
There's also a collective risk. By relying on the same language models trained on dominant datasets, new generations of developers risk converging toward generic solutions, formatted according to AI's statistical biases. The software industry was built on the diversity of architectural approaches, on unconventional solutions that emerge from individual struggle with a problem. That struggle is exactly what AI can erase.
What this changes, concretely
The report's recommendations are pragmatic, not ideological. The issue isn't banning AI from development — it's understanding when and how to use it without trading competence for speed.
For individuals, the lesson is in the six patterns. Asking AI why something works rather than to do the thing — that's the pattern scoring 86%, higher than the no-AI group. AI can be a better teacher than a search engine, provided you ask the right questions.
For teams, the concept of no-AI zones deserves serious consideration. Reserving certain fundamental tasks for manual coding — not out of nostalgia, but to ensure expertise remains anchored in the team. Measuring not just delivery speed, but skill health.
For education, delaying AI use until baseline concepts are mastered manually. Designing tools with a "study mode" that guides through questions rather than answers. Forcing comprehension verification before allowing generated code submission.
For tool designers, the most interesting challenge: designing interfaces that make cognitive effort unavoidable. Not barriers — desirable frictions embedded in the experience.
The cash advance
Shen and Tamkin conclude with a financial metaphor that summarizes everything. AI, in its delegating uses, functions like a cash advance on future expertise. You get the solution now. But you pay later — with interest — in the form of conceptual gaps and supervision vulnerabilities.
On a single task, the trade-off might seem reasonable. Over an entire career, or an entire generation of AI-trained developers, the compound interest of this missing expertise is difficult to calculate — and harder still to repay.
The challenge of the twenty-first century won't be building more powerful AI. It will be designing human-AI collaboration that preserves what AI cannot replace: deep understanding, forged in the friction of problem-solving, which alone enables detection of invisible failures in automated systems.
Back to the two groups of surgeons. One watched the robot operate. The other learned by operating. In ten years, when the robot is omnipresent and perfect 99.7% of the time, the only physician capable of handling the remaining 0.3% will be the one who struggled through the hard cases — without a safety net.