It’s Not the AI. It’s How You Use It

Chapter 5 Deep-Dive: The Comprehension You Trade Away

Companion document to “Software Development in the Agentic Era”

By Mike, in collaboration with Claude (Anthropic)

---

The main guide’s Chapter 5 says agents make skill atrophy worse, not better: the more the AI does, the less you engage, and the less equipped you become to evaluate what it produces. That’s the right instinct. But “AI rots your brain” is now a genre, and most of it overshoots — generalizing from one EEG study, treating correlation as proof, and skipping the part that actually matters for practice: the loss is conditional on how you use the tool, and at least one intervention has been shown to reverse most of it.

This chapter narrows the main guide’s claim to one the evidence supports:

AI assistance degrades the specific skills needed to oversee AI — comprehension, code reading, and debugging most of all — but the degradation is driven by interaction pattern, not by AI use per se. The same tool that enables the loss can also be configured to prevent most of it. The open question is no longer whether disengaged AI use can impair oversight skills; it’s how large the effect is in real teams, and whether teams will build the friction back in deliberately, because nothing in the default workflow does it for them.

That second sentence is what separates this from the doom genre. The finding isn’t “stop using AI.” It’s that cognitive engagement is a design variable — of the tool, the workflow, and the team’s norms — and right now most default workflows are not designing for it.

It helps to split the territory into three questions, each handled by a different part of this chapter:

• Mechanism — how does the skill loss happen, and is it the same thing as ordinary cognitive offloading? (Part 1.)
• Trajectory — who does it hit, when does it show up, and does it reverse? (Part 2.)
• Intervention — what actually restores comprehension without throwing away the productivity? (Part 3.)

The three are related but not interchangeable. You can understand the mechanism precisely and still get the trajectory wrong (assuming juniors are the only ones at risk). You can map the trajectory and still pick interventions that don’t work (mandating “review more carefully,” which is the skill that’s atrophying). The main guide treats these together; this deep-dive separates them because the evidence, the failure modes, and the fixes are different for each.

---

Part 1: The Mechanism — Offloading Is Not Outsourcing

1.1 The Anthropic Skill Formation RCT, Read Carefully

The centerpiece evidence is the study the main guide already cites: Shen and Tamkin’s How AI Impacts Skill Formation (arXiv 2601.20245, published January 29, 2026). It’s worth reading precisely, because it’s both stronger and narrower than the headlines suggest.

The design: 52 mostly-junior software engineers, all regular Python users, all unfamiliar with Trio (an async library). Random assignment to AI-assisted or hand-coding. Each completed a warm-up, two coding features using Trio, and a comprehension quiz they’d been warned about in advance. The AI group had a sidebar assistant that could produce correct code on demand.

The result: the AI group averaged 50% on the quiz; the hand-coding group averaged 67% — a 17-percentage-point gap (Cohen’s d = 0.738, p = 0.01), which the authors gloss as nearly two letter grades. The AI group finished about two minutes faster, but that difference was not statistically significant. The largest gap was on debugging questions — the ability to recognize when code is wrong and understand why it fails.

Three things about this study deserve emphasis that the headline number buries.

First, the speed gain mostly didn’t materialize. Several AI participants spent up to 11 minutes — 30% of their allotted time — composing as many as 15 queries. The productivity story everyone assumes (“faster but dumber”) wasn’t even fully true here: on a genuinely novel task, many participants were neither faster nor better. The speedup AI delivers is real on familiar, repetitive work; on learning something new, it can evaporate into prompt-composing overhead.

Second, the skills that degraded are exactly the oversight skills. The authors deliberately weighted the quiz toward debugging, code reading, and conceptual understanding — the three competencies you need to validate AI output. They explicitly downweighted low-level code writing (syntax recall) on the reasoning that it matters less as AI integration deepens. So the study isn’t measuring some incidental academic skill; it’s measuring the precise capability the agentic era depends on most.

Third — and this is the part the doom coverage drops — AI use didn’t guarantee a lower score. How participants used the assistant determined how much they retained. That finding is the hinge of this entire chapter, so it gets its own section below.

A caveat the authors are scrupulous about, and so should we be: the sample is small (n=52), comprehension was measured immediately after the task, and whether immediate quiz performance predicts durable skill is unresolved. The authors also note the setup — a chat assistant in a sidebar — is not an agentic tool, and they expect “the impacts of such programs on skill development are likely to be more pronounced.” That scoping matters for how this chapter uses the study: it is evidence about learning mode — someone acquiring an unfamiliar skill — not about an experienced developer directing agents on a familiar system, a distinction Part 2 builds on. Not every commentator accepts even this much; some practitioners argue the design has enough confounds (the artificial time pressure, the immediate quiz, the unfamiliar-library framing) that it shouldn’t be load-bearing at all. That criticism is worth holding onto: this is one RCT, preliminary by its own authors’ description, and the burden it can carry is “directional and corroborated,” not “settled.”

Source: Shen & Tamkin, “How AI Impacts Skill Formation,” arXiv:2601.20245, January 2026; Anthropic blog post, January 29, 2026.

1.2 Offloading Versus Outsourcing — The Distinction That Does the Work

The reason “how you use it” matters more than “whether you use it” rests on a mature body of cognitive science, not a single recent paper. The foundational work is Risko and Gilbert’s Cognitive Offloading (Trends in Cognitive Sciences, 2016), which framed the act of shifting cognitive work onto external tools and catalogued its two faces: a benefit (reduced demand now) and a cost (reduced internal capacity later). The cost has a name and a physiological signature — cognitive disuse atrophy. The cleanest demonstration predates AI entirely: heavy GPS users show measurably reduced hippocampal grey matter and perform worse on unaided navigation (Dahmani & Bohbot, 2017). When an external tool reliably performs a cognitive function, the internal capacity for it declines through disuse. A 2026 review in Nature Humanities and Social Sciences Communications synthesizes a decade of this work, and the UK Department for Education’s 2026 guidance on classroom AI now treats safe use as a design-and-supervision problem rather than a feature question. The general mechanism is mature; its exact shape in AI-mediated software development is still being mapped.

What’s newer — and worth flagging as such — is the specific two-term split between offloading and outsourcing. That framing is Paul Kirschner’s, sharpened in a January 2026 essay (“Offloading? No Outsourcing!”), and it isn’t yet field consensus. Kirschner’s own complaint is that much of the literature uses the two words interchangeably; a Brookings report he cites used “offloading” 57 times for what he’d call outsourcing. So treat the vocabulary as one scholar’s useful coinage, still settling, while the distinction it points at is solidly grounded in the offloading research above. The split:

• Cognitive offloading — delegating extraneous load. Letting the AI handle boilerplate, syntax lookup, the mechanical parts you already understand. Kirschner’s framing: the tool supports cognition, and you still do the thinking. It’s what a calculator does for arithmetic you could do by hand.
• Cognitive outsourcing — handing over the thinking itself: the intrinsic load where the mental model would have formed. The system thinks; you consume the result. This is the kind that accumulates debt.

The phrases sound interchangeable and aren’t. The same keystroke — “write me this function” — is offloading if you already grasp the concept and outsourcing if you don’t. The tool can’t tell the difference. Only the user’s existing understanding can, which is why the effect is so strongly mediated by who’s at the keyboard and what they do next. Kirschner’s own test is exactly this chapter’s: using AI to critique your draft or check your reasoning is offloading; asking it to write the draft or do the reasoning is outsourcing.

This maps directly onto the Anthropic study’s interaction patterns. The low-scoring patterns (all averaging under 40%) were outsourcing: full AI delegation (fastest, weakest comprehension), progressive reliance (started engaged, drifted into delegating everything), and iterative AI debugging (using the AI to fix problems rather than to understand them). The high-scoring patterns (65%+) were offloading-plus-engagement: generation-then-comprehension (generate, then ask why it works), hybrid code-explanation (ask for code and explanation together), and conceptual inquiry (ask only concept questions, code independently).

The conceptual-inquiry group is the one to sit with. They asked the AI no coding questions — only conceptual ones — coded by hand, hit lots of errors, and resolved them independently. They scored highest and were the fastest of the high-scoring groups, second-fastest overall behind pure delegation. Asking the AI to teach rather than to do was both better for learning and barely slower. The intuition that engagement always costs speed is wrong; the cheapest high-comprehension path was to use AI as a tutor, not a contractor.

One honest limitation: these clusters are tiny (the high-scoring groups were n=2, n=3, and n=7), and the authors are explicit that the patterns are associative, not causal. They describe behaviors correlated with outcomes, not a proven lever. The mechanism is plausible and consistent across sources; the cluster sizes mean it should be held as a strong hypothesis, not a demonstrated law.

Sources: Risko & Gilbert, “Cognitive Offloading,” Trends in Cognitive Sciences, 2016; Dahmani & Bohbot, 2017 (GPS/hippocampus); “Meta-cognitive insights into cognitive offloading,” Nature Humanities & Social Sciences Communications, 2026; Kirschner, “Offloading? No Outsourcing!” 2026; Sankaranarayanan, arXiv:2602.20206, 2026; Shen & Tamkin (2026); UK DfE AI-in-education guidance, May 2026.

1.3 What the Neuroscience Does and Doesn’t Add

The most-cited piece of evidence in popular coverage is MIT Media Lab’s “Your Brain on ChatGPT” (Kosmyna et al., 2025): 54 participants writing essays under three conditions (LLM, search engine, brain-only), EEG across 32 regions, plus a fourth session where 18 participants swapped tools. The findings are striking — brain-only writers showed the strongest, most distributed neural connectivity; LLM users the weakest; search-engine users in between. LLM users also reported the lowest ownership of their essays and struggled to quote work they’d produced minutes earlier.

It’s tempting to treat this as the biological proof under the behavioral findings. Resist that a little. Three reasons for caution:

• It’s essay writing, not coding. The transfer to software engineering is an inference, not a measurement.
• EEG connectivity is a measure of engagement, not of learning or harm. Lower connectivity during a task you’ve offloaded is exactly what you’d predict; it doesn’t by itself establish a durable deficit. “Brain goes into power-saving mode” is a vivid quote, not a finding about long-term capability.
• The durable-effect evidence rests on the 18-person fourth session — a small subgroup of an already-small study.

What the MIT study legitimately contributes is convergent: a different method, on a different task, with a different population, pointing the same direction as the coding RCTs — disengagement tracks with reduced retention and ownership. That’s worth something precisely because it’s independent. It is not worth treating as the mechanistic bedrock, and the chapter’s argument doesn’t need it to be. The behavioral evidence (quiz scores, maintenance-task failure rates) carries the load; the neuroscience rhymes with it.

Source: Kosmyna et al., “Your Brain on ChatGPT: Accumulation of Cognitive Debt,” MIT Media Lab, 2025.

1.4 A Note on the “Cognitive Debt” Family of Terms

A thicket of near-synonyms has grown up here. Cognitive debt (MIT) is the borrow-against-future-capability framing; comprehension debt (Karpathy) and cognitive debt (Fowler/Joshi, Chapter 4 deep-dive) name the team-level version — code shipped that nobody understands; epistemic debt (Sankaranarayanan) is the gap between system complexity and human grasp; intent debt (Tsui et al., Chapter 2 deep-dive) is lost rationale. They’re not identical, but they share a structure: a cost invisible to velocity metrics that comes due only when someone needs to change a system they no longer understand. This chapter is about the individual root of that family — the skill that doesn’t form — upstream of all the team-level variants.

---

Part 2: The Trajectory — Who, When, and Whether It Reverses

2.1 Learning Mode and Production Mode Are Different Risks

The obvious story is “juniors are at risk because they delegate.” True, but the cleaner frame isn’t seniority — it’s mode. The same developer moves between two of them, and the atrophy risk is different in each.

In learning mode — a junior, or anyone in unfamiliar territory — the danger is foundational: outsourcing the struggle that would have built the skill in the first place. This is the Anthropic-RCT case, and the chat-assistant evidence applies directly. In production mode — an experienced developer in a familiar domain — code-writing is genuinely less central; agents do the typing, and as Chapter 4 argued, the human work has moved to specification, validation, and containment. We’re past the point of debating whether agents can code faster than humans on many bounded implementation tasks; they can. So the at-risk skills in production aren’t syntax and boilerplate — they’re the high rungs: architectural reasoning, system-behavior judgment, and the ability to tell whether the thing the agent built does what the domain actually requires.

The junior-pipeline data shows the learning-mode risk at scale. Stanford’s Digital Economy Lab, using ADP payroll data, found employment for software developers aged 22–25 had fallen nearly 20% from its late-2022 peak by September 2025, even as employment for older developers in the same field held steady or grew. Across the broader set of most-AI-exposed occupations, their controlled estimate was a 13–16% relative employment decline for young workers after firm-level effects. The authors are careful that these patterns may partly reflect factors other than generative AI. The mechanism they propose: AI is absorbing exactly the boilerplate, CRUD, and routine work the junior role existed to do — and seniors now do it themselves with AI rather than handing it down. The entry rung is being compressed, which means fewer people pass through the mode where the foundation gets built. This connects to the main guide’s “Perpetual Junior,” for which the Sankaranarayanan study supplies a sharper name: fragile experts, “developers whose high functional utility masks critically low corrective competence.” They ship working features and cannot fix them when they break.

But production-mode atrophy is real too, and it climbs past juniors. Two cross-domain analogies — not software evidence, but suggestive of the same dynamic — are worth one line: a year-long study of cancer specialists using AI decision support (Ehsan et al., 2026) found expert judgment gradually dulling, which the authors call “intuition rust,” and the broader medical-deskilling literature (March 2026 scoping review) reports similar erosion across radiology and pathology. Within software, a practitioner analysis (TianPan, 2026) argues the highest-pressure zone is mid-career engineers — senior enough that managers push hardest for AI utilization, not yet senior enough to notice their architectural-reasoning skills softening from disuse.

2.2 Why Debugging Is the Oversight Skill

The hinge between learning mode and production mode is debugging. It’s the skill hardest to shortcut, which is exactly why its erosion matters most in agentic development.

In a traditional workflow, debugging is part of construction: you write the code, hit the failure, inspect your assumptions, and update your mental model. In an agentic workflow that loop is easy to bypass. The agent produces a plausible implementation, explains it fluently, runs the tests, and hands back a clean summary. The developer can review the output without ever forming the model that would let them notice where it’s wrong.

That matters because debugging expertise doesn’t transfer well from abstract instruction. The expert-novice literature is consistent: experts debug using accumulated mental models, chunking, and pattern recognition, while novices reason line by line (Vessey, 1985), and attempts to teach expert strategies directly have shown limited transfer (ACM, The Debugging Mindset). The feel is built by doing, not by being told. The same review’s sharpest observation is that the most dangerous bugs come from programmers who falsely believe their mental model is complete — precisely the state an agentic workflow manufactures: if the agent built the system and you never formed the model, you don’t just have an incomplete picture, you can’t see its edges.

This is why debugging matters more, not less, as agents write more of the code. The human can only validate agent output by reconstructing enough of the system’s behavior to notice when the fluent answer is wrong. Tests help but don’t replace that model; they only sample it. AI can help build the model rather than bypass it — asking why code fails, what a function assumes, how a path executes — subject to the offloading-versus-outsourcing distinction from Part 1.

Debugging is therefore the bridge skill: built in learning mode and spent in production mode. A developer who stops writing boilerplate loses little. A developer who never builds the debugging model — or lets it lapse completely — loses the capability that makes agentic oversight possible.

Sources: Stanford Digital Economy Lab, “Canaries in the Coal Mine” (Brynjolfsson, Chandar, Chen, 2025); Ehsan et al. (2026), “intuition rust” (cross-domain); ScienceDirect scoping review on AI deskilling in medicine (2026, cross-domain); TianPan, “The Skill Atrophy Trap” (2026); Vessey, “Expertise in Debugging Computer Programs,” 1985; Stitt, “The Debugging Mindset,” ACM Queue, 2017.

2.3 The Confidence Trap

What makes the trajectory dangerous is that it’s self-masking. Several studies and practitioner reports point toward the same confidence-trap pattern: developers who use AI heavily may feel more capable while performing worse on unaided tasks once the tool is removed. It’s the Dunning-Kruger effect with a technological accelerant: the tool produces working output in exactly the areas where you’d otherwise have gotten stuck, so you never receive the failure signal that tells you the skill is missing. From the inside, “I did it” and “the tool did it” feel identical.

Practitioner survey reporting makes the behavioral version concrete: a large majority of developers say they don’t fully trust AI-generated code, yet only about half say they consistently verify it before committing — even as AI accounts for a rising share of committed code. (These figures circulate through practitioner write-ups rather than a single primary survey, so treat them as directional.) The gap between declared skepticism and actual behavior is the atrophy engine running in production. Everyone knows they should verify more carefully; verification leans on exactly the comprehension and debugging model that erodes when you stop building it independently.

This is why “just review more carefully” fails as an intervention. The capacity to review carefully is downstream of the comprehension that’s eroding. You can’t will yourself to catch a bug you no longer have the mental model to recognize.

2.4 Reversible, or Foreclosed?

The honest answer is: it depends on whether the skill was ever built, and the evidence is thinner than anyone would like.

The most useful framing comes from a March 2026 Psychology Today analysis distinguishing atrophy from foreclosure. An expert who offloads a skill they understand is making a deliberate efficiency tradeoff; the capacity exists, it’s just not being exercised, and the atrophy is probably recoverable — the way an unused muscle rebuilds. A novice who never builds the skill because AI did it from day one experiences something different: the neural pathways for that reasoning never formed. “You can’t atrophy a muscle that was never built.” That’s foreclosure, and it “may not be reversible the way atrophy is.”

This is a conceptual distinction with limited direct empirical backing for software specifically — it’s reasoned from developmental psychology and analogy, not from a longitudinal coding study, and should be flagged as such. But it reframes the junior-pipeline data from Part 2.1 in a sharper way: the concern isn’t only that juniors are being hired less. It’s that the ones who are working may be foreclosing on skills that seniors got to build before the tools existed — and there’s no guarantee a later course-correction rebuilds what was never there. Where recovery is possible at all, the analogy to physical deconditioning suggests it’s a matter of sustained deliberate practice, not a quick reset.

Where this leaves us: atrophy in already-skilled developers is probably reversible with deliberate practice. Foreclosure in developers who never built the skill is the genuinely worrying case, and it’s the one the employment data suggests we’re running at scale. Neither claim is settled, and both deserve the hedge.

Source: Cook, “Adults Lose Skills to AI. Children Never Build Them,” Psychology Today, March 2026.

---

Part 3: The Intervention — Building the Friction Back In

This is where the chapter earns its keep, because there’s now direct experimental evidence that the loss is preventable — not just exhortation to “stay engaged.”

Agentic workflows make this more urgent, because each step moves the human farther from the act of construction. With autocomplete you still see the next line; with chat assistance you review a generated block; with an agent you may receive a finished plan, patch set, test run, and summary all at once. Each layer raises the odds that “review” becomes accepting a narrative rather than reconstructing what the system actually does. That is why the intervention has to target comprehension before integration, not validation after deployment — and why the evidence below, though gathered on a chat-style tool, points at the workflow agentic teams most need.

3.1 The Explanation Gate: An RCT With a Real Counterfactual

The Sankaranarayanan study (arXiv 2602.20206) didn’t just measure the loss; it tested a fix. Between-subjects, N=78, recruited via Prolific and UserInterviews to represent AI-native learners, using a custom Cursor IDE plugin (VibeCheck) backed by Claude 3.5 Sonnet. Three conditions: manual (control), unrestricted AI, and scaffolded AI.

The scaffold was an Explanation Gate: before generated code could be integrated, the developer had to explain its causal logic in their own words, and an LLM-as-judge — scoring against the SOLO taxonomy, a learning-depth rubric — decided whether the explanation showed genuine causal understanding or mere restatement. Restatements were rejected; relational, causal explanations passed. A “teach-back” protocol, automated.

The results are the most actionable finding in this chapter:

• Both AI groups crushed the manual control on functional utility (p < .001) and didn’t differ from each other (p = .64). The code worked equally well whether or not the gate was present. In this task, the gate did not reduce shipped functionality.
• In a subsequent 30-minute AI-blackout maintenance task, the unrestricted group failed at 77%; the scaffolded group at 39%. Roughly half the failure rate. Reframed as bug-repair competence: unrestricted AI cratered it to about 23% (under a third of the manual baseline); the gate recovered it to about 62% — within striking distance of hand-coding.
• The cost was about 14 extra minutes per session, largely subsidized by the speed of generation, with 89.1% task completion preserved. Epistemic debt (the study’s composite measure) dropped from 69.3 to 27.6.

The shape of this result is the important part. The intervention didn’t sacrifice the productivity — both AI groups shipped working code fast — it bought back most of the comprehension for a modest time cost, using the same AI that caused the loss, with no human reviewer in the loop. That last point removes the usual scalability objection to “make people explain their code”: the judge is itself an LLM.

Caveats, because this is one study too: N=78, novices rather than working professionals, a single library/task, Claude 3.5 Sonnet specifically, and an LLM-judge whose grading is only as good as the SOLO operationalization. The effect is large and the mechanism is principled, but “replicated across populations and tasks” it is not. It’s the strongest intervention evidence this chapter relies on, which is a different claim from definitive.

Source: Sankaranarayanan, “Mitigating ‘Epistemic Debt,’” arXiv:2602.20206, March 2026.

3.2 Stance Beats Tooling

The same study’s qualitative analysis surfaced the finding that generalizes beyond any plugin: outcomes tracked the user’s interactional stance, not just the tool’s constraints. Successful participants in the unrestricted group — no gate forcing them — spontaneously adopted a consultant stance: interrogating the AI, asking why, treating it as something to learn from. The unsuccessful ones adopted a contractor stance: handing off the work and integrating whatever came back.

This is the Anthropic study’s interaction patterns arriving from a second, independent direction. Consultant stance ≈ conceptual inquiry and hybrid code-explanation. Contractor stance ≈ delegation and progressive reliance. Two studies, two methods, two populations, the same underlying variable: whether the human stays in the reasoning loop. The convergence is the strongest thing in this chapter — stronger than either study alone — precisely because the methods don’t share a failure mode.

The practical implication: the Explanation Gate works because it forces a consultant stance on people who’d default to contractor. For developers who already hold a consultant stance, the gate is redundant friction. This is why interventions should be calibrated, not universal — a point Part 3.3 turns into an ordering.

3.3 What Actually Helps, Ranked

The main guide’s Chapter 5 mitigations are directionally right. What this deep-dive adds is a priority order — because not all of them carry equal evidence or equal leverage, and a list that treats them as equal hides the one move that’s actually been shown to work.

1. Use AI for conceptual inquiry, not code generation, when learning something new. (Highest leverage, best evidence.) This is the single behavior both RCTs converge on: it produced the best comprehension and, in the Anthropic study, was the fastest of the high-scoring patterns. It costs almost nothing and is the closest thing to a free lunch in this literature. “Ask how it works before you ask it to write it.”
2. Add an explanation/teach-back gate for novel or high-stakes work. (Strong direct evidence, real cost.) The VibeCheck result shows a forced teach-back roughly halves later maintenance-task failure for ~14 minutes per session. Worth it where the code will live and where the developer is still building the relevant model; redundant for genuine experts offloading skills they already have. Calibrate by stakes and by who’s coding, not blanket.
3. Generate-then-comprehend as a default loop. (Good evidence, low friction.) When you do let the AI write, ask a follow-up: why this approach, what breaks it, what was the alternative. The Anthropic generation-then-comprehension group did exactly this and scored in the high band. It’s the lightweight version of the gate, self-imposed.
4. Deliberately alternate AI-assisted and AI-free work. (Practitioner consensus, weaker formal evidence.) The “AI-blackout maintenance task” in the VibeCheck study is essentially this as a measurement; as a practice, periodically solving something without the tool both maintains the skill and surfaces — to you — whether it’s eroding. Deliberate non-use is a diagnostic, not just a discipline.
5. Use built-in learning modes in unfamiliar territory. (Plausible, under-tested.) Claude Code’s Learning/Explanatory modes and ChatGPT’s Study Mode are designed to push conceptual engagement; Anthropic’s own write-up points to them. They operationalize the consultant stance by default. Direct comparative evidence that they improve retention in production settings is still thin.
6. Track skill debt the way you track tech debt — at the team level. (Organizational, mechanism-level.) The confidence trap (Part 2.3) means individuals can’t self-diagnose reliably. Periodic unaided exercises, “explain this module without AI” as a recognized competency, and architectural-reasoning checks catch at the team level what individuals will systematically miss about themselves.

The ordering is the argument. Most published advice lists these flat, which implies they’re interchangeable. They aren’t: items 1–3 have experimental support and items 4–6 lean on consensus and analogy, and item 1 is both the best-supported and the cheapest. If a team does only one thing, it should be that one.

3.4 The Organizational Trap That Defeats All of It

Every intervention above is friction, and friction is exactly what organizational incentives are tuned to remove. A 2026 analysis of AI-adoption incentive structures found managers with shorter time horizons pushing for higher AI-utilization rates than the employees whose decade-long careers were actually on the line. The short-term signal (output looks fast and clean) overrides the long-term one (independent reasoning capacity declining), and the people setting utilization targets aren’t the ones who’ll be unable to debug the system in three years.

This is the same shape as Amazon’s 80% mandate from the Chapter 1 deep-dive: an adoption KPI that creates pressure to outsource rather than offload, because outsourcing is faster and the cost is deferred and invisible. A team that rewards “explain it without the AI” as a genuine competency will sustain these practices; a team that frames an explanation gate as compliance overhead will game it exactly the way perfunctory code reviews get gamed today. The friction has to be felt as valuable, not as tax. That’s a culture problem, and no plugin fixes a culture problem.

The deeper point, echoing the main guide’s conclusion: the developer who understands the system is now more valuable, not less, because they’re the only one who can validate what the agent produces. An organization that optimizes that capability away is optimizing away the thing that makes the agent safe to use.

---

Part 4: Self-Assessment

In the spirit of the Chapter 1, 2, 3, and 4 self-assessments — questions designed to surface the answer rather than confirm a hope.

On mechanism.

• When you reach for the AI, are you offloading something you already understand, or outsourcing the part where the understanding would have formed? The keystroke looks the same; only you know which it is.
• The last time the AI wrote something non-trivial for you, could you have written it yourself — and could you debug it now if it broke at 2am with the AI unavailable?

On trajectory.

• Do the developers who use AI most on your team rate their skills highest? Do they score highest when you take the AI away? If those two answers diverge, you’re looking at the confidence trap directly.
• For your juniors: are they building skills they could lose and rebuild (atrophy), or skipping skills they’re never forming (foreclosure)? The second is the one that doesn’t fix itself.
• If you removed AI tomorrow, who on the team could still reason from constraints to architecture without a generated scaffold to react to?

On intervention.

• When someone integrates AI-generated code, does anything in your workflow require them to demonstrate they understand it — or does “tests pass” stand in for “I understand this”?
• When was the last time someone on your team deliberately solved something without AI, and was that treated as a reasonable use of time or as falling behind?
• Is your AI-adoption target a utilization percentage? If so, it’s a pressure to outsource, and it’s pulling against every mitigation in Part 3.

The summary question.
If your most AI-fluent developer had to maintain, under pressure, a system they shipped six months ago with heavy AI assistance — would they be a senior engineer who understands it, or a fragile expert who produced it? If you don’t know, that uncertainty is itself the finding.

---

Conclusion

The main guide framed Chapter 5’s territory as “the more the AI does, the less you engage.” A year of evidence supports the direction and sharpens the claim: it’s not AI use that degrades the oversight skills, it’s disengaged AI use — outsourcing the intrinsic load instead of offloading the extraneous. The Anthropic RCT and the VibeCheck RCT, arriving by different methods at the same place, both say the determining variable is whether the human stays in the reasoning loop, and the VibeCheck result adds the part the doom genre never gets to: the loss is largely preventable, with the same AI that causes it, for about fourteen minutes a session.

The parts that look durable: the offloading/outsourcing distinction explains why “whether you use AI” is the wrong question and “how” is the right one; the learning-mode/production-mode split explains why the answer differs for a junior acquiring a skill and a senior directing agents on a familiar system; the oversight skills (debugging, reading, conceptual grasp) are precisely the ones that degrade and precisely the ones the agentic era needs; and the consultant-versus-contractor stance is the lever, whether enforced by a tool or held as a habit.

The parts still settling — and this field is moving fast enough that the caveat is load-bearing — are most of the magnitudes. The 17-point gap is one small RCT its own authors call preliminary. The reversibility-versus-foreclosure split is reasoned from analogy more than from longitudinal coding data. The Explanation Gate is one study on novices with one model. Treat the direction as well-supported and convergent — multiple independent groups reached compatible conclusions across early 2026 — and treat every specific number as provisional, to be updated as the replications land.

One thing to watch regardless of which specifics hold up: the failure mode here is silent. Technical debt eventually announces itself in slowed velocity; comprehension debt announces itself only when someone needs to change a system nobody understands, and by then the skill that would have let them is the one that didn’t form. The teams that do well across tooling generations will be the ones that treated cognitive engagement as something to design for — in the tool, the workflow, and the incentives — rather than something to hope survives a workflow built entirely for speed.

The most advanced AI skill in 2026 isn’t getting the agent to write the code. It’s remaining the kind of engineer who could have.

---

Key References

Source	Year	Relevance
Shen & Tamkin, “How AI Impacts Skill Formation” (arXiv:2601.20245)	2026	Core RCT: n=52; AI group 50% vs 67% on comprehension quiz (d=0.738, p=0.01); debugging hit hardest; interaction pattern mediates outcome
Sankaranarayanan, “Mitigating ‘Epistemic Debt’” (arXiv:2602.20206)	2026	Explanation Gate RCT (N=78): unrestricted-AI maintenance failure 77% vs scaffolded 39%; ~14 min cost; offloading/outsourcing distinction; consultant vs. contractor stance
Kosmyna et al., “Your Brain on ChatGPT” (MIT Media Lab)	2025	EEG study (n=54, fourth session n=18); weakest connectivity and lowest ownership for LLM users; convergent, not foundational
Stanford Digital Economy Lab, “Canaries in the Coal Mine” (Brynjolfsson, Chandar, Chen)	2025	ADP payroll data; ~20% decline for software developers aged 22–25 from late-2022 peak; 13–16% relative decline (controlled) for young workers in most-exposed occupations; authors caution against sole causal attribution to AI
Ehsan et al., “intuition rust” (oncology AI decision support)	2026	Cross-domain: expert judgment dulls with sustained AI reliance (not software evidence)
ScienceDirect, scoping review of AI deskilling in medicine	2026	Cross-domain: deskilling across radiology and pathology (not software evidence)
Cook, “Adults Lose Skills to AI. Children Never Build Them,” Psychology Today	2026	Atrophy (recoverable) vs. foreclosure (maybe not) distinction
Lee et al., “Impact of Generative AI on Critical Thinking” (Microsoft Research, CHI)	2025	Cognitive offloading reduces independent critical thinking
TianPan, “The Skill Atrophy Trap” (practitioner analysis)	2026	Mid-career risk zone; trust-vs-verify behavior gap; organizational incentive misalignment
Macnamara et al., “Does AI Assistance Accelerate Skill Decay…”	2024	Skill decay without performer awareness — the confidence trap
Anthropic, “Estimating Productivity Gains”	2025	Counterpoint: AI speeds tasks where skill already exists (up to 80%); reconciles with skill-formation findings
Risko & Gilbert, “Cognitive Offloading” (Trends in Cognitive Sciences)	2016	Foundational offloading framework; metacognitive triggers and disuse-atrophy costs
Dahmani & Bohbot, GPS use and hippocampal grey matter	2017	Pre-AI demonstration of cognitive disuse atrophy from tool reliance
Kirschner, “Offloading? No Outsourcing!”	2026	The offloading-vs-outsourcing distinction (recent coinage, not yet field consensus)
“Meta-cognitive insights into cognitive offloading” (Nature Hum. & Soc. Sci. Comms.)	2026	Decade-spanning review reconciling offloading mechanisms and interventions
UK Dept. for Education, AI-in-education guidance	2026	Treats safe educational AI use as a design-and-supervision problem (emphasis on safeguards and appropriate pupil use); does not formally adopt the offloading/outsourcing terminology
Vessey, “Expertise in Debugging Computer Programs”	1985	Expert/novice debugging; chunking and accurate mental models built through experience
Stitt, “The Debugging Mindset” (ACM Queue)	2017	Expert strategy instruction doesn’t reliably transfer; dangerous bugs from falsely-complete mental models