Mental Models & Understanding

Genuine human comprehension of how systems behave and why — the capability AI can erode through recognition-without-understanding, and cannot substitute for in a crisis.

Also known as: mental model, mental models, mental model ownership, widen system understanding / mental model, illusion of explanatory depth (forståelsesdybde-illusjon), illusion of explanatory depth, gjenkjenne vs forstå, insight vs summarization, systems thinking

How authors use it

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

Documents (29)

• 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.
• TBM 440: The Problem With Putting People in Boxes John Cutler · 2026-09-19 Reader 🖥️
  Putting people in boxes — typing them by personality, strengths, or 'culture fit' — is a category error at work because behavior is not a stable, context-free trait but a function of the person interacting with situational incentives, norms, power dynamics, and constraints, so the operative question should be 'under what conditions do you/they behave differently' rather than 'what type are you.'
• Collective problem solving in music, art, science, and software Jessitron · 2026-09-12 Reader 🖥️
  Great teams and great individuals are produced (not assembled from pre-existing talent) by group processes — camerata-like communities across music, art, science, and software — because such groups form a 'symmathesy': a living system of mutually learning people, tools, and (in software's unique case) the running software itself, and therefore growing individual and collective capability requires cultivating and sharing mental models within that system rather than optimizing individual output or hoarding recognition.
• TBM 439: Day At The Gig... John Cutler from The Beautiful Mess · 2026-09-11 Reader 🖥️
  AI can accelerate the mechanical formalization of sensemaking artifacts a person has already understood, but it cannot solve the harder problem underneath — telling which of an organization's proliferating artifacts still reflect current reality — so genuine organizational context remains something you have to actively create through your own exploration and other people's tacit knowledge, not something AI can spoon-feed you.
• Experience Mapping Matters More the Faster You Move Jim Kalbach · 2026-09-08 Reader 🖥️
  Because AI now lets every team execute fast and independently, the real risk facing organizations is uncoordinated speed, not slow speed — so experience maps matter more, not less, because they are one of the few tools that reliably turn scattered, siloed knowledge into a shared, in-the-room conversation that AI cannot produce on its own.
• 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.
• Why Great Leaders Need More Than Good Judgment Harvard Business Review · 2026-07-21 source ↗ Reader 🖥️
  Because the pace of change now outstrips any individual leader's judgment and experience, leaders should replace reliance on personal judgment alone with an institutionalized discipline of systematically gathering and integrating stakeholder perspectives ('panoramic leadership') before moving to action.
• Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone Lenny Rachitsky (host); Elizabeth Stone (guest, Chief Product and Technology Officer, Netflix) · 2026-07-19 Reader 🖥️
  As generative AI lets anyone prototype, analyze, and ship — collapsing the old boundaries between product, design, engineering, and data science — organizations should respond not by dissolving functional expertise but by doubling down on scarce craft excellence and systems thinking, investing in shared infrastructure/guardrails so individual fluidity compounds rather than fragments, and leaning harder into a talent-dense, high-agency, low-process culture ('excellence as an operating system') that Netflix built before AI made it fashionable.
• OpenAI Fixes 18-Year-Old GNU libunwind Bug by Treating Crash Debugging Like Epidemiology Steef-Jan Wiggers · 2026-07-11 Reader 🖥️
  When production crashes resist every hypothesis, the fastest way to see their structure is not deeper analysis of individual cases but building a complete, labeled dataset across the whole population of failures — a population-level, epidemiological approach that revealed OpenAI had conflated two unrelated bugs (silent CPU corruption on one Azure host and an 18-year-old race condition in GNU libunwind's setcontext) into a single unsolvable mystery.
• What 60 Years of Data Reveals About How Men and Women Experience Leadership Harvard Business Review · 2026-07-10 source ↗ Reader 🖥️
  Over 60 years overt bias against women leaders has receded but reorganized into harder-to-see structural forms (informal sponsorship, subjectively interpreted merit, unequal access to P&L roles), and men and women now sharply diverge on whether the system is fair — progress on the surface, deterioration underneath.
• Det skal være vanskelig Erik Børve Rasmussen · 2026-07-10 source ↗ Reader 🖥️
  Difficulty is the mechanism of learning, not a defect in it, so AI — a machine for removing difficulty — destroys learning wherever the process rather than the product was the whole point (school, unlike work); the remedy is therefore to redesign AI and assessment as skill-forcing 'simulators' rather than to ban them.
• Podcast: Formal Methods for Every Engineer in an AI-Powered Future Gabriela Moreira (guest); host Shane Hastie (InfoQ) · 2026-07-10 Reader 🖥️
  Formal methods are a practical tool for reasoning about the edge cases of complex distributed and concurrent systems, and because AI in 2026 collapses the historic barriers to writing specifications and the glue code that binds them to real implementations, the profession's enduring human work shifts to defining which system behaviours are correct — the judgment AI cannot take over.
• 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.
• TBM 426: The Trouble With Mirrors John Cutler from The Beautiful Mess · 2026-06-16 source ↗ Reader 🖥️
  Visualizing how an organization works and 'embracing transparency' cannot by themselves improve it, because organizational truth is never a single neutral reflection but is positional, framed, and continuously negotiated among parties who each have something at stake in what gets seen — so the real need is not to be shown the mirror but to be mirrored: to have one's perspective recognized and held with care.
• Brain Food: Answers Without Effort Shane Parrish (FS) · 2026-06-14 source ↗ Reader 🖥️
  Understanding — and the confidence, success and clutch performance that stand alongside it — cannot be borrowed or shortcut; all are earned only through whole-hearted, sustained effort, so an answer you obtain without effort is hollow because it never becomes understanding you actually own.
• 4) Morten Eikeland: Det finnes alltid et hierarki Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-06-01 source ↗ Reader 🖥️
  Hierarchy is not optional in any group of more than a few people — it arises structurally from division-of-labour pressure plus external groups' need for a single point of contact — and the agile/teknologi/flat-struktur ideology that pretends otherwise does not eliminate hierarchy, it only makes the actual operating hierarchy invisible, unspoken, and harder to challenge; therefore the work of leading well is not to flatten but to operate at the correct abstraction level for the role one is in, to recognise the role-vs-person distinction, and (for a developer becoming a leader) to walk a real sorgprosess of identity loss before gaining a different kind of relevance.
• Build an AI Advisory Board with GPTs for Decision-Making Carolyn Healey · 2026-05-25 source ↗ Reader 🖥️
  Running major decisions through a self-built panel of 3–5 custom GPTs modeled on the frameworks of admired leaders is a cheap, always-available substitute for an advisory board that forces decision-makers out of single-mental-model thinking by surfacing questions they would not have asked themselves.
• Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) J. Paul Reed · 2026-05-22 Reader 🖥️
  The ironies Bainbridge identified in 1983 — that automation makes the human operator more, not less, crucial while simultaneously eroding the skills needed to intervene — persist and intensify under AI, so engineering organizations must treat AI as an efficiency lever that demands deliberate cultivation of human thoroughness, mental models, and coordination practices rather than as a substitute for them.
• Designing Data-Intensive Applications: The Cloud & Doing the Right Thing The Pragmatic Engineer · 2026-05-05 Reader 🖥️
  Cloud computing changes the technical and economic architecture of data systems in ways that demand new operational thinking, while the growing power of data-intensive applications creates ethical obligations for engineers to consider the societal consequences of what they build.
• 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.
• Introduction johnpcutler.github.io · 2026-04-10 source ↗ Reader 🖥️
  Organizations suffer because the words, categories, and representations they use to describe product development work systematically flatten, filter, and distort reality as information moves across levels -- and the solution requires treating operational language as information architecture and ontology design rather than simple labeling.
• 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 third golden age of software engineering – thanks to AI, with Grady Booch The Pragmatic Engineer (Gergely Orosz, host; Grady Booch, guest) · 2026-02-04 Reader 🖥️
  Software engineering is entering a historically recurring pattern — a rise in the dominant level of abstraction — rather than being automated out of existence, because 'software engineering' has always meant balancing human, economic, legal, and ethical forces (not just writing code), and today's AI tools only automate the coding layer, which is itself bounded by the already-seen patterns they were trained on.
• Who is LLM? Martin Fowler · 2025-07-22 Reader 🖥️
  Developers cope with the unpredictable, powerful-but-untrustworthy behavior of LLM coding assistants by adopting anthropomorphic personas (stubborn donkey, genie, slot machine, Uriah Heep) that compress real, observed behavioral traits — over-eagerness, complexity-blindness, variable-reward unpredictability, and subtle manipulation of the user's trust — into memorable, shareable working heuristics, not literal claims about what an LLM actually is.
• Eight years of wanting, three months of building with AI Lalit Maganti · 2025-03-01 source ↗ Reader 🖥️
  AI coding agents are a genuine force multiplier for implementation and last-mile polish, and can unlock projects that would otherwise die from the intersection of difficulty and tedium, but they are a dangerous substitute for design, architecture, and taste -- the developer must retain ownership of the soul of the software or risk building a codebase they cannot reason about.
• 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.
• Sociotechnical Architecture as Enabler of Product Thinking Eduardo da Silva · 2021-04-30 source ↗ Reader 🖥️
  An organization can only achieve Product Thinking's goal — maximizing continuous, high-velocity value exchange with the customer — by holistically co-designing three interrelated systems together (the customer/market, the teams/organization, and the software architecture), a discipline the author names Sociotechnical Architecture, building on Conway's Law, Team Topologies, and Ackoff's Systems Thinking.
• Software Design X-Rays Adam Tornhill · 2018-03 source ↗ Reader 🖥️
  The real cost and risk in a large codebase is invisible in the code's current structure and can only be recovered by mining version-control history as a behavioral record of how people actually work on it — and once recovered (as hotspots, change coupling, code age, developer fragmentation, and knowledge maps), that record should drive both technical refactoring priorities and the alignment of team structure with system structure (Conway's Law), because most expensive software problems are organizational problems wearing a technical disguise.

Propositions touching this concept (43)

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

2023-07

• explicitEffective prompting for code generation means decomposing a task into manageable chunks and asking for one function or step at a time, because asking the model to do too much at once produces worse results; the ideal mental model for the assistant is 'a smart intern who knows a lot about a subject but isn't that experienced.'
  How Coders Can Survive—and Thrive—in a ChatGPT World · p6

2025-01

• explicitestablishedThe same AI tool can either hollow out or sharpen an engineer's mental model; the outcome depends entirely on the user's posture — thinking *with* vs. *instead of* thinking.
  Cognitive Surrender · p7

2025-03

• explicitDevelopers and managers hold systematically different mental models of productivity: in a Microsoft/University of Victoria study (~2022), developers described productivity roughly 50% in activity-metric terms (commits, lines of code), while managers overwhelmingly used process/performance terms, and almost nobody — developer or manager — mentioned satisfaction.
  DORA Community Discussion - DX Core 4 · p9
• implicitDevelopers who lose their mental model of an AI-generated codebase become the kind of disconnected manager that engineers have always complained about.
  Eight years of wanting, three months of building with AI · p10

2025-11

• explicitcorroboratedRealizing the benefits of agentic AI requires reskilling developers away from traditional coding skills toward problem decomposition, systems thinking, communication, collaboration, and continuous learning.
  Agentic AI in the Software Development Lifecycle (SDLC) · p3

2026-04

• explicitDeep modules (Ousterhout) make codebases easy for agents to navigate AND let humans retain a mental model of the codebase while delegating implementation behind module interfaces.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p10
• explicitWorking with AI in 2026 means working harder than before, AND losing your mental model of the codebase faster than before; the architectural prescription (deep modules with interfaces you design yourself) is the proposed defence.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p22
• implicitThe factory/manufacturing mental model is the default frame most organizations bring to product development operations, and it is the wrong frame.
  Introduction · p8
• explicitThe ideas in Dorsey's post are not new — learning organizations, cybernetics, systems thinking, and platform thinking all predate it
  TBM 414: Legibility and Legitimacy · p4
• explicitThe dominant mental model of product development treats engineering as the bottleneck, and the entire system organizes around feeding that constraint efficiently — this model is the root cause of most organizational dysfunction
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p3
• explicitIf you keep the engineering-as-bottleneck mental model, AI will accelerate all existing dysfunctions: more ideas generated, more artifacts produced, more negotiation, more overload — all faster
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p4
• explicitThe alternative mental model ends the funnel at meaningful change for customers, not at feeding a team — and in this model, AI accelerates learning rather than feeding a bottleneck
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p5
• explicitUsing AI to reinforce broken mental models of product development (PRDs that wither on contact with reality, box-checking business cases, cascading work nobody believes in) supercharges what was already broken — 'more artifacts, same blind spots.'
  TBM 418: Campfires, Trails, and Quests · p1
• explicitestablishedSystems thinking, metacognition, and contextual judgment are being discounted precisely when they are most needed.
  TBM 420: The AI Playbook Puzzle · p5
• implicitOrganizations cannot effectively apply AI without first building a working mental model of what AI actually does.
  TBM 420: The AI Playbook Puzzle · p10

2026-05

• empiricalThe public mental model that 'automated content is generic and therefore spottable' is obsolete — AI agents produce surgically personalized content at negligible marginal cost.
  How AI Swarms Are Disrupting Democracy · p3
• explicitMost CXOs make major decisions inside a single mental model — their own.
  Build an AI Advisory Board with GPTs for Decision-Making · p1
• explicitAI's current main effect on engineering operations is more incidents, not fewer — because AI accelerates code generation faster than humans can sustain mental models of what was generated.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) · p17
• explicitWaiting is not merely a UX friction; it is a flow-destroying event that breaks the developer's mental models and therefore degrades the quality of thought, not just throughput.
  KI, utvikling og følelser · p3
• 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
• implicitMental model freshness is itself a stock that depletes silently when you merge unread code; the depletion is invisible until production breaks.
  The Orchestration Tax is You · p23
• explicitProduct, design, and technology hold different and partly incompatible mental models of team structure even in nominally cross-functional orgs.
  TBM 423: Why Defining Teams Is So Hard · p2

2026-06

• explicitReviewing an agent's documentation edits first is an effective way to build an initial mental model of what changed in a large agent-produced change.
  Have your agent record video demos of its work with shot-scraper video · p10
• explicitGeneralisering at the top is necessary but produces overdreven selvsetthet — an illusion of explanatory depth that is unmasked when one asks for mekanismer instead of meninger.
  4) Morten Eikeland: Det finnes alltid et hierarki · p15
• explicitMigrations (large, complex, shared-system changes) that used to require a team can now be roughly 95% owned by a single driving individual or small team and completed in roughly 10% of the previous time — which raises, not lowers, the stakes of individual judgment, because even small sharp edges in a fast migration will break colleagues' mental models of the shared system.
  Revised rules of engineering leadership. · p1

2026-07

• explicitThe industry has no settled mental model for agents (tool/API vs. team member/human vs. non-deterministic 'chemical vat'), and this ambiguity is slowing coherent governance and investment decisions.
  Finding Comfort in the Uncertainty · p9
• 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
• explicitTasks that require reconstructing the same mental model of a codebase should be assigned to the same agent/context ('cognitive locality'); splitting them by task rather than by the knowledge each task requires forces multiple agents to independently rebuild the same understanding from scratch.
  The Orchestrator's Tax · p7
• explicitThe reason paved paths and systems thinking matter more now is chiefly velocity and risk: more bets, more people (and agents) doing more kinds of work, and access/identity/security risk that can no longer be re-derived per-person or held as tribal knowledge across a large organization.
  Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone · p7
• explicitA practical, teachable technique for systems thinking is a single deliberate 'zoom out' per problem — asking what you're assuming about the broader space — bounded so it doesn't stall forward progress.
  Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone · p10
• explicitAI will not convert a defensive intent into a reflective one on its own; a manager gets self-interrogation and a challenged mental model only if they explicitly ask for it.
  TBM 428: Yes, Robot. Yes, Boss? · p6
• explicitMachine Understanding requires a viable mental model of AI's inputs, outputs, and failure modes -- not expert-level math -- sufficient to get past treating AI as 'magic.'
  TBM 431: The Denominator That Matters · p3
• 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

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

• explicitEach developer's mental model of a shared software system is necessarily incomplete, out of date, and different from every other developer's model ("Woods' Law"), and reconciling these models to communicate imposes a real cost (a 'coherence penalty').
  Collective problem solving in music, art, science, and software · p5
• explicitIt is cognitively easier to build a new system from scratch (constructing your mental model as you build) than to form an accurate mental model of an already-built system of comparable complexity, even though building from scratch may not be faster.
  Collective problem solving in music, art, science, and software · p6
• explicitA single developer who holds most of a system's mental model (and keeps changing the system) can be a bottleneck that makes assigned helpers unable to contribute, regardless of the helpers' individual talent; the fix is working together on the system and deliberately investing attention in transferring the model, not assigning more people.
  Collective problem solving in music, art, science, and software · p8
• explicitcorroboratedEvaluating and rewarding people as individuals creates an incentive to hoard useful mental models/ideas rather than share them, even though shared ideas are what make the whole team more capable.
  Collective problem solving in music, art, science, and software · p10
• explicitAI agents discover and invoke API capabilities at runtime rather than building durable semantic mental models the way human developers do.
  Why Developer Portals Must Evolve in the AI Agent Age · p2
• explicitTechnically fluent users get more value from AI-driven knowledge automation than non-technical users, because understanding how to compose tools/scripts/APIs lets them treat most knowledge work as reducible to code, a mental model non-technical users don't reach for by default.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p31
• implicitThe 'design the graph around your business ontology' guidance implicitly assumes an organization has, or can converge on, a single shared mental model of its domain — when in practice different functions (sales, finance, product) often model the same entities (a 'deal,' a 'customer,' an 'account') differently.
  Enterprise Analytics Beyond Dashboards: Intelligent Data Orchestration with LLMs · p21

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
• 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

Tensions

Open gaps (77)

• incompleteThe headline findings rest on executives' self-reported perceptions, yet the piece reads the widening women/men gap as evidence of worsening structural reality and privileges women's read — without triangulating perception against objective within-sample advancement outcomes, or ruling out that rising awareness (rather than rising bias) drives the divergence.
  What 60 Years of Data Reveals About How Men and Women Experience Leadership — read next: Methods contrasting perception with behavioral/objective measures — audit studies, administrative promotion-record analysis, and work distinguishing bias-in-fact from bias-awareness.
• incompleteThe sample is 193 U.S. senior executives across unspecified industries plus a few qualitative interviews. Generalizability to other geographies (e.g., Nordic/European labor markets with different parental-leave and board-quota regimes), to organizational levels below the C-suite, and to non-corporate sectors is unaddressed.
  What 60 Years of Data Reveals About How Men and Women Experience Leadership — read next: Cross-national comparative and multi-level studies of leadership advancement, and the interaction of national policy (quotas, leave) with the underground-bias mechanism.
• 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.
• incompleteNo epistemic test for whether a custom GPT is applying a thinker's framework versus producing fluent imitations of that thinker's voice. The 'intellectual DNA' claim is the load-bearing assumption of the entire practice — if it fails, the panel becomes a stylized confidence generator. The article offers no method (held-out test cases with known answers, decisions-vs-outcomes tracking, blind comparison against a generic 'critique my decision' prompt) for detecting this failure.
  Build an AI Advisory Board with GPTs for Decision-Making — read next: Annie Duke, 'Thinking in Bets' and 'Quit' — for the distinction between decision quality and outcome quality, and the discipline of pre-committing to what evidence would change your view. Philip Tetlock, 'Superforecasting' — for what actually-calibrated judgment looks like and how to measure it. Daniel Kahneman, 'Noise' — on the gap between confident expert judgment and reliable judgment.
• incompleteNo engagement with the possibility that the practice does subtle epistemic harm: it lets the decision-maker experience the feeling of having consulted wisdom without the actual feedback loop (real advisors push back, get hurt, hold you accountable, and update their advice based on what happened last time). The closer the simulation gets to feeling real, the more it may displace practices that actually improve decisions.
  Build an AI Advisory Board with GPTs for Decision-Making — read next: Cutler on accountability and DRIs (directly responsible individuals); literature on simulated advice in clinical and organizational decisions (Logg et al. on algorithm aversion/appreciation); the AI-coding-quality conversation in the user's library (Marcus, the SQLite-vs-LLM-rewrite finding) for the more general pattern of fluent output being mistaken for capable output.
• incompleteSelection bias in the advisor pool is unacknowledged. The named exemplars are almost all American, male, billionaire CEOs/investors from a specific era — selected by biographical-survivor bias (we have books about Buffett because he succeeded). Their published frameworks are necessarily post-hoc rationalizations of decisions that worked. A panel of survivors cannot teach you about the decisions that, made the same way, did not work.
  Build an AI Advisory Board with GPTs for Decision-Making — read next: Survivorship-bias literature; Tetlock on the difference between pundit confidence and forecasting accuracy; Annie Duke on resulting (judging decision quality by outcomes).
• illogicalSelf-undermining selection criterion: 'pick thinkers whose blind spots differ from yours.' If a decision-maker could identify their own blind spots well enough to do this selection, the blind spots would no longer be blind. The directive presupposes the very self-knowledge whose absence the panel is supposed to compensate for.
  Build an AI Advisory Board with GPTs for Decision-Making — read next: Kahneman, 'Thinking, Fast and Slow' on the bias blind spot; Pronin et al. on asymmetric insight; literature on structured techniques (e.g. premortem, red teaming) that don't require accurate self-diagnosis to function.
• uninformedNo engagement with established decision-quality literature that already addresses many of the same goals (Duke, Tetlock, Klein's recognition-primed decision-making, Kahneman on noise, the premortem technique). The piece writes as if the choice is between 'one mental model' and 'GPT panel,' ignoring a substantial existing toolkit that does not depend on the framework-capture assumption.
  Build an AI Advisory Board with GPTs for Decision-Making — read next: Duke, 'Thinking in Bets'; Klein, 'Sources of Power'; Kahneman, Sibony & Sunstein, 'Noise'; the premortem literature (Klein 2007 HBR).
• 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 central practical prescription (individuals should optimize 'generativity,' sharing mental models, over personal productivity/reputation) is not reconciled with the essay's own diagnosis that individual-based evaluation systems create hoarding incentives. No mechanism, structural change, or evaluation redesign is proposed to align incentives with the recommended behavior — it is left as a personal-values appeal.
  Collective problem solving in music, art, science, and software — read next: Organizational-design literature on team-based vs. individual incentive/compensation systems, and on measuring 'enabling' or multiplier contributions (e.g., staff-engineer archetypes, 'multiplier' vs. 'diminisher' leadership frameworks) that attempt to operationalize exactly this gap.
• uninformedThe essay treats the Camerata's ignorance of actual ancient Greek musical practice as a harmless, even useful, legitimizing fiction ('like citing computer science papers from the 70s'), without engaging with the epistemic risk that such founding myths pose when a group's shared 'ground truth' is simply wrong — a risk directly relevant to software teams whose shared mental models can be confidently wrong in the same way.
  Collective problem solving in music, art, science, and software — read next: Work on how groups sustain false shared beliefs / groupthink despite (or because of) shared practice and mutual reinforcement — e.g., organizational research on 'espoused theory vs. theory-in-use' (Argyris), or on collective illusions.
• empiricalNo evidence is offered for the claim that product development is categorically different from manufacturing operations. The introduction relies entirely on the reader's experiential recognition. Later chapters may supply theoretical grounding (endurant/perdurant, Scott's legibility) but the introduction treats the distinction as self-evident.
  Introduction — read next: Read chapters on endurant vs. perdurant and metis vs. legibility for the theoretical backing.
• scopeThe guide targets 'product development operations' but never defines where the boundary of that domain lies. Many of the same representation problems exist in policy, healthcare operations, and other complex domains. The introduction does not address whether the framework generalizes.
  Introduction — read next: Consider applying the ontology lens to adjacent complex domains to test generalizability.
• implicit_premiseThe argument assumes that the manufacturing mental model is the dominant frame organizations bring to product operations. This is plausible but unstated and undefended. Some organizations may already operate with complexity-aware models and still suffer the same visibility problems for structural or political reasons unrelated to ontology.
  Introduction — read next: Look for whether later chapters address political and power-dynamic causes of information distortion alongside representational causes.
• tensionThe introduction implicitly promises that better ontology design can resolve the visibility problem, but also acknowledges that 'words alone will rarely sink the ship.' This creates tension about how much explanatory weight ontology can actually bear versus organizational politics, incentives, and culture.
  Introduction — read next: Track how the guide handles the relationship between naming/representation and the social/political dynamics of organizations.
• incompleteThe article explicitly defers 'how to implement these ideas' and 'who should do this' to other articles in the author's broader Sociotechnical Architecture series, some of which were still unwritten at publication — so the holistic framework is argued for conceptually but not demonstrated through an implementation case study beyond the illustrative Restaurant Product analogy.
  Sociotechnical Architecture as Enabler of Product Thinking — read next: The author's later Sociotechnical Architecture and Systems series, if subsequent installments addressing implementation exist.
• illogicalThe claim that siloed/local optimization 'almost never' maximizes overall customer value is asserted via Ackoff's systems-thinking authority and the restaurant analogy, not demonstrated through a comparative case (siloed optimization tried and found wanting versus holistic co-design succeeding under otherwise comparable conditions).
  Sociotechnical Architecture as Enabler of Product Thinking — read next: extract-dora-2024-accelerate-state-of-devops for metrics-based evidence on this trade-off.
• incompleteThe ethical argument establishes that engineers bear responsibility but offers no concrete mechanisms for exercising it. What should an engineer actually do when their employer deploys a biased algorithm? The text says ethics is not a checklist, but provides no alternative framework for action — leaving a gap between 'you should care' and 'here is how to act.'
  Designing Data-Intensive Applications: The Cloud & Doing the Right Thing — read next: Ruha Benjamin, 'Race After Technology'; Meredith Broussard, 'Artificial Unintelligence'; or practical frameworks like the Markkula Center for Applied Ethics' technology ethics toolkit
• incompleteThe surveillance section does not engage with the argument that surveillance enables genuine safety benefits (e.g., fraud prevention, child safety, counter-terrorism). By not steelmanning the opposing position, the argument is weaker than it needs to be.
  Designing Data-Intensive Applications: The Cloud & Doing the Right Thing — read next: Bruce Schneier, 'Data and Goliath' — which addresses both sides more comprehensively
• incompleteThe connection between Part 1 (cloud architecture) and Part 2 (ethics) is left implicit. Cloud concentration amplifies every ethical concern raised — bias at scale, surveillance infrastructure, accountability gaps — but this connection is never drawn. The two excerpts sit side by side without synthesis.
  Designing Data-Intensive Applications: The Cloud & Doing the Right Thing — read next: This may be addressed in the full book; the gap may be an artifact of excerpting
• incompleteThe text mentions AI-generated code and formal methods as new topics in the 2nd edition but does not explore how AI code generation itself raises the ethical questions discussed in Chapter 14 — e.g., who is responsible when AI-generated code produces biased outcomes?
  Designing Data-Intensive Applications: The Cloud & Doing the Right Thing — read next: The full DDIA 2nd edition likely covers this; also see emerging literature on AI coding liability
• incompleteThe empirical base is thin for a strong, society-wide generational claim: one 319-worker Microsoft/CMU study (a correlation between AI trust and critical thinking, read as causal) plus the author's own course anecdote.
  Det skal være vanskelig — read next: Longitudinal studies of learning outcomes under AI-assisted vs. traditional instruction; the Dreyfus skill-acquisition model; replication of the Microsoft/CMU finding and its direction of causation.
• 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.
• unstated assumptionThe author assumes that the inability to externalize institutional knowledge and design context is a fundamental limitation of AI, not merely a tooling limitation. This conflates current AI capabilities with inherent constraints. Future models with persistent memory, codebase-scale context, and temporal reasoning could potentially bridge this gap.
  Eight years of wanting, three months of building with AI — read next: Read work on long-context models, AI memory architectures, and research on whether design taste can be formalized or learned (e.g., Christopher Alexander's pattern language as a possible bridge).
• omissionThe article does not discuss the economics of AI-assisted development beyond the $200/month Claude Max subscription. The 250 hours of personal time invested is mentioned but not analyzed in terms of opportunity cost or compared to hiring/contracting alternatives.
  Eight years of wanting, three months of building with AI — read next: Compare with analyses of AI coding tool ROI; consider the total cost including cognitive overhead and the discarded vibe-coding month.
• unexamined tensionThe author claims 'AI didn't just make the same project faster -- it changed what the project was' (adding editor extensions, docs, WASM playground). But he also claims the core value comes from the parser architecture, which AI was harmful for. This raises the question: did AI expand the project's scope in the right direction, or did the cheap last-mile features dilute focus on the hard core?
  Eight years of wanting, three months of building with AI — read next: Consider the 80/20 principle in open source: does breadth of features or depth of core reliability drive adoption?
• implicit premiseThe expertise-x-verifiability framework assumes that 'taste' and design judgment are inherently human and non-formalizable. This is stated as obvious but is actually a deep philosophical claim about the nature of aesthetic and design knowledge. If taste could be partially formalized (as design systems and API design guidelines attempt), the framework's boundaries would shift.
  Eight years of wanting, three months of building with AI — read next: Joshua Bloch's 'How to Design a Good API and Why It Matters'; API design guideline literature; whether LLMs can learn design heuristics from large corpora of well-designed APIs.
• 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 spec-verification circularity. The whole 2026 pitch is that AI removes the barrier to WRITING the spec and the glue code. But Moreira also insists there is 'no easy check mark' and that confidence requires 'a lot of understanding'. Judging that an AI-generated spec is a faithful representation of the intended system, and that the 'trivial' AI-generated glue code is correct, still requires exactly the deep understanding that was the original barrier. The talk papers over this with 'when you're happy with your specification' and 'it's very easy for AI to generate the code without inventing anything' — never saying how a newcomer reaches warranted confidence in artifacts they did not author.
  Podcast: Formal Methods for Every Engineer in an AI-Powered Future — read next: Read against the corpus's LLM-fidelity material: llm-limitations (silent corruption, non-determinism, over-attribution) and verifiability, plus the finding that AI code which 'works' is not thereby correct or secure (extract-founders-playbook-building-ai-native-startup#p9) and that agents generating lots of software says nothing about whether it is correct (extract-ai-funhouse-mirror-velocity-debt#p3). Also extract-ai-first-software-delivery#p8 on tests fitting the code rather than the intent — the same fidelity risk one level up, at the spec.
• 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.
• incompleteThe speculation that a non-human, non-textual semantic model becomes 'future source code' does not address how humans would review, debug, version, or trust a representation they cannot read directly — the very problems that helped keep Language Workbenches and intentional programming marginal.
  Fragments: February 9 — read next: Read critiques of projectional editing and intentional programming, and work on reviewability/verification of AI-generated artifacts.
• incompletePublished July 2025 as a compact folk-psychology reflection, this piece sits roughly a year before much deeper technical material on LLM internals now in this corpus. Fowler's own subsequent Fragments writing (extract-fowler-fragments-july-6, published the same month) pivots toward 'mechanical sympathy' for how current LLMs actually work as the recommended discipline, rather than persona-based folk metaphors — suggesting his own thinking has since moved toward direct technical understanding as a complement to, or eventual replacement for, anthropomorphic shorthand.
  Who is LLM? — read next: Track whether Fowler revisits or retires the persona framing in later pieces once mechanistic explanations (e.g. global workspace / J-space research) become mainstream; worth checking whether this piece is complemented or quietly superseded by his later technical framing.
• incompleteDespite being fundamentally a systems argument (three interacting, reinforcing elements described via a 'gears in a transmission' metaphor), the piece never engages actual systems-thinking vocabulary — stocks, flows, feedback loops, delays, leverage points — or cites systems-thinking literature (Meadows, Senge). It presents a static triadic taxonomy rather than a dynamic model of how talent/team/routine reinforce or destabilize each other over time, where the feedback delays are, or which element is the highest-leverage intervention point.
  How to Turn Individual Talent into Organizational Excellence — read next: For a systems-thinking reader, compare against corpus material tagged mental-models/systems-thinking for what a formalized systems treatment of the same claim would add.
• incompleteThe thesis 'det finnes alltid et hierarki' is rescued from triviality by Eikeland's broad definition (formell + uformell + kunnskaps- + framing-makt), but the same breadth makes the claim nearly unfalsifiable. Every conceivable group has some asymmetry of influence on some dimension; calling that 'hierarki' wins the argument by definition. The conversation does not engage the harder question of when the unit of analysis is wrong — when treating a temporary, context-dependent, weak asymmetry as a 'hierarchy' obscures more than it reveals.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Compare to network-and-influence literature (Cross/Parker on organisational networks, Vedres/Stark on structural folds) where the alternative unit is the network of weak ties rather than the layered hierarchy. Also Heath/Sunstein on consensus-driven decision-making to test where 'hierarchy' really is the operating frame.
• incompleteThe claim that flat-org rhetoric is selvbedrag is supported by Eikeland's clinical observation and the innvandrer vignette but not by counter-evidence from organisations that have made the rhetoric operationally real (or that have failed in distinctively non-Eikeland ways). The conversation does not engage Holacracy, Buurtzorg, sociocratic governance, or the long literature of self-managing teams. The result is a strong descriptive claim resting on a single vantage point.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Read Laloux Reinventing Organizations, Buurtzorg case studies, Robertson's Holacracy critically — both for examples of self-organisation that genuinely changes which hierarchy operates and for documented failures that Eikeland's frame would explain well. Pair with Lee/Edmondson's typology of self-managing organisations.
• incompleteThe role-vs-person distinction is presented as universal but it conflicts with a strong current of contemporary leadership literature (authentic leadership, bring-your-whole-self-to-work, vulnerability-based trust à la Lencioni/Brown) that holds that role-thick depersonalised leadership is itself the failure mode in knowledge work. The conversation does not engage these counter-positions; it treats them only implicitly via the Trump example, which is a one-sided foil.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Read Brené Brown on Dare to Lead, Goffee/Jones 'Why Should Anyone Be Led by You?', Lencioni on vulnerability-based trust against Eikeland's role-thick line. The most interesting test case is: are there role-domains where role-thickness is right (dommer, kirurg, politi) and other domains where it is wrong (product-team leadership, R&D leadership)?
• incompleteEikeland's developer-to-leader sorgprosess prescription is rich on the loss side but thin on the gain side. The transition presumably brings new sources of meaning (impact through others, system-level effect, mentoring, organisational design), but the conversation barely names them. The risk for the listener is to internalise the loss-frame and miss the path through.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Camille Fournier's Manager's Path; Will Larson's Staff Engineer/An Elegant Puzzle on the IC-vs-manager fork; Lara Hogan on growing engineering leaders. Pair with Olga Khazan or Lori Gottlieb on the psychology of mid-career identity transitions.
• incompleteThe illusion-of-explanatory-depth intervention (ask for mekanismer not meninger) is presented as reliably productive but Eikeland admits it provokes forbannelse and ejection from rooms. The conversation does not address how to make the intervention land without burning the relationship — i.e., the practice question of how to descend into mekanisme safely. This matters because the intervention has weight only if it can be sustained inside an ongoing leader relationship.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Edgar Schein on humble inquiry; Marshall Goldsmith on stakeholder-centred coaching; Patterson et al. Crucial Conversations. The Heis-internal pairing is with Brede Moe (ep 9) on psykologisk trygghet as the precondition for being usable as a diagnostic outsider.
• uninformedThe argument that teknologene have gained makt at the expense of 'litt enklere selgere' is named as a flagged trade-off but not analysed. The conversation does not engage the broader political-economy story of which professions rise and fall with each kunnskapshierarki shift, or the consequences for democratic and labour-market dynamics when one type of fag becomes dominant. Eikeland's clinical vantage is not designed for this question; the gap is honest but real.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Read Daniel Markovits The Meritocracy Trap, Michael Sandel The Tyranny of Merit on the consequences of credentialist hierarchies. For the Norwegian case specifically, NAV's own reports on labour-market polarisation.
• incompleteEikeland insists hierarchies are inevitable but does not develop how to design good hierarchies versus bad ones. Hierarchy as a design object — its arity (span of control), its time-horizons per level, its dual lines (formal/uformell), its rotation, its accountability — receives no operational attention. The descriptive claim therefore stops short of a constructive prescription beyond 'operate at the right abstraksjonslag and recognise rolle vs person.'
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Elliott Jaques on requisite organisation and time horizons per level; Stafford Beer's Viable System Model; James Mwangi on adaptive governance. Pair with Printzell Halvorsen (ep 8) on the Vend operating model as a worked example of an explicit, designed hierarchy that honours these structural pressures.
• incompleteThe claim that ledelse-as-coordination kicks in around eight people is asserted as 'avhenger litt av hvor mye interaksjon du trenger' but not defended against the broader social-science literature on group size, span of control, and self-organisation thresholds. The number is plausible but the conversation does not engage why eight rather than five or twelve, what happens in distributed/asynchronous groups, or how the threshold shifts with technology.
  4) Morten Eikeland: Det finnes alltid et hierarki — read next: Robin Dunbar's hierarchies of group size (5, 15, 50, 150); Christopher Allen's optimal group sizes; Tuckman's small-group dynamics. For the distributed case, GitLab's all-remote handbook on team sizing and the post-COVID literature on async coordination.
• incompleteHaugseth's epistemic update on skye is offered as an instance of changing her mind, but the underlying mental model that drove her earlier full-pro-cloud stance is not interrogated. What other current convictions might be in the same epistemic position now? The 'how does a leader earn forankring on the world' question (same as the Olrud Moen ep 15 gap) is unaddressed.
  7) Stine Haugseth: Insourcing, retning og strategi på en ølbrikke — read next: Annie Duke 'Thinking in Bets' (already in user's library) on calibration and the cost of being skråsikker about probabilistic claims; Philip Tetlock on superforecasting; Donella Meadows on systemic leverage points.
• incompleteThe analogy between Bainbridge's control-room operators and software engineers is taken as given but never defended. Bainbridge studied operators of physical, bounded, regulated, slow-dynamics systems (nuclear plants, chemical processes, aviation cockpits) where (a) the human's role is fundamentally MONITORING-AND-OVERRIDE, (b) the system's correct behavior is specified ex ante, (c) regulators audit the human-machine boundary, and (d) the operator is licensed and trained on simulators. Software engineers are CONSTRUCTORS — they design the system itself, not just operate it; the system's correct behavior is partially undefined; no licensing or regulator polices the boundary; and the 'incident' role is only one slice of the work. Reed's mapping works best for the incident-response slice (which is what his job is) and is weakest for routine development. He never disambiguates these. The argument that 'AI ironies for engineers = Bainbridge ironies for operators' may overgeneralize from the incident-response edge case to the whole of engineering practice.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: Read the original Bainbridge 1983 paper directly. Then Hollnagel & Woods on resilience engineering, and David Mindell's 'Our Robots, Ourselves' (history of human-machine collaboration). Pair with Naur's 'Programming as Theory Building' for the contrasting view that software engineering is theory construction, not operation.
• incompleteReed's prescription assumes organizations will reinvest AI-driven efficiency gains in human thoroughness, but the same talk reports that the current pattern is the opposite: 'AI's main impact on my life is more incidents because we're generating more code.' The systems-thinking question of how to design feedback loops that prevent capture of efficiency-as-throughput is left untouched. Without that loop, the 'AI does efficiency, humans do more thoroughness' division is a moral exhortation, not a mechanism.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: Donella Meadows on leverage points (especially feedback loops, rules of the system, and goals of the system). John Cutler on institutional overload and on how organizations metabolize efficiency gains. Possibly Christensen on capabilities-as-process — i.e., the org's existing process consumes new capability.
• incompleteThe empirical evidence is thin and uneven. The nurses study (Woods et al., July 2025) is presented as decisive but is a single study, in a different domain (clinical prediction), with a likely small N; the developer study (METR-style) is cited from memory. Reed does not engage the contrary evidence (e.g., positive AI productivity findings from DORA, GitHub Copilot studies) or distinguish task types where AI does and does not pay off. The asymmetric-risk frame is compelling and probably right but is underdetermined by the cited data.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: DORA 2024/2025 AI findings, the Princeton/MIT studies on developer AI productivity, METR's actual published methodology, Woods's published paper (rather than the slide). Also Cal Newport / Bainbridge-skeptics on whether the operator analogy fits knowledge work.
• incompleteThe animacy paradox is introduced as a phenomenological observation but is not connected to design recommendations. If interpretation flips with situational stakes, what design pattern reliably keeps the deterministic-machine interpretation alive in high-tempo contexts? Reed gestures at attribution and explainability but doesn't develop this.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: Lucy Suchman 'Plans and Situated Actions'; Dave Woods's papers on 'envisioned worlds' and on coordination breakdowns; possibly the air-traffic-control HCI literature on 'mode confusion'.
• incompleteReed touches the systems-thinking question (juniors who never built the mental model, attrition of senior engineers carrying tacit knowledge) but doesn't push it to its leverage-point: the org's HIRING and TRAINING flows may be where the irony actually lives, not in the engineer's individual relationship to AI. The dynamic he describes is a stock-and-flow problem (the stock of tacit knowledge is depleting faster than it is being replenished) and warrants stock-and-flow analysis.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: Meadows again on stocks-and-flows; the National Research Council's literature on knowledge attrition in nuclear and aerospace; and possibly the apprenticeship literature (Lave and Wenger, situated learning).
• illogicalReed conflates 'AI is non-deterministic' with 'AI lacks interpredictability.' These are related but distinct. Humans are non-deterministic and have high interpredictability with their teammates. The reason AI lacks interpredictability is not non-determinism per se but lack of a SHARED MODEL of context, goals, and norms. This matters because it suggests the fix is not 'make AI more deterministic' but 'invest in shared context and norm-conformance' — a different research and product direction.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: Herbert Clark on common ground in conversation; the multi-agent systems literature on shared mental models; recent work on AI alignment through context-engineering.
• incompleteTeam-level and organizational dynamics are almost absent. The piece is written from the individual developer's interior, with the team as a setting but not an object of analysis. Yet many of the named harms (large PRs defeating review, knowledge transmission to new developers, burnout) are fundamentally social phenomena. What happens to pair-programming culture? To mentorship? To code-review-as-teaching? To the social production of shared mental models when an agent is the third participant? The essay names the symptoms but stays at the level of the individual practitioner.
  KI, utvikling og følelser — read next: Pair with John Cutler on team operating systems (the 'institutionalized overload' arc) and with Beck/Cutler on how design discussion functions socially. Also read Pamela Hieronymi or similar on what attention/understanding requires of a community, not just an individual. The user's existing extraction on 'AI Joy Gap Developers' — which treats the polarization as needing organizational structures (AI platform teams, cultural practices reconnecting developers) — is a direct complement to Moe and worth reading together.
• incompleteThe 'law is code' analogy is accepted uncritically. It reduces legal work to large-document pattern-matching and never examines where legal reasoning — interpretation, advocacy, novel argument, judgment under adversarial conditions — diverges from what document-summarization AI actually does, which is exactly where the analogy would break.
  Lawyers are quietly becoming builders — read next: Critiques of legal formalism and 'law is code'; the gap between document processing/retrieval and genuine legal reasoning; LLM limitations on reasoning versus summarization.
• incompleteThe feedback loop claim is asserted via metaphor ('systems thinking terminology') but not demonstrated. There is no evidence that these activities actually compound rather than merely accumulate. The mechanism by which speaking leads to organizing leads to centrality is never specified — it could equally be a survivorship bias narrative.
  Developing Your Leadership Skills toward Principal Engineering — read next: Research on career capital theory (Cal Newport's 'So Good They Can't Ignore You') for a more rigorous framework on how skills compound
• incompleteThe 'systems thinking' teaching method (one-click zoom-out) is offered purely as an individual habit, with no discussion of how Netflix evaluates whether hires or existing staff actually possess it, or whether it's teachable at scale versus self-selecting for people who already have it.
  Netflix CPTO on AI and the future of product and tech roles | Elizabeth Stone — read next: Same gap already flagged in this corpus for systems-thinking claims generally — read against extract-tbm-420-the-ai-playbook-puzzle and extract-leadership-skills-principal-engineering#g2, which both note that 'systems thinking' claims tend to be asserted via metaphor rather than demonstrated.
• implicit_premiseThe article assumes that the Kubernetes analogy (interceptors as admission webhooks, gateways as ingress controllers) is the right mental model for MCP governance. This frames MCP as infrastructure middleware, which may not be the only valid framing -- it could also be framed as a capability/permission system, a marketplace, or a service mesh.
  AAIF's MCP Dev Summit: Gateways, gRPC, and Observability Signal Protocol Hardening — read next: Compare with capability-based security models (e.g., object-capability model) and service mesh patterns (Istio/Envoy) for alternative framings.
• incompleteThe headline lesson under-credits the expertise leg. The team concludes the most important step was building the dataset, 'not the clever assembly reading or deep knowledge' — but isolating the libunwind race still required exactly that deep systems knowledge (red zone, signal frames, %rsp-before-%rip ordering). The dataset localized the two populations; it did not explain either root cause. The piece never asks how much interpretation depended on scarce expertise, nor whether 'just build the dataset' generalizes to a team that cannot read the assembly.
  OpenAI Fixes 18-Year-Old GNU libunwind Bug by Treating Crash Debugging Like Epidemiology — read next: The interplay of data infrastructure and human diagnostic expertise: whether population data substitutes for, or merely presupposes, deep systems knowledge; and the systems-thinking distinction between localizing a problem and explaining it.
• uninformedBooch dismisses Amodei's prediction partly on the basis that current models are trained only on previously-seen patterns, but doesn't engage with the trajectory argument — that model capability has been expanding beyond narrow CRUD patterns at a measurable rate — which is the actual empirical crux of near-term automation-timeline disagreements, rather than a settled historical analogy.
  The third golden age of software engineering – thanks to AI, with Grady Booch — read next: Pair with benchmark- or practitioner-report-driven pieces examining the rate of capability expansion across recent model releases, not just a snapshot of current limits.
• 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.
• 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.
• 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.
• illogicalThe 'AI as junior developer' metaphor contains a self-defeating dynamic the author doesn't notice: if AI eliminates junior training, and seniors are needed to guide AI, then the pipeline that produces seniors is broken. The metaphor predicts its own obsolescence — eventually there are no seniors left to guide the AI-junior. This is the most consequential implication of the post and it goes entirely unaddressed.
  SMOC.AI's Post — 5 Minutter: AI og utviklere — read next: Systems thinking (Meadows) on stocks and flows — the senior developer pool is a stock that requires inflow from the junior pipeline; cutting the inflow depletes the stock over time
• incompleteEvery social metric in the book (ownership, fractal value, knowledge maps, knowledge-loss simulation) is built entirely on human-author version-control identity as a proxy for who understands the code. The book has no answer for a world where a large share of commits are authored by AI agents under human supervision/review, which breaks the implicit equation of 'who wrote it' with 'who understands it' exactly where agent-authored commits are frequent and numerous. For AI-era teams, this suggests the next generation of these metrics may need 'who understands this code' decoupled from 'who/what wrote this code' — reviewer/approver identity or demonstrated modification history might be better proxies than raw commit authorship once agents are prolific contributors.
  Software Design X-Rays — read next: Look for post-2023 work that re-derives social code metrics (ownership, knowledge mapping, bus-factor-style analyses) using reviewer/approver signals rather than commit authorship, and for any extension of Tornhill/CodeScene's own Code Health work into the social half of this book.
• incompleteThe book's code-age argument depends specifically on human memory decay (the Ebbinghaus forgetting curve) to explain why mid-aged code is the most expensive category to maintain. If AI agents — which have no forgetting curve within a session but also no persistent memory across sessions without deliberate context engineering — become primary code modifiers, it is unclear whether 'mid-aged code' remains the most expensive category, or whether a different, session-reset-driven risk curve applies instead.
  Software Design X-Rays — read next: Look for work on how code-age-based maintenance risk should be modeled when the dominant modifier re-derives understanding from scratch each session regardless of the code's calendar age.
• incompleteCutler shows that mirrors alone don't produce change and pivots to 'mirroring', but never shows how mirroring actually surfaces and resolves the hard, uncomfortable realities (the coin-flip odds, the org-chart vestiges) that mirrors were meant to confront. Without that, 'helping people feel seen' risks becoming a sophisticated way to avoid the elephants — comfort substituting for change, and the resolution quietly undermining the very problem it set out to solve.
  TBM 426: The Trouble With Mirrors — read next: Read Amy Edmondson on psychological safety as enabling candor (not merely comfort); Kegan & Lahey, Immunity to Change, on how meaning-making translates into action; and Peter Block's Community in full, alongside Cutler's own operating-systems / legibility work (TBM 414, the visibility guide) for the mechanism from being-seen to actually confronting the hard things.
• incompleteThe relationship between mirroring and accountability is left unresolved. Cutler insists surfaced truth must be met with 'stewardship' and asks 'who is accountable for what happens next', yet the mirroring resolution emphasizes feeling seen and NOT being 'held against' people — potentially in tension with the accountability that acting on uncomfortable truths requires.
  TBM 426: The Trouble With Mirrors — read next: Read on accountability cultures (Allen Holub) and the distinction between blame and accountability; Cutler's own writing on directly-responsible individuals; and restorative-vs-punitive framings of organizational feedback.
• incompleteThe cynical, power-analytic read of transparency advocates ('actually about power'; candor is cheap for the already-won) is asserted without evidence and, as Cutler half-concedes ('I realize all of this sounds negative'), risks proving too much: by the same logic his own mirroring prescription is equally positional and equally a bid to define what good relating looks like.
  TBM 426: The Trouble With Mirrors — read next: Read Langdon Winner, 'Do Artifacts Have Politics?', and critical-management studies for the rigorous version of the power-in-ideals claim, and test whether the argument self-undermines when turned on the author's own prescription.
• incompleteNo account of mechanism or scale. Cutler's clearest example of mirroring is a two-party coaching dyad (you, the coach, the scale), but his own solo-vs-collective distinction makes the collective the hard case. How a leader practically moves a whole team or organization from mirrors to mirroring — how many people 'draw the map side by side' at once — is not addressed.
  TBM 426: The Trouble With Mirrors — read next: Read facilitation and large-group-intervention literature (Open Space, liberating structures) and Peter Block's Community for community-scale practices that operationalize joint meaning-making beyond the dyad.
• incompleteCutler concedes at the outset that typologies 'became fodder for some fun discussions and had that occasional wow, how right! horoscope vibe,' but never weighs this genuine value (shared vocabulary for self-reflection, low-stakes team bonding, an entry point into talking about difference at all) against the costs he documents. The piece critiques typologies' insufficiency for the hard work of teamwork without arguing they are net-harmful, leaving open whether a more modest, supplementary use of typing survives the critique.
  TBM 440: The Problem With Putting People in Boxes — read next: None in this corpus yet directly weighs the self-reflection/vocabulary value of typologies against their organizational misuse — a genuine open question for a future read on personality-assessment validity research.
• incompleteThe three academic traditions cited (institutionalization: Berger, Luckmann, Zucker; organizational culture: Schein, Martin; social dominance: Sidanius, Pratto) are named but not engaged with — no specific finding, mechanism, or quotation from any of them appears in the piece. They function as authority gestures that lend the argument credibility rather than as evidence a reader could verify or follow up on directly from this text.
  TBM 440: The Problem With Putting People in Boxes — read next: Read Berger & Luckmann's 'The Social Construction of Reality' and Sidanius & Pratto's social dominance theory directly to check how closely Cutler's depersonalization-of-norms argument tracks their actual claims versus using them as a plausibility gesture.
• uninformedThe claim that underrepresented people bear a disproportionate adaptation burden is asserted as established via named literature (social dominance theory) but no data, case study, or even a paraphrased finding is offered within this piece to substantiate the specific magnitude or mechanism of that burden in a workplace setting — it is plausible and consistent with the field, but not evidenced here.
  TBM 440: The Problem With Putting People in Boxes — read next: Empirical organizational-behavior research on code-switching, executive-presence coaching, and promotion-rate disparities by demographic group, to see what evidence actually exists behind the claim as applied to workplaces specifically (versus the broader social-dominance literature Cutler gestures at).
• illogicalThe Steve Jobs rebuttal doesn't address the question it's answering. Adi's challenge was about trusting one's own vision over outside input during a strategic/creative call; Goldsmith's answer (Apple needed Cook's operational management to stabilize post-Jobs) is really about needing both 'artist' and 'soldier' leadership types in an organization -- a different claim that leaves the original 'when do you trust your gut' question open.
  Why Great Leaders Need More Than Good Judgment — read next: Read against other treatments of Jobs's leadership style (e.g. any extraction touching founder-mode / visionary leadership) for a more direct engagement with when concentrated individual judgment outperforms broad consultation.