Architecture Decision Records

Lightweight written records of architectural decisions and their rationale — cheap at write time, invaluable to both future humans and cold-starting agents.

Also known as: ADR, ADRs, ADR (Architecture Decision Record), Architecture Decision Records (ADR), decision log / lightweight ADR, decision log

How authors use it

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

Documents (10)

• Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs Cassie Shum · 2026-09-12 source ↗ Reader 🖥️
  A knowledge graph earns its place in agentic software engineering less as a retrieval-accuracy mechanism (an edge that has largely eroded as models got better at parsing raw context) than as an organizational substrate for four practices: assembling task-specific context bundles, tracing decision provenance from idea to production, treating code rather than spec as the ground truth of system behavior, and making agent activity visible enough to audit and manage.
• Article: Agentic Fitness Functions: Extending Evolutionary Architecture Beyond Deterministic Rules Hemant Kumar Mahato, Łukasz Sieczkowski, Vijayasenthilkumar Kuppusamy · 2026-08-17 source ↗ Reader 🖥️
  Deterministic fitness functions should remain the primary architectural governance mechanism, but calibrated, evidence-scoped, escalation-capable AI 'agentic fitness functions' should be added as an advisory judgment layer for architectural concerns that are evidence-bound but not reducible to a rule — boundary fidelity, semantic contract drift, stale ADR assumptions — so that architectural judgment itself becomes observable, auditable, and, where patterns repeat, convertible back into deterministic guardrails.
• When AI Writes the Code, Specifications Need an Exit Strategy Markus Eisele · 2026-08-17 source ↗ Reader 🖥️
  When building software with AI coding agents, a specification should be a temporary 'change brief' that describes only the delta between current and intended behavior and expires at release, because durable system knowledge belongs in the native artifacts engineering already trusts to stay synchronized with the code — schemas, types, tests, policies, and telemetry — not in permanent prose that inevitably drifts and consumes an agent's finite context budget.
• 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.
• 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.
• 13) Tobias K. Torrissen om kodekvalitet, konferanser og AI Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-03-16 source ↗ Reader 🖥️
  In the age of LLM-generated code, the durable value of an engineering leader is not in writing code but in cultivating the engineering practices, explicit design discipline, and craft community that determine whether a long-lived system can be understood, maintained, and adapted — and code quality, understood as 'obvious over clever,' matters more in this era, not less.
• Coding Agent Development Workflows Nick Tune · 2026-01-07 source ↗ Reader 🖥️
  Making an autonomous coding agent reliable enough to go from ticket to mergeable pull request requires converting as much of the surrounding process as possible into explicit, versioned, tool-agnostic artifacts — deterministic scripts, a single shared source of truth for conventions that every agent and review tool reads, and structured task templates that reject underspecified work — because agent reliability is bounded by the explicitness of what surrounds it, not by the model's capability alone; and the harder unsolved problem this creates for teams and organizations is deciding how explicit conventions must be, who owns them, and at what level (team vs. org) they should be standardized.
• 5) Vidar Moe: Det eneste Vidar vil er å ha det lett Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2025-11-17 source ↗ Reader 🖥️
  Vidar Moe's core engineering-leadership philosophy is 'gjøre det lett og rett' (make it easy and right) — a Toyota-Way-inflected craft and leadership stance in which you lead an organization most powerfully not by exhortation but by patiently building the tooling, frameworks, fagtid, hiring filters, fixed-term leadership rotation, and shared decision arenas that make the right thing the path of least resistance; the episode's ironic title ('the only thing Vidar wants is to have it easy') inverts this — Moe wants the work to be easy precisely because he is willing to do the very hard, decade-long, mostly invisible work of removing friction from doing the right thing, and his current concern with AI agents is the natural next chapter of the same project.
• Scaling the Practice of Architecture, Conversationally Andrew Harmel-Law · 2021-11-30 source ↗ Reader 🖥️
  Architecture should be practiced as a decentralized, conversational discipline — anyone can make an architectural decision as long as they first seek out and record advice from those meaningfully affected and those with relevant expertise (the 'Advice Process') — supported by four lightweight tools (Architecture Decision Records, a recurring Architecture Advisory Forum, team-sourced architectural principles, and a technology radar) that let architecture scale with team autonomy instead of being bottlenecked on a small group of designated architects.
• How do software development teams manage technical debt? - An empirical study Jesse Yli-Huumo, Andrey Maglyas, Kari Smolander · 2016-08-08 Reader 🖥️
  Software development teams manage technical debt unevenly and mostly informally -- across eight distinct activities (identification, measurement, prioritization, prevention, monitoring, repayment, documentation, communication) teams sit at different maturity levels (unorganized, received, organized), and the key differentiator is not tooling but whether TD communication and documentation are treated as first-class practices, since every other activity depends on TD being visible and discussed rather than left in individual developers' heads.

Propositions touching this concept (5)

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

2025-01

• explicit⚡ disputed & corroboratedAdding more context (context files, ADRs, rules) to guide agent behavior degrades output quality rather than improving it, because summarization quality degrades as context grows.
  Agents don't know what good looks like. And that's exactly the problem. · p4

2026-01

• explicitDeciding which conventions should be standardized organization-wide versus left to team discretion is a genuine, unresolved tension; a workable middle ground is to standardize at the level of principles (e.g. 'every team must have documented coding standards and ADRs accessible to AI agents and review tools') while letting each team choose its own concrete standards and tooling to satisfy that principle.
  Coding Agent Development Workflows · p10

2026-04

• explicitcontestedArtifacts built for team guardrails (coding standards in CI, ADRs, templates) become the constraints that keep AI agents on track.
  The Organization Is the Bottleneck · p8

2026-06

• implicitestablishedAGENTS.md, ADRs, learnings files and specs are the right substrate for externalized intent — i.e., the right artifact format already exists.
  The Intent Debt · p25

2026-07

• explicitdevelopedPlanning should use interactive intent elicitation rather than the human writing the plan: instead of plan mode, an agent grills the human one question at a time, explicitly separating facts (which the agent discovers by exploring the code) from decisions (which only the human can make), captures rationale in ADRs and a glossary, and gates on explicit human confirmation before implementing.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p9

Open gaps (28)

• incompleteThe article assumes review is primarily about correctness/quality of code-as-written. It doesn't address review's role in architectural drift, dependency hygiene, security review, or other concerns where a fresh reviewer's distance from the work might be a feature, not a bug.
  From Async Code Reviews to Co-Creation Patterns — read next: Threat modeling literature; architecture decision records; literature on outside-in review for security and design coherence.
• incompleteArchitectural-coherence prescription (CLAUDE.md, specs before code) is good advice but is reintroducing classical software-engineering discipline (formal specs, ADRs, design docs) without acknowledging the lineage. The implicit message — 'this is new' — undersells how much of the prescription is rediscovery.
  The Founder's Playbook: Building An AI-Native Startup — read next: Re-read Kent Beck (Tidy First?), structured-design literature (Yourdon & Constantine), and ADR/design-doc practice writeups against the playbook's reframing.
• uninformedWritten in 2021, the article has no occasion to consider what happens to the Advice Process and ADR discipline once a large share of code is authored by AI coding agents rather than humans — specifically, whether an agent can be a legitimate decision-taker under the Rule, whether an agent can meaningfully 'seek advice,' and whether agent-authored ADRs would carry the same teaching/learning value for human teams that Harmel-Law attributes to human-authored ones.
  Scaling the Practice of Architecture, Conversationally — read next: See the corpus's AI-era ADR and architecture-governance material (e.g. extract-ai-agents-own-initial-code-draft, extract-osmani-intent-debt) for how this question starts to get addressed once agents are in the authoring loop.
• incompleteThe episode systematically tells the success-side of the story. Crisis → response → improvement is the recurring arc, but failed experiments, dead-end framework choices, or instances where 'gjøre det lett og rett' produced unintended organisational uniformity are absent. Moe's stated regret is only directional (could have done more, faster, in more places), not structural (e.g. 'this particular default we engineered was wrong'). The hosts twice surface the hierarchy-is-inevitable point but do not press on whether the framework-team's 'easy and right' becomes a hidden orthodoxy.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with Allen Holub's #NoAccountability strand (already in the user's persona) and with anything on the costs of platform-engineering paved roads (e.g. Charity Majors / Honeycomb on the limits of golden paths). The user's existing extraction on Cutler's institutionalised overload is a strong complement here — Cutler's frame would ask what the second-order costs of the SpareBank 1 system look like.
• incompleteMoe's persistent 'vi' is itself a load-bearing rhetorical pattern that the hosts notice in closing but do not unpack. The episode is a portrait of a person who declines to be individuated — he says 'vi' even when narrating decisions whose intellectual origin clearly lies with him personally. This is consistent with the leadership-through-defaults thesis (the work is the structure, not the speaker) but it also obscures the part of the story that does depend on a specific senior practitioner persistently present in the system for 14 years. The question 'how transferrable is this without Moe (and Stian)?' is not engaged.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in tension with the previous Heis episode on hierarchy (Eikeland, ep 4, alluded to: 'forrige podcast-episoden snakket om... det er sjelden helt flat struktur') and with the leadership-presence strand in the user's library (Cutler on power and space, TBM 413). Beck's writing on senior individuals' role in evolutionary design is a direct anglophone parallel.
• incompleteThe 'organisatorisk gjeld' coinage at the close is the most pregnant unfinished idea in the episode. Moe gestures at the next direction of 'lett og rett' — engineering golden paths for product development itself, with good practices baked into roadmap tooling — but does not work it out. This is exactly the territory where the AI question reconnects: an agentic product-development assistant that encoded the right defaults could be the next instance of 'lett og rett', and would be a Moe-shaped answer to the alienation worry from his essay.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Pair with the user's existing extractions on harness engineering for AI coding agents and on 'Agents Don't Know What Good Looks Like'. The Backstage / Internal Developer Platforms tradition (Spotify) is the obvious anglophone analogue. Team Topologies (Skelton & Pais) and DORA's recent platform engineering findings are the natural canon. Truls's closing observation that Toyota → DORA → Team Topologies is one lineage is exactly the bridge.
• incompletePair programming is named as the most effective form of knowledge sharing and as the substrate that the rest of the infrastructure exists to support, but the cost question (developer preference, time investment, neurodiversity, hybrid/remote context) is not engaged. Moe acknowledges that change in this direction is 'ordentlig seig' — really tough/slow — but does not ask why even at SpareBank 1, with all the structure in place, pair programming is not yet universal. The same gap exists in his essay's TDD-with-the-agent prescription.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read Birgitta Böckeler's recent work on remote pair programming, and the user's already-extracted Beck material on TCR (which functions as a half-step toward pair-discipline). The 'AI Joy Gap Developers' extraction the user already has — which treats reconnection-of-developers as needing organisational structure — is a direct complement.
• incompleteThe Norwegian / Lean-Norwegian context is implicit but not theorised. The åremål concept comes from Norwegian political and academic life and is being repurposed for engineering leadership. The fagtid concept has roots in Norwegian work-culture autonomy ideas. The DORA / Lean / Toyota convergence Truls names at the end is itself partially a Nordic management-culture convergence. There is a comparative essay latent here that the episode does not write.
  5) Vidar Moe: Det eneste Vidar vil er å ha det lett — read next: Read in parallel with NAV's 'optimizing for fast flow' piece (already in the user's queue), with Norwegian Self-Determination Theory–inflected management writing (autonomi, mestring, mening), and with the wider tradition of Nordic engineering culture vs. anglophone agile-at-scale. The user's coding-agents corpus already includes Nils Brede Moe (no relation? — but a Nordic empirical-software-engineering voice in the same neighbourhood, including the upcoming Heis episode 9).
• incompleteTorrissen's frame is largely Norwegian consultancy and public-sector. The 30-year-lifespan argument is anchored in NAV/Skatt/politi; he gestures at differential quality bars for low-stakes consumer apps but does not engage with product-company contexts (startup, scaleup, SaaS) where the relevant time horizon is 3-5 years and the relevant readers are 5-10 engineers, not 70 forvaltere.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Read this against the Pocock workshop extraction (product-company AI workflow) and Vidar Moe (Heis), to see how product-company engineers calibrate quality differently.
• incompleteThe 'engineering practices matter more under AI' claim rests on one cited Telenor talk. Strong intuition, weak evidence. A serious version needs DORA-style measurement of practice maturity × AI uplift.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: DORA 2025 (already in user's library); the Entur AI adoption piece; Addy Osmani's agent patterns; any rigorous productivity studies.
• incompleteThe 'obvious over clever' principle is presented as inheritance from NAV's tekniske retning but the tradeoff against domain-modelling power, type-system expressiveness, and idiomatic language use is not explored. A 'maximally obvious' codebase in a functional language with strong types may look obscure to a Java-trained 70-forvalter pool.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Greg Young / Vlad Khononov on domain modelling; Ousterhout's 'A Philosophy of Software Design'; Rich Hickey's 'Simple Made Easy' (vs. 'easy ≠ obvious').
• incompleteTorrissen acknowledges he's about to participate in a recursive case (reviewing code that was itself generated agentically) and only jokes. The methodology gap — how does code review change when the developer's intent is partially encoded in prompts, ADRs, and context files rather than commit history — is left for next time.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Anthropic 'harness design' talk and the Pocock workshop already in this corpus.
• incompleteThe advice to juniors assumes the fundamentals taught today are the right ones; doesn't engage with the possibility that fundamentals themselves need re-curation for a world where LLMs are the second author. What does TDD even mean when test generation is also automated?
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Kent Beck's recent 'Tidy First?' work on AI and design; 'starving genies' series; DORA on AI testing practices.
• uninformedTorrissen disclaims familiarity with the formal 'distribution law' he invokes (Parnas/Helland-style). He gets the spirit right but doesn't engage with the literature on when distribution is forced (latency, regulatory, fault isolation).
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Pat Helland's papers; Parnas on module boundaries; Vlad Khononov directly.
• incompleteCode quality discussion is silent on data and persistence design — arguably the longest-lived and hardest-to-change layer in 30-year systems. The whole conversation is about behavioural code.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Stripe-style schema evolution practice; Martin Kleppmann's data engineering work; event-sourcing reflections from CQRS practitioners.
• uninformedUlseth notes he has not yet seen conversational architecture practiced and that sociotechnical architecture is a new acquaintance — yet these are the frameworks he is now bringing into Fremtind's IT strategy. The talk does not engage seriously with the published critiques of these models (e.g. that Team Topologies under-specifies platform-team funding, or that Harmel-Law's model assumes a maturity teams may not have).
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Andrew Harmel-Law's own book and the Architecture Decision Records literature; critical reviews of Team Topologies (Manuel Pais et al.).
• incompleteThe four-rebuilds story is reported as triumph but never costed. Destroying and rebuilding the platform architecture four times has a cost — for the consuming squads who must re-learn it, for the regulators who must re-approve it, for the institutional memory that bleeds out at each rebuild. The article reports the platform team's experience ('it worked perfectly for us') without checking the consumer side. The same testimony from the squads might read very differently.
  How a Culture of Data-Driven Conversations Can Support Platform Engineering — read next: Ford, Parsons & Kua on evolutionary architecture (the disciplined version of what Petean is describing). Hohpe on architecture decision records and the institutional cost of irreversibility. Naur on programming-as-theory-building — what gets destroyed in a rebuild that isn't in the code.
• incompleteThe harness's provenance/audit trail is written back into the graph by the same agent (or an agent-driven summarization step) that performed the work, with no described independent, agent-can't-edit instrumentation layer verifying the record matches what actually happened — a self-reported chain of custody.
  Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs — read next: Read against extract-the-meter-was-always-running (especially its claim that an agent cannot be the system of record for its own authority, cost, or refusals, and that evidence must be captured at instrumentation points the agent cannot bypass) for a corpus-level argument that self-reported agent provenance specifically fails an auditor.
• 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 'golden path vs golden brick' distinction is rhetorical, not analytical. What actually changes when you move from path to brick? The article never decomposes the shift along the three axes where the shift really lives: (a) governance — who owns correctness, the platform team (path) or the consuming team (brick); (b) composability — who designs the assembly, and against what contract; (c) team autonomy — does the consuming team have the decision-rights, time, and skill to assemble well? Without this decomposition, 'bricks' is a slogan, not a model.
  How Platform Engineering Using Golden Bricks Can Enable Fast and Smooth Delivery — read next: Skelton & Pais, Team Topologies (esp. platform team / stream-aligned team interaction modes). Camille Fournier's writing on platform teams. Gregor Hohpe on architecture decision records and IT architecture as conversation. Manuel Pais on the cognitive-load assessment.
• 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.
• incompleteNo account of how the criteria themselves get updated over time, who has authority to add, remove or revise a bullet, or how a team's disagreement with a criterion (e.g. believing a 'falls significantly short' item doesn't fit their context) gets resolved.
  What good software looks like at REA — read next: Living/evolving internal standards literature — lightweight governance models such as RFC processes or ADR-based amendment for engineering guidelines themselves, not just for individual system decisions.
• incompleteThe article never addresses teams whose native artifacts are themselves weak or absent (no real schema contracts, thin or no test suite, no telemetry). For them, 'keep durable facts in their native form' recommends a home that doesn't yet exist, and the article gives no guidance on sequencing — build the native artifact first, or use prose as a legitimate transitional stopgap while it matures.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Look for material on artifact/observability maturity models, or on how teams bootstrap schema, test, and telemetry discipline in codebases that currently have none, to test whether prose specification is a legitimate transitional artifact rather than pure waste.
• uninformedThe mapping of durable-fact categories to native artifacts (API shape to schemas, data invariants to types, security to policies, architecture to tests, reliability to telemetry, release to CI/CD) treats each category as if it maps cleanly one-to-one, without engaging cases where a single durable fact spans several categories at once (e.g., a business policy that is simultaneously a data invariant, a security rule, and a UX constraint), or with prior literature on the difficulty of converting tacit organizational knowledge into formal artifacts.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Knowledge-elicitation and requirements-engineering literature on tacit-to-explicit knowledge conversion (e.g., Nonaka & Takeuchi's SECI model), and this corpus's own organizational-forgetting material (extract-3-ways-ai-can-free-orgs-from-legacy-workflows) on how depersonalized evidence surfaces facts nobody wrote down anywhere.
• incompleteThe empirical studies cited (ambiguity repair improving results ~31%, SWT-Bench doubling precision, TLA+ translation reaching only ~27%/9% syntactic/semantic correctness) support 'small specs plus independent verification' in general, but none of them actually measures this article's central claim — that treating specs as temporary and promoting only durable facts to native artifacts reduces total cost or drift compared to alternative approaches.
  When AI Writes the Code, Specifications Need an Exit Strategy — read next: Look for empirical work directly comparing 'temporary change-brief' workflows against both prose-heavy and specless workflows on drift, rework, or maintenance cost — the same empirical gap already flagged in extract-eisele-ai-coding-agents-need-clear-specs#g1 for the U-shaped cost curve, now recurring for this piece's 'expire the spec' claim.
• uninformedThe framework assigns documentation/representation responsibility to "the development team, software architect(s)" as an undifferentiated group, with no examination of whether documentation that exists only as unstructured JIRA tickets or personal notes functions any differently from documentation written to be read later by someone who wasn't present for the original decision -- the distinction between 'a record exists' and 'the record externalizes the rationale a future reader needs' is never drawn.
  How do software development teams manage technical debt? - An empirical study — read next: The corpus's architecture-decision-records and intent-debt concepts name exactly this distinction (a record vs. an externalized, load-bearing rationale) and would sharpen this paper's flat treatment of 'documentation' as a single undifferentiated activity.