Cognitive Debt

The growing gap between how much code or content exists and how much any human genuinely understands — the accumulated bill of unreviewed AI output.

Also known as: cognitive debt, Cognitive debt, comprehension debt, Comprehension debt, chain of understanding

How authors use it

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

Documents (33)

• Guillaume Barrois' Post Guillaume Barrois · 2026-10-08 source ↗ Reader 🖥️
  Building features at the speed coding agents enable creates 'cognitive debt' — an accumulating gap between what has been built and what the engineer still understands — which, like technical debt, must be deliberately repaid (through upfront planning, disposable prototyping, and PR-based review) or it will erode confidence and slow you down.
• Redefining the Software Engineering Profession for AI Mark Russinovich and Scott Hanselman · 2026-10-08 source ↗ Reader 🖥️
  Because generative AI amplifies senior engineering judgment while penalizing early-in-career developers, organizations must deliberately keep hiring and investing in EiC engineers through a structured 'preceptorship at scale' system -- senior mentors paired with AI tooling designed to teach, not just produce -- or the profession's talent pipeline will collapse.
• TBM 437: AI and the Recontextualization Tax John Cutler · 2026-09-03 Reader 🖥️
  Organizations pay a real, often-hidden cost -- the 'recontextualization tax' -- every time people flatten a working reality into a simplified version to suit whoever has the most power, the least appetite for detail, or the least time, and AI is newly good at absorbing that translation labor because it can render one underlying, accurate context into many audience-tailored formats without forcing teams to first standardize how they actually work.
• Loop Engineering: Building Blocks, Adoption, and Impact Jai Lal Lulla; Vahram Nersesyan; Seyedmoein Mohsenimofidi; Christoph Treude; Sebastian Baltes · 2026-08-28 Reader 🖥️
  "Loop engineering" has a stable, practitioner-agreed definition and set of building blocks (triggers, stop conditions, persisted state, verifiers, budgets, escalation points) for designing systems that repeatedly prompt coding agents instead of a human doing so turn by turn, but an exploratory mining study of 36,710 open-source repositories finds confirmed autonomous agent loops in only 0.59% of them, and shows that while loops' triggering configuration gets committed to version control, almost none of the prescribed runtime building blocks — state files, verifiers, budgets, machine-checkable goal conditions — do, leaving the practice's claimed value almost entirely untested by evidence.
• Human judgment doesn't leave the software factory. It relocates. Addy Osmani · 2026-08-21 source ↗ Reader 🖥️
  As software development moves from hand-coding to operating repeatable, event-driven 'software factories' of coding agents, human judgment does not leave the loop -- it relocates upstream to intent, system design, and the quality bar, and downstream to verification design, risk, and ownership of what ships -- so the best factories are defined by how intelligently they place human attention, not by how completely they remove it.
• Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development Claudio Masolo · 2026-08 source ↗ Reader 🖥️
  As AI coding agents let engineers generate diffs faster than they (or reviewing agents) can build genuine understanding of them, Grafana's newly-GA gcx CLI and MCP server let those same agents query live observability data (metrics, logs, traces, SLOs) during development, so that implementation and testing decisions are grounded in and checked against actual system behavior rather than training-data assumptions or a code review that has become unreliable.
• Presentation: The Free-Lunch Guide to Idea Circularity Holly Cummins · 2026-07-31 source ↗ Reader 🖥️
  Ideas in technology that look genuinely new are almost always old tradeoffs returning because the surrounding environment has re-tilted the balance, not novelties or evidence of forgetting -- and the same 'debt is a tradeoff with the future' logic that explains financial debt also explains technical, epistemic, ecological, and sleep debt, so recognizing which tradeoff underlies a current design is the transferable skill for spotting when a discarded old idea is about to become valuable again.
• Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough Ben Greene · 2026-07-28 Reader 🖥️
  Software engineers remain valuable in the age of coding agents not because they can still write code, but because building working systems still requires disciplined simplicity, deliberately protected comprehension, willingness to attack hard problems first, and human empathy for customers — capacities coding agents lack and that startups have always demanded of engineers under resource pressure.
• 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.
• Software Factories, Light and Dark AddyOsmani.com · 2026-07-20 source ↗ Reader 🖥️
  Because verification, not generation, is the real bottleneck of an AI-driven 'software factory,' an engineer's central job is to decide loop by loop how much autonomy each part of the pipeline can earn — full automation ('dark') only where a check is cheap, fast, and hard to fake, human judgment ('lit') everywhere else — with the human's own role relocating from writing code to owning and verifying that outer decision.
• 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.
• AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy Charity Majors · 2026-07-11 Reader 🖥️
  The AI enthusiast-versus-skeptic split inside high-performing engineering orgs is not one side being right and the other wrong but two groups each responding to a real existential threat (missed windows vs. systems decaying into slop) that they never see the other's side of, and the cure is to rebuild a shared reality by telling the whole story and then treat AI adoption as an engineering problem rather than a rhetorical war.
• 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.
• Finding Comfort in the Uncertainty Annie Vella · 2026-07-07 source ↗ Reader 🖥️
  The most valuable takeaway from a gathering of leading software practitioners on AI's impact is that nobody has it figured out — and that this shared uncertainty, together with a convergent set of hard questions the field is only beginning to name, is itself the ground for progress and a source of comfort rather than alarm.
• 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.
• AI coding creates two kinds of debt. You're only measuring one Antonija Bilić Arar · 2026-06-18 source ↗ Reader 🖥️
  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.
• The 8 software engineering metrics AI broke Michael Hill · 2026-06-16 source ↗ Reader 🖥️
  Software engineering metrics were built on the assumption that human effort and output move in rough proportion, and AI has severed that link by making activity nearly free — so activity/volume proxies (deployment frequency, cycle time, PR and commit volume, lines of code, satisfaction, efficiency/flow, DevEx/DXI) now measure tool adoption rather than engineering quality, while only outcome-based measures (time to recover, escaped defect rate, delivered value) remain trustworthy, because they measure what happened rather than how much happened.
• 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.
• Engineering Leadership Report 2026 Postman · 2026-06-05 Reader 🖥️
  Engineering leadership is undergoing genuine, compounding transformation — organizational flattening (now reaching upper management), expanding technical-plus-managerial scope, and AI adoption that has outpaced governance and measurement — and the organizations that come out ahead in 2026 will not be the ones that adopted AI fastest but the ones that built the trust, clarity, and investment in people that let AI amplify rather than erode human capability.
• Using AI to write better code more slowly Nolan Lawson (Read the Tea Leaves) · 2026-05-25 source ↗ Reader 🖥️
  LLMs are flexible enough to produce either fast, unvetted slop or slower, carefully reviewed and understood code, and deliberately choosing the latter — running multiple different models to hunt for bugs, personally validating and triaging what they find, and refusing to ship a PR you don't fully understand — is a better way to use AI for programming, even without a velocity payoff.
• The Orchestration Tax is You AddyOsmani.com · 2026-05-25 Reader 🖥️
  Because each developer is a single, non-parallelizable serial processor whose attention is the binding constraint on what agent-generated code can actually be merged, the only real fix for the 'orchestration tax' is to deliberately architect your own attention the way you architect any concurrent system — sizing the agent fleet to your review rate, sorting work by judgement-content, batching reviews, offloading verification to machines, and protecting your serial time.
• Doug Shannon's Post Doug Shannon, Anastasios (Tassos) Fountis, Victoria Dior Wang, Dr Scott Davies, Carrie Eckersley, Antony Evans, and others · 2026-05-19 source ↗ Reader 🖥️
  As AI absorbs more of the work of producing answers, the decisive human skill shifts from using AI well to thinking well about one's own thinking while using it — a disposition ('co-thinking', the 'Cyborg' stance) distinct from both AI dependency and from mere prompt skill, with early evidence (self-reported and cited brain-connectivity and creativity studies) suggesting this metacognitive posture determines whether AI sharpens or erodes a person's independent judgment.
• Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework Marc Millstone · 2026-05 source ↗ Reader 🖥️
  The same risk-and-differentiation framework that tells engineering teams where to grant AI autonomy also governs knowledge work like writing: delegate heavily where errors are cheap and recoverable, retain full ownership where the work carries the argument's credibility, and use AI as an adversarial critic rather than a ghostwriter.
• The Psychological Costs of Adopting AI Guy Champniss · 2026-05 source ↗ Reader 🖥️
  AI adoption strategies that focus only on productivity ignore six forms of 'psychological debt' (cognitive, autonomy, competency, relatedness, credibility, identity) that AI use imposes on employees, and unless companies deliberately design the human-AI relationship to mitigate these debts — through cognitive friction, explainability, peer-led training, visible normalization of AI use, and identity-affirming framings — the psychological cost will cancel out the productivity gains, making adoption a human-infrastructure problem as much as a technology problem.
• Technology Radar, Volume 34 Thoughtworks (Technology Advisory Board) · 2026-04-14 source ↗ Reader 🖥️
  AI-assisted, agentic software development is moving faster than the industry's ability to evaluate it, which means teams must simultaneously retain long-held craftsmanship principles (testability, deliberate design, feedback loops) and rethink team/agent topologies, trust boundaries and metrics that were built for a pre-agent world.
• Fragments: February 13 Martin Fowler · 2026-02-13 source ↗ Reader 🖥️
  As LLMs become established coding collaborators, software development is reorganizing around 'supervisory programming' in which developers herd fleets of agents — a shift that recasts the profession's central challenges as preserving a team's shared understanding of the system (cognitive debt), sustaining a developer experience that is effectively identical to agent experience, and containing the work-intensification and context-switching that driving many agents creates.
• Fragments: February 9 Martin Fowler · 2026-02-09 source ↗ Reader 🖥️
  As LLMs absorb more of the work of building software, the pressing questions are less about model capability than about what humans stand to lose — the team's understanding of the system (cognitive debt), the intellectual craft-joy of model-building, and even the meaning of 'source code' as behavior shifts from deterministic text toward non-deterministic natural-language prompting.
• Fragments: February 4 Martin Fowler · 2026-02-04 source ↗ Reader 🖥️
  AI is reshaping the developer's relationship to understanding: it can erode comprehension of the systems we build, is wisely used to navigate toward an answer but never trusted for the answer itself, and may make code cheap enough that the specification becomes the durable engineering artifact.
• The Future Of Software Engineering Thoughtworks · 2026-02 Reader 🖥️
  As AI takes over code production, engineering rigor does not disappear but migrates to specifications, tests, constraints, risk management, and a new 'middle loop' of supervisory work — and organizations that fail to deliberately rebuild their practices, roles, and governance around these new destinations will suffer compounding losses in quality, comprehension, and stability.
• We Studied 150 Developers Using AI (Here's What's Actually Changed...) Dave Farley (Modern Software Engineering) · 2026-01-27 Reader 🖥️
  A pre-registered, two-phase controlled experiment with 151 mostly-professional developers found that AI-assisted code is no harder or easier for a different developer to maintain later than human-written code, and slightly easier when written by experienced habitual AI users — because AI acts as an amplifier of a developer's existing skill and engineering practice, not a substitute for it, so maintainability outcomes are determined by practice and discipline, not by whether AI was used.
• Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect Simon Wardley · 2025-12 Reader 🖥️
  What is happening with AI is the industrialisation of machine learning — a one-way evolutionary shift to commodity/utility — and the right posture toward it is neither resistance nor hype but disciplined adaptation through the predictable 5-8 year co-evolution of practices, with explicit attention to where bottlenecks, supply-chain power, and inequality will actually land.
• How Microsoft Developers Use AI in Real-World Coding | BRK103 Microsoft Developer · 2025-05-21 source ↗ Reader 🖥️
  AI tools are most valuable to an individual developer not as autocomplete or as a replacement for judgment, but as a fast, tireless conversational partner for ideation, documentation, test generation, and debugging across a developer's own long-lived codebase — provided a knowledgeable human stays in the loop to evaluate, correct, and hold accountability for what the AI produces before it reaches the team's review process.
• Cognitive Surrender AddyOsmani.com · 2025-01-01 source ↗ Reader 🖥️
  When software engineers stop forming independent views of AI-generated outputs — crossing from cognitive offloading to cognitive surrender — they accumulate comprehension debt that compounds invisibly until a crisis reveals that no one on the team can reconstruct the system from first principles; the antidote is not refusing AI tools but cultivating a posture of mutual amplification: thinking *with* the model rather than delegating thinking *to* it.

Propositions touching this concept (37)

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

2025-01

• explicitcorroboratedCognitive surrender is the mechanism by which comprehension debt accumulates — each act of surrender is a tiny loan against future understanding.
  Cognitive Surrender · p3

2025-12

• explicitestablishedAs development accelerates, comprehension and the chain of understanding become the new bottleneck.
  Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect · p10

2026-01

• explicitCode bloat (excess code volume, now nearly free to generate) and cognitive debt (eroding developer understanding and skill from not thinking hard about AI-generated code) are two specific long-term risks the study's authors highlight that would not show up in a short-horizon sprint metric.
  We Studied 150 Developers Using AI (Here's What's Actually Changed...) · p8

2026-02

• explicitCognitive debt — the fragmentation or loss of a team's shared theory of the system — can paralyze a team faster than technical debt.
  Fragments: February 13 · p6
• explicitcorroboratedWhen much of the building work is delegated to LLMs, the development team no longer gains as much understanding of the domain and the software it is building — incurring 'cognitive debt'.
  Fragments: February 9 · p2

2026-04

• implicitCodebase cognitive debt and agent-accelerated change velocity reinforce each other in a vicious loop: weaker shared understanding of a system reduces developers' ability to steer agents effectively, which in turn produces more code nobody fully understands.
  Technology Radar, Volume 34 · p15

2026-05

• explicitcorroboratedUnpaid orchestration tax accumulates as both technical debt (merged-without-reading code) and cognitive debt (stale mental model of the codebase).
  The Orchestration Tax is You · p14
• explicitestablishedCognitive offloading to AI undermines users' understanding of the problem and reduces their sense of ownership of the solution; the loss accumulates as cognitive debt
  The Psychological Costs of Adopting AI · p3
• explicitdevelopedIntroducing cognitive friction (e.g., requiring hypothesis formation before AI use) preserves higher-order cognition and reduces cognitive debt
  The Psychological Costs of Adopting AI · p13
• explicitUsing AI superficially to automate thinking measurably reduces brain connectivity and accumulates cognitive debt, while engaging with AI only after first exercising one's own unaided cognitive processing increases brain connectivity — so AI makes deep thinkers sharper and shallow thinkers obsolete.
  Doug Shannon's Post · p7

2026-06

• explicitYou must understand agent-produced code to a depth that lets you keep participating creatively in the project; a rich set of concepts in your head is what preserves your ability to move the work forward, and drifting from it is cognitive debt.
  Have your agent record video demos of its work with shot-scraper video · p12
• 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.
  AI coding creates two kinds of debt. You're only measuring one · p1
• 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.
  AI coding creates two kinds of debt. You're only measuring one · p2
• explicitdevelopedStandard engineering metrics do not surface cognitive debt, because it is precisely the kind of blind spot leaders don't know to check for.
  AI coding creates two kinds of debt. You're only measuring one · p3
• 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.
  AI coding creates two kinds of debt. You're only measuring one · p9
• 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.
  AI coding creates two kinds of debt. You're only measuring one · p10
• 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
• explicitdevelopedThe recurring symptoms Osmani has named over recent months (comprehension debt, cognitive surrender, orchestration tax) are retroactively unified as instances of intent-debt management.
  The Intent Debt · p23
• explicitdevelopedComprehension debt (the growing gap between what exists and what the human actually understands) grows faster, not slower, as a smooth loop ships more code the human didn't write, unless the human keeps reading what the loop produced.
  Loop Engineering · p12

2026-07

• explicitcorroboratedComprehension debt (the growing gap between how much code exists and how much any human still understands) is not paid down by a dark factory; it is taken on as fast as possible, with tests green the whole way.
  Software Factories, Light and Dark · p7
• explicitModel-only automated coding fails specifically against comprehension debt in complex, brownfield, long-lived production systems (not in weekend/toy projects), because a decade-old enterprise codebase has to be maintained at a professional pace that a few months of unread development cycles can't survive.
  Software Factories, Light and Dark · p8
• explicitAI-driven volume produces new forms of debt beyond technical debt — cognitive debt, trust debt, and active knowledge decay — which are problems of identity, meaning, and accountability, not just process.
  Finding Comfort in the Uncertainty · p6
• 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
• explicitcorroboratedCognitive debt accumulates when a team's shared understanding erodes faster than it is replenished, because when AI generates code developers may accept it without building the mental model they would have built by writing it themselves.
  Five studies that are changing how I think about AI in software engineering · p10
• 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
• explicitCognitive debt is a team-level/project-level property, not an individual one -- it resides in accumulated gaps in shared understanding and awareness across a team, so a codebase can have low technical debt and still be deeply problematic if the team no longer understands it or if it no longer reflects the system's intended purpose.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p3
• explicitCognitive surrender -- adopting AI outputs with minimal scrutiny, bypassing System 1/System 2 reasoning -- is the psychological mechanism driving cognitive debt accumulation, and it is more dangerous than ordinary cognitive offloading because it also inflates developers' confidence even when the AI's output is wrong, which is precisely why cognitive debt stays invisible until it is too late.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p4
• 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
• explicitCognitive debt can be diagnosed through five visible signals even though it is not directly visible in code: resistance to change, unexpected results from changes, slow/unpredictable onboarding, loss of transactive memory (who knows what), and low bus factor.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p7
• explicitcontestedCognitive debt is partially repairable, not purely a one-way accumulation -- system walkthroughs, retrospectives/post-mortems, deliberate onboarding/offboarding communication, and (newly, because code generation is now cheap) reimplementing a feature with different tests or design specifically to rebuild understanding are all offered as active repair practices, not just prevention.
  From Technical Debt to Cognitive and Intent Debt: Rethinking Software Health in the Age of AI · p9

2026-08

• explicitdevelopedA human's own cognitive bandwidth does not scale with the number of parallel agent sessions they run, so parallel agentic work creates comprehension/cognitive debt and context-switching costs -- mental models going cold between sessions, decisions whose rationale isn't preserved anywhere -- that scale with session count, not with agent capability.
  Human judgment doesn't leave the software factory. It relocates. · p7

2026-09

• explicitThere are three hidden costs of ceding the outer loop: cognitive surrender (a Wharton study found nearly three-quarters of people accepted a wrong AI answer anyway and felt more confident for having consulted it), cognitive debt (an Anthropic RCT found engineers who leaned on AI scored 17 percentage points lower on a comprehension quiz, 50% vs. 67%), and the orchestration tax (steering, sorting, and verifying agent output does not parallelize with a person's cognitive bandwidth).
  Own the Outer Loop · p14

2026-10

• explicitThis feeling matches 'cognitive debt': like technical debt, it accumulates and must eventually be repaid (rebuilding a mental model via reading code/documentation, writing tests, running experiments) or it will slow the developer down.
  Guillaume Barrois' Post · p2
• explicitTwo possible long-term resolutions exist: engineering practice evolves to prevent cognitive debt from accumulating (more testing, continuously updated documentation, better review workflows), or code becomes an abstraction layer agents manipulate while engineers work one level up on specifications, constraints, and outcomes — with reality likely landing somewhere between the two.
  Guillaume Barrois' Post · p3
• explicitCurrent personal practices for managing cognitive debt: normalize throwing away code (especially proof-of-concepts), spend more time planning upfront to build a solid mental model before the agent starts writing code, and use pull requests as the specific checkpoint to 'repay' cognitive debt when feeling overwhelmed.
  Guillaume Barrois' Post · p4
• implicitcontestedThe post treats repaying cognitive debt as primarily a matter of individual developer discipline (personal planning habits, personal PR-review timing), even though one of the author's own two forecasted resolutions — evolving testing, documentation, and review workflows — is itself a team- or organization-level practice change, not an individual one.
  Guillaume Barrois' Post · p5

Tensions

Open gaps (66)

• illogicalThe article's own framing is internally inconsistent about scope: the intro promises 'ten metrics that are breaking down,' the SPACE section is introduced as covering 'a couple of metrics' but actually covers three, and the title promises '8' broken metrics — which does match the count of metrics explicitly presented as broken (3 DORA + 3 SPACE + 2 standalone), but only by excluding the 3 counter-example metrics from the 'ten' the intro promised. The total metrics actually discussed is 11, not 10, and 'a couple' undercounts by one. This suggests the taxonomy was fitted to a round headline number rather than derived from a principled classification.
  The 8 software engineering metrics AI broke — read next: Compare against the live leaddev.com page for possible post-publication editing (the mismatch is exactly the kind an editor introduces when trimming or adding an example late); no corpus cross-reference needed.
• illogicalThe piece argues both that free-running loops are dangerously unstructured (motivating the pivot to explicit graphs) and that short, low-stakes loops (the nightly lint-fix cron) legitimately earn full autonomy without any explicit graph structure — it never reconciles when a loop needs graph-discipline versus when it's fine to run as a pure loop; length and stakes are offered as the answer for automation-worthiness, but that criterion is never explicitly connected back to the separate loop-vs-graph argument.
  Software Factories, Light and Dark — read next: Read for a unified framework connecting loop-length/stakes-based autonomy criteria with graph/state-machine architecture choices, rather than treating them as two independent recommendations.
• incompleteThe rule of thumb that 'an agent holds up for three to ten steps, then starts losing the thread past twenty' is stated (attributed to Dex Horthy) without any grounding for why that specific numeric range holds, what model or context window it was measured against, or whether it's expected to shift as context windows and context-management techniques improve — it's treated as a durable constant rather than a fast-moving, model-dependent empirical measurement.
  Software Factories, Light and Dark — read next: Look for benchmark data on agent step-count reliability across model generations and context-management techniques, to see whether this threshold is already stale.
• illogicalThe closing note that 'Pangram scored this article as 100% human written' is offered as a credibility signal, but the piece doesn't examine (or seem to notice) that using an AI-detection tool's green/red verdict as the evidentiary bar for 'a human genuinely understood and is accountable for this text' is exactly the category error the whole essay warns against for code — a cheap, automatable check standing in for real comprehension and accountability.
  Software Factories, Light and Dark — read next: None needed — this is a self-referential observation about the piece's own closing move rather than a pointer to further reading.
• incompleteReview's knowledge-distribution function is named as real ('the team absorbed how the system fit together as a side effect of reading each other's diffs') but never re-examined. Once humans stop reading most diffs, the question of whether AI reviewers, evidence-gates or written intent can carry that team-comprehension role — or whether it simply erodes — is left open, even though it is a distinct job of review from bug-catching and intent-reconstruction.
  Agentic Code Review — read next: Empirical code-review research (Greg Wilson) on what review actually accomplishes; distributed-cognition literature (Hutchins, 'Cognition in the Wild') on knowledge spread as a side effect of shared reading.
• incompleteThe 'measure trajectory, not satisfaction' prescription rests entirely on Infobip's own internal, non-independently-audited alumni survey (N=96, self-selected respondents, retrospective self-assessed skill ratings) — the very instrument vulnerable to the Dunning-Kruger miscalibration the study itself measures. The article pairs this with a rigorous RCT (Anthropic, objective comprehension testing) but never flags that its own headline metric is far weaker methodologically than the study it borrows credibility from.
  AI coding creates two kinds of debt. You're only measuring one — read next: Cross-reference the Anthropic RCT's comprehension-test methodology (extract-cognitive-surrender#p4) against Infobip's self-report design; look for Storey's own published paper on triple-debt measurement (referenced elsewhere in this corpus as arXiv 2603.22106, per extract-osmani-intent-debt) to see whether it offers a non-self-report instrument.
• incompleteThe Infobip pre-AI vs. AI-era cohort comparison is a non-randomized, before/after natural comparison spanning 2022–2026 — a period during which the internship's content, mentor selection, hiring bar or applicant pool could plausibly have shifted for reasons unrelated to AI. The piece treats the causal attribution to AI as settled ('This confirmed that the problem wasn't the quality of the program') without directly ruling out these confounds.
  AI coding creates two kinds of debt. You're only measuring one — read next: DORA/Accelerate-style guidance on longitudinal measurement validity and confound control; look for a matched or randomized version of this comparison (e.g., interns with AI access experimentally withheld) that would isolate the AI effect from era effects.
• incompleteThe Anthropic RCT is cited only in paraphrase (52 junior developers, 17% lower comprehension, 'nearly two letter grades') without reporting the comparison arms, confidence intervals, or how comprehension was tested. This corpus already extracted a related but not identically-framed version of what appears to be the same underlying finding (generation-only vs. conceptual-inquiry posture, rather than 'used AI assistants' vs. a control) — the two paraphrases have not been reconciled against Anthropic's original publication.
  AI coding creates two kinds of debt. You're only measuring one — read next: extract-cognitive-surrender.json#p4 for the alternate framing of the same study; anthropic.com/research/AI-assistance-coding-skills for the primary source to resolve which comparison arms each paraphrase actually describes.
• 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.
• incompleteThe concrete prescriptions (mentor-as-coach, AI-free checkpoints, try-first-check-second, visibility of professional standards) are demonstrated only inside a structured, resourced internship program with a dedicated mentor per intern. The piece never asks whether or how they generalize to an ordinary team of mid-level or senior engineers with no formal mentor role, or to distributed/remote teams that lack the ambient 'who's the go-to' awareness the piece assumes exists in a colocated cohort.
  AI coding creates two kinds of debt. You're only measuring one — read next: Golden-path / platform-engineering literature on embedding good practice without a bespoke mentor relationship; pair/mob-programming literature on how tacit-knowledge transfer happens outside formal mentorship for non-junior engineers.
• incompleteThe post's remedies (planning, disposable code, PR review) are framed entirely as individual habits, but other corpus material on cognitive debt argues it is fundamentally a property of the team/system — no individual dashboard or personal practice can surface or repay the team's shared loss of a 'mental map of who knows what.' The post never addresses whether his personal repayment actually restores anything beyond his own understanding.
  Guillaume Barrois' Post — read next: Pair with team-level cognitive-debt accounts to see whether individual repayment habits like his actually transfer to team-level understanding, or only patch the individual's own gap.
• incompleteThe 'spend more time planning' practice presupposes the planning skill and domain expertise to build a solid mental model upfront — the post doesn't address whether a less senior engineer, who may lack that expertise, can use the same practice to the same effect.
  Guillaume Barrois' Post — read next: Look for evidence on whether upfront-planning-as-cognitive-debt-mitigation holds across seniority levels, not just for experienced practitioners like the author.
• incompleteThe 'answer without effort' theme is stated abstractly and never connects to the most salient contemporary source of effortless answers — AI/LLMs handing you conclusions you never worked for. Whether borrowed machine answers leave you without understanding (cognitive debt) or quietly replace your own view (cognitive surrender) is left entirely unexamined.
  Brain Food: Answers Without Effort — read next: The corpus's cognitive-debt and cognitive-surrender lines (e.g. agentic-code-review); 'Your Brain on ChatGPT'-style studies of offloaded cognition.
• incompleteThe MIT 'cognitive debt' study (Kosmyna et al.) measured essay-writing with ChatGPT, not software engineering with coding agents; the article extrapolates its learning-outcomes finding to justify the EiC-mode / Socratic-coaching proposal without evidence from the actual domain.
  Redefining the Software Engineering Profession for AI — read next: Empirical study of whether Socratic-mode coding assistants (if any exist) actually improve junior engineers' systems judgment over time, versus simply slowing them down.
• unaddressed questionNo discussion of how surrender dynamics change with model capability over time. As models improve and surface-correctness signals become even stronger, the offloading/surrender line presumably shifts — but the essay treats the distinction as static.
  Cognitive Surrender
• untested assumptionThe prescriptive heuristics (construct expectations, argue against self, etc.) are presented without evidence of their effectiveness. They may themselves be susceptible to surrender: an engineer could go through the motions of the heuristic while still surrendering.
  Cognitive Surrender
• unaddressed tensionNo treatment of the economic/game-theoretic pressure: if surrender increases short-term throughput and organizations reward throughput, then the equilibrium may favor surrender regardless of individual awareness. The essay gestures at this ('the org rewards both equivalently in the short run') but does not resolve it.
  Cognitive Surrender
• scope limitationThe mutual-amplification frame assumes the engineer has enough domain knowledge to ask good questions and evaluate answers. For truly novel domains or junior engineers, the entry point into the amplification loop is unclear.
  Cognitive Surrender
• 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.
• illogicalThe five-way 'debt' unification (financial, technical, epistemic, ecological, sleep) elides real differences between the domains. Financial debt has a mechanistic, quantifiable repayment schedule (compound interest) enforced by a counterparty; technical/cognitive/epistemic debt, per other extractions in this corpus, has no equivalent repayment mechanism and is only partially, informally repairable (e.g. via retrospectives or deliberate re-implementation, not a 'payment'); sleep debt is a biological phenomenon recoverable through actual rest, a third distinct dynamic again. Treating all five as instances of 'the same underlying pattern' does more rhetorical unification work than analytical work -- memorable, but it risks implying a false interchangeability (e.g. that principles for managing financial debt, like refinancing, transfer to epistemic debt, which they plausibly do not).
  Presentation: The Free-Lunch Guide to Idea Circularity — read next: extract-triple-debt-storey and extract-ai-coding-two-kinds-debt, which analyze cognitive/technical/intent debt specifically and explicitly note debt-type asymmetries (e.g., cognitive debt 'has no repayment mechanism' unlike technical debt) -- read against Cummins's talk to test the limits of her unification.
• uninformedCummins frames 'epistemic debt' as a fresh insight heard from Simon Wardley, but doesn't connect it to the more developed 'triple debt' framework already circulating in the same discourse, which distinguishes cognitive debt (team-level loss of shared understanding) from intent debt (undocumented rationale/goals) as separate, causally-interacting debts rather than a single undifferentiated 'epistemic debt.' That finer-grained model would sharpen her own diagnosis of why 'shipping code you don't understand' is a problem and what specifically would fix it.
  Presentation: The Free-Lunch Guide to Idea Circularity — read next: extract-triple-debt-storey and extract-ai-coding-two-kinds-debt for the more granular cognitive/intent-debt distinction.
• incompleteThe essay is written entirely from an individual-contributor, single-developer vantage point with no discussion of team or organizational context — code review by others, shared coding standards, pairing, or whether colleagues can tell from the outside whether a given PR reflects genuine understanding or the described discipline having quietly lapsed on a busy day.
  How I Use Agents Without Stopping My Own Growth — read next: extract-agentic-code-review (on how review itself has to change when agent-written code has no human intent behind it to reconstruct) and extract-ai-coding-two-kinds-debt (on cognitive debt as a team-level property invisible to individual self-report)
• self-assessment biasThe author is grading his own framework by applying it to his own work. There is no external validation, no second writer replicating the quadrant assignments independently, and no reader-side evidence that the framework-guided post is actually stronger than a counterfactual version. The self-referential structure is rhetorically clever but epistemically circular.
  Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework — read next: Independent case studies applying the framework; A/B testing of framework-guided vs. unguided AI-assisted writing.
• scopeThe demonstration covers exactly one genre (persuasive long-form essay) by one expert writer. No evidence is offered that the quadrant assignments would hold for other knowledge work types -- technical documentation, code review, strategic memos, creative writing -- where risk and differentiation profiles differ.
  Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework — read next: Apply the framework to diverse knowledge work outputs and check whether quadrant assignments remain stable.
• mechanismThe post does not explain how a practitioner should determine which quadrant a given piece of work falls into. The author's assignments feel intuitive but the decision criteria are not made explicit enough for someone else to replicate them.
  Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework — read next: The parent post 'Don't Automate Your Moat' may provide the missing decision criteria; worth checking.
• counterfactualNo comparison to what would have happened without the framework. The author asserts the framework guided his delegation decisions, but an experienced writer might have made similar choices by instinct. The framework's marginal value over general editorial judgment is not demonstrated.
  Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework — read next: Studies on structured decision-making vs. expert intuition in creative/knowledge work.
• incompleteThe adversarial-critic prompt pattern is presented as highly effective but with only anecdotal evidence from one use case. The failure modes of this approach (model sycophancy despite hostile persona, critique that is adversarial in tone but generic in substance) are not explored.
  Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework — read next: Research on LLM sycophancy and the reliability of adversarial prompting for substantive critique.
• incompletePurely individual and prescriptive, the piece never engages the tension inside 'own what you ship': owning an outcome requires understanding it, but the same workflow (agents produce 70-80%, human directs) risks comprehension debt — accountability for code one didn't write and may not fully grasp. It assumes the accountable human retains deep-enough understanding without saying how.
  Addy Osmani’s Post — read next: Comprehension/cognitive debt and mental-model ownership under AI; how to preserve genuine understanding of agent-produced systems while still delegating the doing.
• incomplete'Treat understanding as a deliverable' is the headline prescription but is given no mechanism: how understanding is produced, externalized, measured, or verified as a deliverable is unspecified, and that is the hard part.
  Five studies that are changing how I think about AI in software engineering — read next: Read extract-osmani-intent-debt for concrete substrate (AGENTS.md as intent ledger, ADRs, learnings files) and brain-food-answers-without-effort#p11 for the objection that understanding is a non-transferable byproduct of effort, not a portable object that can be delivered.
• incompleteThe comprehension-loss worry is raised and then softened by the SRE anecdote, but the piece never distinguishes genuine understanding from borrowed or illusory understanding: the SRE 'understands what the code is doing' via the LLM, yet whether that is real comprehension or offloaded confidence is not examined.
  Fragments: February 4 — read next: Read on cognitive/comprehension debt and the illusion of explanatory depth — when LLM-mediated navigation deepens versus substitutes for real understanding.
• uninformedDiscussing AI-driven loss of understanding, the fragment does not engage the existing vocabulary of comprehension/cognitive debt or cognitive surrender that names precisely this failure mode and its accrual over time.
  Fragments: February 4 — read next: Bring the comprehension-debt and cognitive-surrender literature to bear on the pair-programming and LLM-navigation fragments.
• incompleteThe post names 'cognitive debt' as a risk but offers no way to detect or measure it, and no evidence about its actual consequences — leaving the central worry asserted rather than examined.
  Fragments: February 9 — read next: Look for empirical work on skill and comprehension erosion under AI-assisted development (e.g., the MIT 'cognitive debt' study) and metrics for team understanding.
• incompleteThe proposed understanding-consolidation step 'analogous to TDD's refactor' is gestured at but never specified — no defined practice, cadence, artifact, or acceptance criteria beyond the fairy-tale-explanation tactic.
  Fragments: February 9 — read next: Read on comprehension practices for AI-written code: decision records/ADRs, code walkthroughs, and structured explanation or knowledge-consolidation rituals.
• incompleteThe entire pattern presupposes an organization already has OpenTelemetry instrumentation, defined SLOs, and a Grafana-compatible observability stack to query — this is unglamorous infrastructure work that many teams have not done. The article treats 'point the agent at your telemetry' as a drop-in capability rather than naming the maturity precondition, so teams without that substrate get no guidance on how to get from zero to telemetry-grounded agent development.
  Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development — read next: Observability-maturity and adoption-sequencing literature; the corpus's own material on trace validation as future/hard infrastructure work.
• incompleteGreene's evidence throughout is drawn almost entirely from his own two startups (InsightSquared, Outcomes4Me) plus one recent personal side project (the Android RAG proof-of-concept); no comparative case is offered of a startup or team that ignored these mindsets and what happened as a result, nor of a larger, less resource-constrained organization successfully applying the same lessons. It is left open whether 'the lessons startups have always taught us' generalize past small, high-autonomy, high-trust teams.
  Presentation: The Future of Engineering: Mindsets That Matter When Code Isn't Enough — read next: Seek accounts of these same mindsets (start simple, protect comprehension, attack hard bits first) applied — or failing to apply — inside larger, less autonomous engineering organizations.
• uninformedThe thinkslop harm is asserted at population scale from vivid single-user anecdotes. The study measures the prevalence of use cases where thinking COULD be outsourced (a quarter of top uses) but not the cognitive damage actually incurred, and — crucially — it presents the sharpening 'sparring-partner' use from the same data without ever quantifying the crutch-vs-foil ratio, so the headline concern rests on an unmeasured mix.
  How People Are Really Using AI in 2026 — read next: Read the cited 'cognitive debt' study (arXiv 2506.08872, 'Your Brain on ChatGPT') and extract-cognitive-surrender (offloading vs. surrender, posture-dependence, the 73% wrong-answer acceptance finding) for the mechanism and the controlled evidence the HBR piece substitutes anecdote for.
• incompleteThe mining study measures public open-source adoption only. The paper itself notes that 'high-volume internal deployments... leave no public trace,' but the headline anecdotes it discusses (Stripe's Minions, 1,300 PRs/week) are exactly such internal deployments. The 0.59% figure is therefore a floor on publicly-visible evidence, not a measure of practice overall, and the paper cannot adjudicate whether loop engineering is genuinely rare or merely rare in public repositories.
  Loop Engineering: Building Blocks, Adoption, and Impact — read next: An internal-tooling survey or structured practitioner-interview study of enterprise/internal loop adoption (the kind this corpus's Stripe and 'software factory' pieces gesture toward) to estimate private adoption rates that public GitHub mining cannot reach.
• incompleteOsmani notes that 'code often preserves a decision that was made, but not why the decision was made' and suggests agents should store trajectory/lessons information, but this stays a casual aside -- no format, storage location, retrieval mechanism, or team-sharing design is specified, even though it's exactly what would resolve the comprehension-debt problem his own 'feature I had to relearn' story illustrates as a serious, recurring cost.
  Human judgment doesn't leave the software factory. It relocates. — read next: A concrete design for a durable, queryable record of agent decision rationale that survives context compaction and is shared across a team, rather than left to one operator's memory or an ad hoc local note.
• 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 piece does not distinguish between agent types or task types when sizing the fleet. 'Background agents in the Cloud' versus 'foreground agents you steer interactively' have very different review-cost profiles; isolated refactors versus exploratory feature work have very different judgement-content. A more developed version would offer a cost function for fleet sizing rather than 'a low single digit'. The lock-thrashing claim for complex tasks is asserted but not modeled — at what point does adding one more in-flight complex task degrade ALL outputs, and how do you tell you're past it?
  The Orchestration Tax is You — read next: Queuing-theory treatments of knowledge work (e.g., Reinertsen 'The Principles of Product Development Flow'); empirical studies of attention residue (Sophie Leroy).
• incompleteOsmani assumes the developer can accurately measure their own sustainable review rate and choose to stop at it. Stolen-Focus / Bailey-style attention research suggests this self-measurement is precisely what gets degraded first when attention is depleted. The prescription 'scale fleet to your review rate' presupposes a calibrated self-monitor that the diagnosis itself implies has been compromised. The post does not address this circularity.
  The Orchestration Tax is You — read next: Chris Bailey on attention as a managed resource; Johann Hari 'Stolen Focus'; cognitive-load research on metacognitive accuracy under load.
• incompleteOsmani gestures at 'cognitive debt' via Storey but does not develop the stock-and-flow model implied by his own diagnosis. If mental model is a stock that depletes with unreviewed merges and replenishes with deep code reading, the orchestration tax is a flow-rate problem with a leverage point in the replenishment rate, not just in the merge rate. He prescribes throttling merges (backpressure) but does not prescribe deliberately re-reading old code to rebuild stale model — a complementary tactic.
  The Orchestration Tax is You — read next: Donella Meadows on stocks-and-flows and leverage points; Naur 'Programming as Theory Building' on the theory developers carry of their code; recent empirical work on mental-model decay in long-lived codebases.
• incompleteThe asymmetric-risk frame from Paul Reed's 'Ironies of A^2 I^2' (catastrophic downside when AI is misleading, modest upside when AI is correct, and operators cannot detect in real time which regime they are in) is precisely the empirical mechanism that would make 'shallow reviews' so dangerous. Osmani names shallow reviews as the failure mode but does not connect it to the Woods et al. nurses-study finding that explains WHY shallow review of AI output is uniquely catastrophic compared with shallow review of human output. The two posts are talking about the same dynamic from different angles and would strengthen each other.
  The Orchestration Tax is You — read next: Paul Reed 'The Ironies of A^2 I^2' (already extracted in this repo); Woods et al. July 2025 nurses study; the METR developer study.
• illogicalThe GIL analogy is rhetorically powerful but slightly misleading. A GIL serializes execution but does NOT serialize knowledge of state — Python threads share memory cheaply once the lock is held. The developer's situation is worse: not only is execution serial, but knowledge-of-state must be reconstructed (the 'cold reload') every time the lock is acquired. Osmani notes the cold-reload cost separately but does not see that this means the GIL analogy understates the asymmetry. A better analogy would be 'GIL plus no shared memory plus expensive page fault on every acquire' — i.e., closer to distributed-systems coordination than to threaded execution.
  The Orchestration Tax is You — read next: Distributed-systems literature on shared-nothing coordination; Hutchins on distributed cognition; the multi-agent-systems literature on shared mental models.
• incompleteCausal direction is never established. Heavy AI users have lower psychological debt — but this could mean (a) using AI more reduces debt, (b) lower-debt employees use AI more, (c) both share an unobserved cause (e.g., role design, manager support). The training-program recommendation only makes sense under (a), which the data does not establish.
  The Psychological Costs of Adopting AI — read next: Longitudinal or quasi-experimental studies of AI adoption (e.g., the Brynjolfsson/Li/Raymond customer-service study); methodology critiques of HR-survey-based causal claims
• incompleteThe exemplar companies are all success stories with no failure cases. Klarna in particular publicly reversed parts of its AI-first strategy in 2024-2025 after customer service quality concerns; the article treats the 90% adoption number uncritically as proof of working culture rather than as a snapshot that didn't hold. Selection bias on the prescription side is severe.
  The Psychological Costs of Adopting AI — read next: Follow-up coverage of Klarna's AI strategy reversal; broader research on the gap between announced and sustained AI adoption rates
• uninformedThe six debts are presented as independent dimensions but are conceptually entangled. Competency debt is partly a felt consequence of cognitive debt; identity debt overlaps with autonomy debt when the threatened identity is built on autonomous expert judgment. The taxonomy may be a useful management heuristic but is not analytically clean, and the survey's 0–100 conversion may double-count.
  The Psychological Costs of Adopting AI — read next: The original Self-Determination Theory literature (Ryan & Deci) on how the basic needs interact rather than sum; latent-variable analyses of motivation constructs
• uninformedNo engagement with the asymmetry the survey itself surfaces: people excuse their own AI use but judge others'. This is a textbook 'fundamental attribution error' / actor-observer asymmetry, and the credibility-debt prescription (make use visible) assumes a social-norms mechanism that the underlying psychology may resist. The author does not engage with whether visibility actually shifts the attribution or just relocates it.
  The Psychological Costs of Adopting AI — read next: Classic social psychology on actor-observer asymmetry (Jones & Nisbett); norm-shifting interventions in moral psychology
• incompleteConflict of interest is disclosed but its implications are unexamined. The survey was commissioned for Meltwater Consulting (where the author is a director) and underwrites a consulting offer. The framing — that companies need expertly-designed adoption strategies — directly supports the consulting product. The article treats the data as objective evidence rather than as evidence shaped by a commercial frame.
  The Psychological Costs of Adopting AI — read next: Methodology of practitioner-commissioned research; meta-analyses comparing commissioned to independent organizational research
• incompleteThe 'human infrastructure' closing claim is large but underspecified. Each prescription is a single-company anecdote; there is no theory of which mitigation pattern applies to which combination of debts, no sequencing guidance, and no analysis of how the patterns interact (e.g., does cognitive friction reduce or increase autonomy debt?). The article ends as a framework prospectus rather than as a developed framework.
  The Psychological Costs of Adopting AI — read next: Work on socio-technical systems design (Trist, Pasmore); change-management research on layered intervention design
• incompleteNone of the reshared sub-posts cite a verifiable, linked source for their headline empirical claims (an MIT brain-connectivity study, a '2026 Harvard study' on creativity and metacognition) — each is summarized in a sentence or two with no link, sample size, or methodology, inside a feed whose own participants (Davies, Eckersley) are explicitly warning against exactly this kind of unverified, consensus-reinforcing repetition ('intellectual parroting disguised as thought leadership', per Wang's own post in the same capture).
  Doug Shannon's Post — read next: The actual MIT Media Lab study on LLM use and EEG connectivity ('Your Brain on ChatGPT') for what it actually measured and its stated limitations, and whatever the cited 2026 Harvard creativity study turns out to be once properly named and linked.
• uninformedThe essay states there is 'widespread agreement' that AI-heavy code is harder for humans to understand but 'disagreement about how much that matters' and 'not a lot of actual evidence' either way — an open, acknowledged evidentiary gap that the essay doesn't attempt to resolve or even point toward evidence-gathering for, despite the series' stated commitment to rigor over anecdote.
  Measuring AI's Unintended Consequences — read next: Look for empirical studies connecting human comprehension of AI-generated code to actual defect or incident rates, e.g. work on cognitive/comprehension debt.
• illogicalThe China-dominance argument compresses 'supply chain understanding' into a near-sufficient condition for long-run dominance. Other variables (capital allocation efficiency, demographics, talent migration, capability of domestic models, export-control regimes, energy supply, civil-military fusion costs) are not weighed.
  Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect — read next: Read against Dan Wang on Chinese tech policy, CSIS/RAND supply-chain analyses, and any sceptical takes on PRC industrial policy execution (e.g. semiconductor self-sufficiency progress vs targets).
• incompleteThe Jevons-paradox reframing (adjacent possibles becoming real) is asserted but the conditions under which adjacent possibles actually become real industries — vs stalling — are not specified. Sometimes the adjacent possible is real and stays small.
  Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect — read next: Read against the slower-than-expected industrialisation histories — early electricity (the 40-year productivity paradox), enterprise software in the 1990s. Beck and Shoup on Jevons-in-coding is a sharper instantiation of this same claim worth juxtaposing.
• uninformed (mild)The post under-weights regulatory ratchets — particularly EU AI Act, sector-specific liability regimes, GDPR-style data sovereignty rules — as climatic variables that shape what 'industrialised ML' actually looks like in different jurisdictions. Wardley's mapping treats regulation as doctrine; this post treats it as background.
  Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect — read next: Read alongside EU AI Act implementing acts, NSM/Datatilsynet guidance for the Norwegian context, and Frederiksen on Coop Bank sovereignty for how an enterprise actually reasons about regulatory ratchets as architectural constraint.
• incompleteThe post is silent on the cultural and organisational variation in how 'practice converges' over the 5-8 year window. Nordic public-sector institutions, Japanese manufacturers, and Silicon Valley startups will not converge to the same practice — but the post talks as if there is one convergence trajectory.
  Simon Wardley's Post — Industrialisation of ML: nine notes on what to expect — read next: Read against Cutler on organisational operating systems and the Heis stable's Norwegian-leader interviews — concrete evidence that practice-convergence is mediated by national culture and institutional shape, not just by elapsed years.
• uninformedNo engagement with what happens to accountability when a stakeholder acts on an AI-translated version of reality that later turns out to have mis-flattened something important -- who is responsible for catching that, and does the translation layer diffuse responsibility in a way that hand-built flattening (where a named person chose what to cut) did not.
  TBM 437: AI and the Recontextualization Tax — read next: Read alongside Cutler's own cognitive-surrender / cognitive-debt material elsewhere in the corpus on AI-mediated understanding gaps, to see whether he has a general position on accountability for AI-intermediated organizational communication.
• incompleteThe document identifies the productivity/experience paradox but offers no framework for resolving it beyond the 'agent experience' reframe. How should organizations actually measure and invest in developer satisfaction when it is decoupled from output?
  The Future Of Software Engineering — read next: DORA team's ongoing research on developer experience metrics; Nicole Forsgren's work on SPACE framework
• incompleteThe batch-size regression is flagged as an 'active regression needing industry attention' but no countermeasures are proposed beyond general governance reform.
  The Future Of Software Engineering — read next: DORA State of DevOps reports; continuous delivery literature on changeset sizing with AI tools
• incomplete'Codebase cognitive debt' is diagnosed with real specificity (the reinforcing loop between change velocity and shrinking shared understanding) and three named countermeasures (feedback sensors, tracking team cognitive load, architectural fitness functions) are listed, but none is elaborated into a concrete method — there is no worked example of how a team would actually measure or 'pay down' cognitive debt in practice.
  Technology Radar, Volume 34 — read next: See extract-fowler-fragments-february-13#g2 and extract-ai-coding-two-kinds-debt, which raise the same measurement gap from a different angle; a concrete practitioner writeup of 'tracking team cognitive load' in production would close both.
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Technology Radar, Volume 34 — read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.
• 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 documents that developers retain some Manual Fix work and periodically redo tasks themselves specifically 'to keep the map in my head,' but doesn't examine whether this countermeasure actually holds up over longer timeframes than the ~40 minutes observed in the lab study -- i.e. whether comprehension of agent-produced systems measurably degrades for developers who increasingly shift to Wait and heavy delegation across many parallel tasks over weeks or months.
  The Work Behind Delegation: A Framework for Supervising AI Coding Agents — read next: A longitudinal study (as the authors themselves call for in §9) tracking a developer's ability to explain or modify agent-produced code weeks or months after heavy multi-session delegation, to test whether comprehension debt accumulates despite the Manual Fix countermeasure this paper documents.