Intent Debt

The absence of externalized rationale, goals and constraints in artifacts agents can read — the one debt AI cannot pay down because the why must originate with humans.

Also known as: intent debt, Intent debt, externalize (intent), tacit intent, load-bearing rationale, cold start (of an agent session), plausible guess (about intent), externalization, cognitive artifacts

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (15)

• AI Development Patterns Paul Duvall · 2026-10-08 source ↗ Reader 🖥️
  Organizations should adopt this catalog's AI-development patterns selectively and in an order diagnosed from their own team size, project type, and technology stack — not uniformly or in catalog order — because the coordination problems a solo developer needs to solve (rapid iteration, tool-matching) are categorically different from, and the patterns designed for them can actively mismatch, what a two-pizza team or a multi-team organization needs (parallel-agent isolation and conflict resolution, cross-team traceability, automated review of agent output at volume).
• Coherence, Connections, and… Spacetime Crystals Art Anthony · 2026-09-09 source ↗ Reader 🖥️
  A technically well-performing API is close to worthless if it isn't coherent with the organization's goals, ownership, and structure — and because organizations and their APIs change constantly, that coherence has to be continuously mapped and re-established rather than achieved once and assumed to hold.
• The AI-Native SDLC playbook Louis Claxton · 2026-08-21 source ↗ Reader 🖥️
  Once agentic coding collapses the build phase to hours, the traditional SDLC's human-speed controls (committees, meetings, line-by-line review) become the bottleneck and stop matching reality, so organizations should rebuild the lifecycle as a non-linear loop of six stages (plan, design, build, test, deploy, maintain) where every stage commits a version-controlled artifact the next stage reads, human judgment concentrates at artifact-acceptance gates rather than at the point of production, and governance is enforced as code (hooks, branch protection, managed settings) rather than through periodic human review bodies.
• Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review Leela Kumili · 2026-07-31 source ↗ Reader 🖥️
  AI-assisted code review only enforces security intent reliably if the review agent is grounded, at the moment of implementation, in the organization's own design-time security artifacts via a permission-aware retrieval layer exposed through a standardized protocol (MCP) — and even then the system must stay traceable and advisory rather than authoritative, because retrieval without reasoning-and-restraint just relocates the staleness problem instead of solving it.
• From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI Margaret-Anne Storey · 2026-07-28 Reader 🖥️
  Software debt should be reasoned about across three interacting layers of a software system rather than one -- technical debt (in code), cognitive debt (in the team's shared understanding), and intent debt (in externalized rationale and goals) -- because generative AI is simultaneously shrinking technical debt through automation while accelerating the other two, previously under-recognized and increasingly consequential, forms of debt; managing software health in the AI era therefore requires treating shared understanding and externalized intent as first-class deliverables with the same discipline historically reserved for code quality.
• Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture Stella Berhe, Stephan Bragner, Vikram Maran, Anand Jayaraman · 2026-07-14 source ↗ Reader 🖥️
  Because AI has decoupled writing code from understanding it, engineering organizations must run spec-anchored specification-driven development, test-driven development, and architectural fitness functions together as one verification system so that their combined artifacts form a versioned, queryable "context store" — making comprehension a lifecycle property of evolutionary architecture that both human reviewers and AI agents can draw on, rather than a pre-merge concern that AI-generated speed otherwise outruns.
• Five studies that are changing how I think about AI in software engineering Engineering Enablement · 2026-07-10 Reader 🖥️
  Five methodologically different studies converge on one story: AI has compressed the upstream code-generation work of software engineering, shifting the binding constraint downstream to review, integration, verification, and shared understanding, while our tools, metrics, and team designs have not yet moved with it.
• Agentic Code Review Addy Osmani (addyosmani.com) · 2026-07-06 source ↗ Reader 🖥️
  Because agents made writing code nearly free while understanding it stayed exactly as costly as ever, code review has become the binding constraint on shipping software — and since review must now reconstruct an intent that never existed in any human mind, the right amount of human review is not a fixed rule but a dial set by each change's blast radius.
• The Intent Debt Addy Osmani (addyosmani.com) · 2026-06-06 Reader 🖥️
  Intent debt — the absence of externalized rationale, goals and constraints in artifacts an agent can actually read — is the one of Storey's three debts (technical, cognitive, intent) that AI agents structurally cannot pay down, because intent is the one input that must originate with a human; and because agents start every session cold with no tacit memory, every gap in the externalized why is now paid every session by every agent, making the previously-affordable habit of carrying intent in your head the single most expensive workflow choice in agent-assisted development.
• Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering Chenyu Zhou, Huacan Chai, Wenteng Chen, Zihan Guo, Rong Shan, Yuanyi Song, Tianyi Xu, Congming Zheng, Jiachen Zhu, Zeyu Zheng, Zhuosheng Zhang, Xingyu Lou, Zhihui Fu, Jianghao Lin, Weinan Zhang · 2026-04-09 Reader 🖥️
  Practical progress in LLM agents increasingly depends not on improving model weights but on externalizing cognitive burdens into external infrastructure — memory, skills, protocols, and harness engineering — which together form a systems-level framework of cognitive artifacts.
• Encoding Team Standards Rahul Garg · 2026-03-31 source ↗ Reader 🖥️
  A team's standards for how AI should generate, refactor, secure, and review code must stop living as tacit judgment in senior engineers' heads or as unread documentation, and instead be encoded as small, versioned, repository-resident AI instructions — because an instruction's execution is its application, which turns consistent team judgment into a side effect of the normal workflow rather than a separate step that depends on someone remembering and applying it under pressure.
• Stop Using /init for AGENTS.md Addy Osmani · 2026-02-23 source ↗ Reader 🖥️
  AGENTS.md should hold only project-specific facts an agent cannot discover by reading the code itself — because auto-generated, comprehensiveness-optimized context files duplicate what agents already find on their own and measurably slow and bias them — and the file should function as a living log of unfixed codebase friction to be resolved in the code, not as a permanent, ever-growing configuration.
• Harness engineering: leveraging Codex in an agent-first world Ryan Lopopolo (OpenAI) · 2026-02-11 source ↗ Reader 🖥️
  Building a product with zero manually-written code at scale (one million-plus lines, five months, a team that grew from three to seven engineers with throughput that increased rather than degraded) required redefining engineering work from writing code to designing environments, pushing all team knowledge into repository-local legible artifacts, mechanically enforcing architectural invariants and documentation freshness, and relaxing human-paced process norms (blocking merge gates, manual cleanup) in favor of continuous, agent-driven correction — because human time and attention, not code production, is the one truly scarce resource the whole system must be organized to protect.
• Linear’s CEO just described the biggest shift in product team... Aakash Gupta · 2026-01-04 source ↗ Reader 🖥️
  As coding agents collapse the 'middle' translation step between product intent and working code, leverage shifts to the two points that don't automate away — forming and externalizing clear intent before execution, and reviewing agent output after it — so the teams that build structured, context-rich systems usable by both humans and agents will gain a durable structural advantage.
• How do software development teams manage technical debt? - An empirical study Jesse Yli-Huumo, Andrey Maglyas, Kari Smolander · 2016-08-08 Reader 🖥️
  Software development teams manage technical debt unevenly and mostly informally -- across eight distinct activities (identification, measurement, prioritization, prevention, monitoring, repayment, documentation, communication) teams sit at different maturity levels (unorganized, received, organized), and the key differentiator is not tooling but whether TD communication and documentation are treated as first-class practices, since every other activity depends on TD being visible and discussed rather than left in individual developers' heads.

Propositions touching this concept (18)

By publication month, oldest first (extraction month when no publication date is known).

2026-04

• explicitcorroboratedMemory, skills, and protocols are three distinct but coupled forms of externalization.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering · p4
• explicitHarness engineering is not just another form of externalization but serves as the unification layer that governs the other three.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering · p5
• implicitThe cognitive artifacts framework from cognitive science is the appropriate theoretical lens for understanding agent infrastructure.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering · p7
• explicitSelf-evolving harnesses and shared agent infrastructure represent the frontier of externalization.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering · p8

2026-06

• explicitcorroboratedIntent debt is the absence or erosion of EXTERNALIZED rationale, goals and constraints — not the absence of understanding, but the absence of understanding written down where an agent can read it.
  The Intent Debt · p2
• explicitFrom the inside the three debts 'feel similar' — they are not subjectively distinguishable, which is what lets intent debt accumulate undetected.
  The Intent Debt · p4
• explicitcontestedAgents can pay down technical debt (refactor a tangled module) and partially pay down cognitive debt (re-explain the code), but they cannot pay down intent debt.
  The Intent Debt · p5
• explicitcorroboratedAgents start most sessions cold and carry forward no tacit intent; whatever isn't externalized into a readable artifact, they simply don't have.
  The Intent Debt · p8
• explicitHigh intent debt is felt not as friction but as a 'particular kind of helplessness' — inability to defend or reconstruct a design choice.
  The Intent Debt · p15
• implicitcontestedIntent debt is primarily an individual-developer (and possibly individual-team) problem to be solved by personal discipline around externalization.
  The Intent Debt · p24

2026-07

• explicitSoftware-health debt has three distinct loci — technical debt (in code), cognitive debt (in people), intent debt (in artifacts) — and AI reduces technical debt (refactoring, test generation, automated review) while quietly accelerating cognitive and intent debt.
  Five studies that are changing how I think about AI in software engineering · p8
• explicitIntent debt is the unclear, unwritten, or forgotten goals, constraints, and rationale that both humans and AI agents need to work safely, and it becomes a first-order constraint on what AI can actually do as more development becomes AI-assisted.
  Five studies that are changing how I think about AI in software engineering · p9
• explicitThe three debts interact and compound causally — intent debt causes cognitive debt, cognitive debt causes technical debt, and technical debt amplifies cognitive debt — so managing system health requires attention to all three layers, not just the one easiest to measure.
  Five studies that are changing how I think about AI in software engineering · p11
• explicitestablishedSoftware debt is best understood as three interacting types mapped onto three layers of a software system -- technical debt (code and structure), cognitive debt (shared understanding across people), and intent debt (externalized goals/constraints/rationale in artifacts) -- and system health requires attention to all three, not just the layer that is easiest to measure.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p1
• explicitdevelopedGenerative AI is simultaneously reducing technical debt (via automated refactoring, AI-assisted review, and test generation) while accelerating the accumulation of cognitive and intent debt, because AI generates code faster than teams build genuine understanding of it or externalize the rationale behind decisions.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p2
• explicitThe three debts causally interact and reinforce each other: intent debt causes cognitive debt (undocumented purpose prevents accurate mental models), cognitive debt causes technical debt (poor understanding leads to poor implementation choices), and technical debt amplifies cognitive debt (messy code is harder to reason about) -- grounded in distributed cognition theory (Hutchins 1995), which treats cognitive processes as properties of systems of people and artifacts together.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p6
• explicitIntent debt can be diagnosed through three patterns: behavior drift from stakeholder expectations (often discovered only at testing or in production incidents), AI agents requiring excessive clarification or producing technically-correct-but-off-target solutions, and gradual loss of articulated non-functional constraints (performance, privacy, accessibility) known only to a few people.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p8
• explicitThe paper deliberately declines to resolve whether documenting intent is worth the effort, whether AI can substitute for the human work of building understanding, and whether some level of cognitive/intent debt is an acceptable strategic choice rather than always a risk -- flagging all three as live, unsettled disputes rather than arguing them to a conclusion.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p12

Open gaps (25)

• incompleteStorey's claim that cognitive debt 'has no equivalent' repayment mechanism is stated as an absolute, but the article never distinguishes understanding that was never built (plausibly unrecoverable) from understanding that was once held and has since decayed through disuse (plausibly recoverable via deliberate re-engagement, e.g. re-reading code or asking an agent to explain it back). This corpus's own Osmani extractions raise exactly that distinction and land on the opposite answer — that cognitive debt is partially recoverable this way — without either piece acknowledging the other's position.
  AI coding creates two kinds of debt. You're only measuring one — read next: extract-osmani-orchestration-tax-is-you#g5 (stock-and-flow model of cognitive debt, replenishment via re-reading) and extract-osmani-intent-debt#p5 (agents can 'partially pay down cognitive debt... re-explain the code') — see relations below for the direct tension.
• incompleteEvery play redefines the human's role (from author to reviewer, from implementer to orchestrator, from on-call responder to incident-queue triager) but the piece never addresses the human cost of that shift — skill atrophy from no longer writing code directly, morale effects of reviewing AI output all day, or how an organization trains new engineers who never practiced the skills the plays assume a senior reviewer already has.
  The AI-Native SDLC playbook — read next: Look for practitioner accounts (not vendor playbooks) of how teams that have run this kind of pipeline for a year or more describe the experience of the reviewer-not-author role, and whether junior engineers develop judgment without first doing the work themselves.
• uninformedThe piece is presented as consolidating 'real best practices our Applied AI team executes on a daily basis for our customers,' but every quantitative claim (leading/lagging indicators, 'elapsed time falls from weeks to hours') is prescriptive guidance on what to measure, not a reported result; no outcome data from an actual deployment appears anywhere in the piece.
  The AI-Native SDLC playbook — read next: Look for independent case studies, post-mortems, or DORA-style empirical measurement of organizations that adopted this specific stage structure, as distinct from vendor-authored playbooks.
• incompleteThe Amazon outage is presented as an outcome of the exact context gap this article diagnoses, but the article's own cited source (CNBC) attributes the outage to "changes merged without proper review" — a review-gate failure — not to a documented absence of persisted intent, behavior, or conformance records specifically. The causal attribution to the context gap, versus a more generic review-diligence lapse, is asserted rather than demonstrated from the available reporting.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Follow further Amazon incident reporting or post-mortems, if published, to see whether investigators identified a missing intent/behavior/conformance record specifically, or a simpler story of a skipped approval step that a context store would not by itself have prevented.
• incompleteThe article's context store distinguishes a machine-readable knowledge graph from a human-readable system spec, but doesn't interrogate whether prose-form specs can actually carry the relational structure that intent needs — priorities among constraints, non-negotiables versus preferences, time-bound versus principled rationale. This is the same gap the corpus has already flagged in Osmani's intent-debt series: existing artifact formats (specs, AGENTS.md, ADRs) may be "flat" against intent's real structure. The two-projection move is a step toward richer structure but stops short of specifying what the knowledge graph's schema actually captures that a flat spec would miss.
  Comprehension at AI Speed: Building a Context Store for Evolutionary Architecture — read next: Read against extract-osmani-intent-debt's gap on intent-as-data versus intent-as-prose, and knowledge-representation literature (description logics, semantic web) on what a genuinely structured, queryable intent schema would need to encode.
• uninformedEvery pattern in the catalog is presented with the author's own prescriptive worked example as its sole evidence; the catalog never cites an external case study, a controlled comparison, or independent practitioner validation for any individual pattern, despite the patterns ranging from simple (constraint-based prompting) to organizationally significant (atomic task decomposition coordinating parallel work across multiple teams).
  AI Development Patterns
• incompleteThe team-size framework (Solo / Two-Pizza / Multi Two-Pizza) treats team size as the organizing variable for pattern adoption but never addresses the transition itself — there is no migration path described from, say, a two-pizza team's Human-AI Handoff Protocol to a multi-team organization's Atomic Task Decomposition, only separate, static recommendations for each size category.
  AI Development Patterns
• incompleteThe Knowledge Hoarding anti-pattern correctly diagnoses that exhaustive AI-prompting documentation goes unmaintained, but its prescribed fix ('review and prune knowledge quarterly') assigns that maintenance work to no one in particular — the same ownership-diffusion problem the catalog's own 'Fragmented Handoffs' and 'Alert Fatigue' anti-patterns describe elsewhere, applied here to the knowledge base itself.
  AI Development Patterns
• incompleteThe two central anecdotes (two seniors with different severity thresholds; a junior catching a missing auth check) are both single, author-reported incidents from the author's own consulting practice. No measurement is offered of defect rates, review-quality variance, or time-to-competency before versus after adopting these instructions across a real team over time.
  Encoding Team Standards — read next: Look for quantitative studies measuring review-outcome or defect-rate variance across developers before and after adopting shared, versioned AI instructions, rather than anecdotal before/after accounts.
• incompleteThe transfer of the 'cognitive artifacts' framework from human cognition to LLM systems is asserted but not defended. Human cognitive artifacts augment a general intelligence; LLM externalization compensates for specific architectural limitations (finite context, no persistent state). The analogy may be more misleading than illuminating.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for critiques of anthropomorphic framings of LLM capabilities; compare with distributed systems or compiler theory as alternative analogies.
• incompleteThe taxonomy assumes memory, skills, and protocols are 'distinct but coupled' — but the boundaries may be artificial. A skill with embedded memory and protocol-like interfaces blurs all three categories. The abstract does not address how to handle such overlap.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Check whether the full paper provides clear criteria for categorizing borderline cases.
• uninformedThe abstract does not address whether externalization introduces new failure modes (brittleness, composability failures, versioning conflicts) that may offset reliability gains. The framing is almost entirely positive.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Look for systems engineering literature on integration risk; check if the full paper's 'open challenges' section addresses this.
• illogicalThe historical progression 'weights -> context -> harness' is presented as a clean trajectory, but in practice these co-evolve. Larger context windows reduce the need for some externalization; better weights reduce the need for elaborate harnesses. The narrative oversimplifies.
  Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering — read next: Consider whether a co-evolutionary or dialectical framing would be more accurate than a linear progression.
• incompleteNo metrics are given anywhere in the piece — no false-positive rate, no override/dismissal rate, no measured change in reviewer behavior or time-to-catch for security issues — after deploying Dash+MCP in code review. Every claim about avoiding 'a false sense of security correctness' and about developer trust is a stated design principle, never an evaluated outcome.
  Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review — read next: The linked Dropbox engineering blog post (dropbox.tech/security/dropbox-mcp-dash-design-code-security) or a follow-up post, if one exists, with adoption/precision data.
• incompleteThe system implicitly assumes security intent is always captured as a retrievable document (a threat model, a design doc). No discussion addresses requirements that were only ever expressed verbally in a design review, in a Slack thread, or as tribal knowledge — the same industry pattern that produced stale, disconnected documents in the first place also chronically under-documents decisions, and a purely retrieval-based fix cannot surface intent that was never externalized anywhere Dash can index.
  Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review — read next: Corpus pieces on intent debt (e.g. Osmani's framing that agents cannot pay down intent debt because the rationale must originate with humans) for the limits of a retrieval-only fix.
• incompleteThe argument assumes structured context supplied upfront substitutes adequately for the tacit judgment a human translator previously exercised during implementation, but does not address the risk — well documented elsewhere in this corpus under 'intent debt' — that structured artifacts can still omit load-bearing rationale an agent cannot recover, nor whether authoring sufficiently rich structured context simply relocates the translation labor earlier in the pipeline rather than reducing total coordination work.
  Linear’s CEO just described the biggest shift in product team... — read next: Compare against the corpus's intent-debt material (e.g. extract-osmani-intent-debt, extract-triple-debt-storey) on whether externalized structure reliably prevents the 'cold start' / unrecoverable-rationale problem for agents, and whether intent-debt discipline is realistically an organizational capability (as this thread claims) rather than only an individual one (as other sources argue).
• uninformedEvery quantitative claim in the piece (1/10th the time, 3.5 PRs/engineer/day, 1M+ lines, throughput increasing with team size) is self-reported by the team that built the system and has an organizational interest in publicizing it, with no external audit, no comparison codebase built by an equivalent human-only team under the same product requirements, and no stated method for what counts as a meaningfully-sized 'line of code' or PR.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteThe piece describes human review as optional ('Humans may review pull requests, but aren't required to... we've pushed almost all review effort towards being handled agent-to-agent') but never says what determines which PRs actually receive a human look versus none, or what happens when agent-to-agent review systematically misses the same class of issue because both the authoring agent and the reviewing agent share the same model's blind spots.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteThe recurring Osmani blind spot — third post in a row. Osmani diagnoses a structural problem (intent debt is an artifact-class agents cannot pay down; the cost is now paid per-session-per-agent) and then prescribes individual-developer disciplines. He never engages: (a) organizational incentives that actively reward visible-agent-activity over externalized intent (managers measuring spawn count, throughput pressure that captures any efficiency gain), (b) tooling vendor responsibilities (auto-generated /init flows that produce descriptive AGENTS.md rather than intent-bearing AGENTS.md; UIs that make spawning easy and rationale capture optional), (c) compensation structures that reward shipping over documenting. The individual-discipline frame puts the entire fix-burden on the developer and treats organizational/vendor pressure as background — the same move he made in 'The Orchestration Tax is You' and 'Comprehension Debt'. For Kjetil tracking this series, this is now a load-bearing limitation of Osmani's whole program, not a one-off omission.
  The Intent Debt — read next: Paul Reed 'Ironies of A^2 I^2' (already in this repo) on how orgs capture AI efficiency as throughput pressure. John Cutler on institutional overload and how teams metabolize new capabilities — particularly TBM 411-413 you've been tracking. Donella Meadows' leverage points: rule changes and goal changes outrank parameter changes. Greger Wedel-style 'leadership when the org pressures the opposite direction' on what happens when an individual-practice prescription meets organizational counter-pressure.
• incompleteOsmani concedes 'you can't write down everything' and resolves it as a load-bearingness triage problem — but never gives a criterion for identifying load-bearing decisions IN THE MOMENT (before you know which ones will matter later). This is the operationally hard part. Empirically, much rationale that turns out to be load-bearing did not look load-bearing at decision time. The 'capture the load-bearing why' guidance therefore risks being well-intentioned but unimplementable, or implementable only by people who already have the seniority to predict consequence — i.e., precisely the people whose departure creates the problem in the first place.
  The Intent Debt — read next: Naur 'Programming as Theory Building' on what kinds of decisions are reconstructible from code and which are not. Polanyi on tacit vs explicit knowledge. Decision-research literature (Annie Duke, your Thinking in Bets reading) on the inability to predict consequence and how that affects pre-commitment to recording rationale.
• incompleteThe series-level pattern is itself worth naming. Comprehension debt → orchestration tax → intent debt is now a tightly linked triptych, and Osmani treats them as cumulatively framing one diagnosis. But he never names the underlying disease. The candidate name — and the missing post — is something like 'externalization debt' or 'legibility debt': all three debts are downstream of a single failure to make the relevant signal (code, mental model, rationale) readable by something other than the senior engineer's head. The post that names that underlying disease, distinguishes it from the symptom-class, and asks what an externalization-first development culture looks like, has not been written. For Kjetil tracking the series, that is the post to ask Osmani for next.
  The Intent Debt — read next: Michael Polanyi 'The Tacit Dimension'. Edwin Hutchins 'Cognition in the Wild' on distributed cognition and externalization. Don Norman 'Things That Make Us Smart' on cognitive artifacts. Andy Clark on extended mind. Possibly David Weinberger 'Everything is Miscellaneous' on the conditions under which knowledge externalizes well.
• incompleteThe paper lists qualitative diagnostic signals for both cognitive debt (five signals) and intent debt (three patterns) but proposes no quantitative measurement instrument or threshold -- 'Monitor the three layers in tandem' suggests onboarding-time tracking and knowledge-concentration metrics only in passing, without operationalizing any of them.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI — read next: DORA/SPACE-style measurement-framework literature; this corpus's own osmani-intent-debt#g2 gap raised the identical measurement-thinness problem for Osmani's derivative treatment -- it turns out the primary source is no more quantified.
• uninformedThe paper's four practice recommendations are entirely team/individual-practice level (walkthroughs, ADRs, executable intent, monitoring) and never engage organizational incentive structures -- e.g. whether managers who measure throughput or visible agent activity will actually reward the diffuse, delayed payoff of externalization work over shipping speed. Kjetil's systems-thinking (Meadows) lens would flag this as an intervention at a low-leverage 'parameter' level (adopt this practice) rather than the higher-leverage 'rule' or 'goal' level (what does the organization actually reward).
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI — read next: Donella Meadows' leverage-points framework; this corpus's own osmani-intent-debt#g1 gap, which raised the identical individual-discipline-vs-organizational-incentive blind spot for Osmani's derivative piece and now applies equally to the primary source it draws on.
• incompleteThe paper's entire empirical picture assumes a world where code generation and TD accumulation proceed at a roughly human, team-paced rate -- manual identification, hunch-based prioritization, and optional documentation are treated as viable (if imperfect) coping strategies because the volume of debt being produced is bounded by how fast humans write code. The paper gives no basis for what happens to any of its eight activities once code generation volume is decoupled from human writing speed (i.e. coding agents), even though its own findings (documentation is the first casualty under time pressure; measurement/monitoring are already the rarest activities) predict exactly where an AI-era acceleration would break first.
  How do software development teams manage technical debt? - An empirical study — read next: The corpus's velocity-debt / debt-accelerator concept and the triple-debt (technical/cognitive/intent) framework pick up precisely where this 2016 baseline leaves off -- read this paper as the 'before' picture AI-era teams are accelerating away from.
• uninformedThe framework assigns documentation/representation responsibility to "the development team, software architect(s)" as an undifferentiated group, with no examination of whether documentation that exists only as unstructured JIRA tickets or personal notes functions any differently from documentation written to be read later by someone who wasn't present for the original decision -- the distinction between 'a record exists' and 'the record externalizes the rationale a future reader needs' is never drawn.
  How do software development teams manage technical debt? - An empirical study — read next: The corpus's architecture-decision-records and intent-debt concepts name exactly this distinction (a record vs. an externalized, load-bearing rationale) and would sharpen this paper's flat treatment of 'documentation' as a single undifferentiated activity.