AI coding creates two kinds of debt. You're only measuring one

Antonija Bilić Arar · article · 2026-06-18 source ↗ Reader 🖥️

Cognitive Debt Cognitive Surrender Desirable Difficulty & Productive Struggle DORA & Engineering Metrics Learning Culture & Slack Measuring AI Impact Mental Models & Understanding Meta-Skills & Contextual Judgment Pair & Mob Programming Pull Requests & Async Code Review Technical Debt

AI-generated code creates a second, largely invisible kind of debt — cognitive debt, the erosion of shared team understanding of what a system does and why, distinct from ordinary technical debt in the code itself — and it is a genuine measurement blind spot: satisfaction scores, NPS and mentor ratings can hold steady or rise while it accumulates, so organizations must replace satisfaction-based signals with trajectory-based skill measurement and deliberate team-level questions to catch it before it becomes irreversible.

practical · mixed (expository argument built on interview testimony and two case studies) — Imports one theoretical construct (Storey's 'cognitive debt', itself grounded in Naur's programming-as-theory-building) but the piece's payload is operational: a controlled study, a longitudinal internship dataset, and a set of concrete organizational practices. Structured as journalism (direct quotes from Storey and Jurić) rather than first-person argument.

Structure

Part	Role
Opening: Dr. Margaret-Anne Storey's classroom anecdote (Oct 2025) — students who used AI to move fast lost track of who understood which part of their system.	Coins and defines the term via a lived example
Definition section: cognitive debt as accumulated loss of understanding of what/why/who-knows-what; explicitly distinguished from technical debt (clean code can still carry it); grounded in Peter Naur's 'programming as theory building'.	Theoretical warrant
Anthropic's January 2026 RCT: 52 junior developers, AI-assisted group scored 17% lower on code comprehension, ~two letter grades.	First evidentiary pillar — controlled, quantitative
Infobip's internal longitudinal study: 8 cohorts, 225 interns, 2022–2026, pre-AI vs. AI-era comparison across four self-assessed growth dimensions; satisfaction/NPS/mentor scores flat-to-rising while growth fell.	Second evidentiary pillar — real-world, longitudinal, practitioner-generated
R10 vs. R8 vignette: same tool, same frequency, opposite engagement, opposite growth (+3 vs. 0).	Mechanism narrative
Infobip's concrete intern rules (try-first-check-second, AI sequencing, AI-free checkpoints, mentor-as-coach, visibility of standards, measure trajectory not satisfaction).	Prescriptive payload
Storey's team-level retrospective questions (who can explain each component; when did we last check features against user needs; who understands each subsystem).	Diagnostic payload at the team/system level, complementing Infobip's individual/cohort-level metric
Closing contrast: technical debt is a known, repayable tradeoff; cognitive debt has no repayment mechanism and can only be prevented, not refactored away.	Final distinguishing claim, raises the stakes of the whole piece

Key terms

Cognitive debt Cognitive Debt
The accumulated loss of understanding of what a system does, why, and who on the team knows what — a property of the system/project, not of an individual ('there is no my cognitive debt'). You can have clean, well-tested code and still carry it if the people who built it can no longer account for it, or if understanding is concentrated in one person.
Technical debt Technical Debt
Used strictly as the contrast term: a known, well-understood engineering tradeoff that leaders already know how to find and repay (refactor). Its familiarity is what makes cognitive debt's unfamiliarity and irreversibility legible.
Productive struggle Desirable Difficulty & Productive Struggle
The 'wrestling with a problem' that Jurić identifies as the actual mechanism of learning, and which AI removes when used for generation-and-acceptance rather than generation-and-inquiry. Never defined precisely — used descriptively, not operationally.
Dunning-Kruger gap
Operationalized narrowly as the numeric difference between an intern's self-rating at internship start and their retrospective self-rating of that same starting point, measured today. Used as a proxy for miscalibrated self-awareness of one's own skill trajectory.

Propositions

explicitestablishedCognitive debt is the accumulated loss of understanding of what a system is doing and why and who on the team knows what — distinct from technical debt, which concerns the code itself.conf: high
extendsThe Intent Debt · p1 — This is the primary-source interview with Storey, who coined the term in Oct 2025 and grounds it in Naur's programming-as-theory-building — the direct source Osmani's Triple Debt Model import was paraphrasing secondhand.
supports ←Guillaume Barrois' Post · p2 — The author's first-person account of 'losing the plot' is a concrete illustration of exactly the cognitive-debt dynamic the other document formalizes as an accumulated loss of system understanding.
supports ←Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development · p2 — Restates the same mechanism — loss of understanding of what a system/change is doing when an agent produces it — from the angle of PR review rather than cognitive-debt terminology, and proposes observability grounding as a partial counter-signal.
extends ←Technology Radar, Volume 34 · p14 — The Radar's 'codebase cognitive debt' blip names the same concept (gap between implementation and shared understanding) and adds the AI-swarm-specific acceleration mechanism and three candidate countermeasures that the two-kinds-of-debt piece does not offer.
explicitYou can have clean, well-tested code and still have cognitive debt if the people who built it can no longer fully account for it, or if that understanding is concentrated in one person rather than distributed across the team.conf: high
explicitdevelopedStandard engineering metrics do not surface cognitive debt, because it is precisely the kind of blind spot leaders don't know to check for.conf: high
extends ←The 8 software engineering metrics AI broke · p1 — extract-ai-coding-two-kinds-debt's claim is narrowly about cognitive debt as one specific blind spot standard metrics miss; this article broadens the same underlying diagnosis (activity metrics don't surface what actually matters) to the entire standard metrics stack — deployment frequency, cycle time, PR volume — not just cognitive debt specifically.
explicitcorroboratedIn a randomized controlled trial with 52 junior developers, those who used AI assistants scored 17% lower on code comprehension tests than the comparison group — roughly two letter grades.conf: high
extendsCognitive Surrender · p4 — Same underlying Anthropic RCT (January 2026, junior developers) as extract-cognitive-surrender#p4, with more procedural detail (N=52, 'nearly two letter grades'), but framed as 'used AI assistants' vs. a comparison group rather than extract-cognitive-surrender's 'generation vs. conceptual-inquiry posture' framing — the two paraphrases may describe different comparison arms of the same paper (see gap g3).
supports ←The End of Programming as We Know It · p5 — Osmani's 'house of cards code' / junior-engineers-accept-AI-output-too-readily observation, quoted here, is the same mechanism behind the comprehension-debt findings that gap names (junior engineers losing the judgment to catch bad AI output).
explicitInfobip's 8-cohort, 225-intern longitudinal survey found self-assessed skill growth fell across all four measured dimensions (technical, teamwork, problem-solving, personal excellence) for AI-era cohorts versus pre-AI cohorts, with the starkest gap (+2.89 vs. +0.69) appearing across 2.5 years as heavy AI usage rose from 0% to 54%.conf: medium
explicitcorroboratedOver the same period, Infobip's program satisfaction metrics (NPS, calibration ratings, mentor scores) held stable or rose even as measured skill growth fell — satisfaction is not a valid proxy for learning under AI-assisted work.conf: high
supportsCognitive Surrender · p9 — Concrete longitudinal evidence (Infobip's rising satisfaction/NPS alongside falling skill growth) for extract-cognitive-surrender's claim that current organizational metrics (PRs merged, tickets closed, and here also NPS/satisfaction) are systematically blind to the offloading/surrender distinction.
supports ←The 8 software engineering metrics AI broke · p5 — Both claim satisfaction-type scores can rise while something substantive (engagement/meaning here, skill growth there) falls under AI use. This article asserts the dynamic by argument; extract-ai-coding-two-kinds-debt independently corroborates it with Infobip's 8-cohort/225-intern longitudinal data (NPS/mentor scores flat-to-rising while measured skill growth fell) — real measurement backing this article's unsupported assertion.
explicitestablishedThe determining factor is not how much AI is used but the cognitive posture toward it: interns who asked follow-up questions and demanded explanations of AI output grew (R10: +3, highest in cohort); those who accepted output as a black box did not (R8: 0), despite using the same tool at the same frequency.conf: high
supportsCognitive Surrender · p7 — Fresh empirical corroboration (Infobip's R10 vs. R8, same tool and frequency, opposite outcomes) for extract-cognitive-surrender's core claim that outcome depends entirely on the user's posture, not the tool or its frequency of use.
supports ←How I Use Agents Without Stopping My Own Growth · p6 — Currie's self-reported instinct-building from sustained deep review is an individual-level anecdote matching the Infobip finding that cognitive posture (asking follow-up questions, demanding explanations) — not raw AI usage — is what predicts skill growth.
supports ←Coding agents have crossed a chasm · p8 — Both identify the same mechanism -- a developer's cognitive posture/foundational engagement, not raw AI exposure -- as what determines whether AI use builds or erodes capability; the Infobip intern cohort gives this a measured, comparative version of the author's single anecdotal 'mirror effect' claim.
implicitdevelopedAI accelerates the loss of the organically-formed 'mental map of who knows what', because juniors now default to asking an AI instead of a senior colleague when stuck, so the senior never learns what the junior struggled with.conf: medium
extends ←The More Accessible Information Is, the Less Employees Remember · p2 — Generalizes the coding-specific observation that AI accelerates loss of the 'mental map of who knows what' into a broader, experimentally-demonstrated connectivity tradeoff between content memory and network memory that holds even without AI in the loop.
implicitcontestedBecause cognitive debt is a property of the system/team rather than of any individual, no individual-level dashboard or self-report can surface it — it can only be assessed through deliberate, team-level diagnostic questions.conf: medium
contradicts ←Guillaume Barrois' Post · p5 — This post implicitly treats cognitive debt as repayable through individual habits (planning, personal PR review timing), while the other document argues cognitive debt is a property of the team/system that no individual-level practice or dashboard can surface or repay.
explicitcontestedUnlike technical debt, cognitive debt has no repayment mechanism: you cannot run a script to recover understanding engineers never built or restore shared understanding a team never had — the only lever is prevention, not repair.conf: high
contradictsThe Intent Debt · p5 — Storey (interviewed directly here, as the term's originator) states cognitive debt has no repayment mechanism — you cannot recover understanding never built or restore understanding a team never had. Osmani's piece claims agents can 'partially pay down cognitive debt' by re-explaining code. Direct tension between the primary source and Osmani's secondhand gloss (see gap g4).
contradicts ←From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p9 — Bilić Arar's article (whose cognitive-debt definition closely follows Storey's) claims cognitive debt 'has no repayment mechanism... the only lever is prevention, not repair.' Storey's own paper explicitly lists repair practices for cognitive debt (walkthroughs, retrospectives, and especially cheap AI-assisted reimplementation to rebuild understanding), directly challenging the stronger irreversibility claim -- this is the same tension this corpus's extract-ai-coding-two-kinds-debt#g4 gap already flagged against the Osmani extractions, now traced to its origin.

Arguments

Cognitive debt is real, distinct from technical debt, and current engineering metrics fail to detect it. strength: medium

Explicit premises:

Cognitive debt is the accumulated loss of who-understands-what, not a property of the code
Clean, well-tested code can still carry cognitive debt
Standard metrics don't surface it because it's an unknown blind spot

Implicit premises:

Existing engineering metrics were built to track velocity, quality and delivery stability (i.e., technical-debt-adjacent properties), not distributed tacit understanding
A construct that doesn't move deployment/velocity/satisfaction metrics stays invisible to leaders who manage by those metrics

Inferences:

Generalizes from one expert's classroom observation to a systemic organizational property
Infers metric-blindness from the definitional contrast with technical debt, which existing metrics were designed around

Satisfaction-based metrics actively mask the decline that trajectory-based skill measurement reveals. strength: medium