Technical Debt Is Becoming an AI Problem  🔗 **Source:** [Technical Debt Is Becoming an AI Problem](https://www.jonoalderson.com/conjecture/technical-debt/) > [!note]+ Document Notes > tags: [technical-debt, ai-standards, organizational-architecture, adaptability, web-strategy, governance, ai-readiness] > author: Jono Alderson > source: Jono Alderson > reference: https://www.jonoalderson.com/conjecture/technical-debt/ > date created: 2026-06-22 00:00 > > # 🏷️ Title: Technical debt is becoming an AI problem > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [It's time for modern CSS to kill the SPA](https://www.jonoalderson.com/conjecture/its-time-for-modern-css-to-kill-the-spa/) - [Four ways to build a website](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/) - [One website, one CMS](https://www.jonoalderson.com/conjecture/one-website-one-cms/) ## 📝 Summary - **What happened.** Jono Alderson argues that the strategic hand-wringing over new AI standards (llms.txt, WebMCP, Universal Commerce Protocol) is misdirected. The real story these debates expose is whether an organization can adapt to change at all, not which standard to back. - **Why it matters.** He reframes technical debt: it's not primarily a maintenance burden but a measure of how expensive future change has become. Fragmented systems, multiple CMSs, and scattered ownership tax every new opportunity. - **Key stakeholders.** Web/SEO teams, CMS and platform owners, content governance leads, digital strategy and executive decision-makers weighing AI investments. - **Risks and tradeoffs.** Betting on the "right" standard is a losing strategy when standards multiply weekly. Treating adaptation as a one-off project rather than a built-in capability leaves organizations perpetually behind. - **Bottom line.** The advantage belongs to organizations that have made adaptation cheap, not to those who predict winners best. The goal is becoming the kind of organization that no longer needs to care which standard wins. ## 📖 Main Content - **The strategic framing of AI standards is the tell.** Any mention of a new protocol turns immediately into an investment-decision conversation — implement now, wait, or risk backing the wrong horse. Alderson understands the instinct: twenty years of caution taught businesses to observe emerging tech from a distance until a clear winner emerged. - **That caution rested on a now-false assumption.** It worked when web shifts came every few years. The current debate assumes the present is a temporary period of uncertainty that will consolidate back into a familiar, slower pace. Alderson is "increasingly convinced that this assumption is wrong." - **Disruption is not an event; the gaps are shrinking.** Mobile, social, cloud, and AI get talked about as storms that arrived and passed. The deeper pattern is that each wave shortens the distance to the next. Time to absorb change keeps contracting. - **Prediction is the wrong skill.** If interfaces and protocols keep emerging at an accelerating rate, the ability to choose correctly matters less than the ability to respond quickly. The conversation should be about organizational architecture, not standards selection. - **The standards themselves are usually easy.** Exposing information through a feed, endpoint, API, or structured document is rarely the hard part. The difficulty is knowing where information lives, whether it can be trusted, how it's maintained, who owns it, and whether it can be reused without triggering a chain of internal dependencies. - **Redefining technical debt.** Alderson rejects the common framing of debt as a maintenance problem. His reframe: *technical debt is what happens when future change becomes expensive.* A business with six CMSs, fragmented datasets, disconnected workflows, and middleware layers has reduced its capacity to adapt — every opportunity carries a hidden tax. - **The pattern recurs across his career.** It surfaced in SEO (couldn't ship simple recommendations because ownership was fragmented), in migrations (governance and content inventory, not technology, were the real blockers), and now in AI readiness (organizations can't expose information to new systems because they can't expose it to themselves). - **The best-prepared firms aren't "AI-first."** They've quietly spent years reducing complexity — consolidating systems, rationalizing content, improving governance, clarifying ownership. Unglamorous work that determines adaptive speed. - **A widening gap.** Some organizations can treat new standards as experiments (implement, observe, move on); others must treat them as projects (evaluate, prioritize, budget, coordinate, negotiate). The difference is rarely technical capability — it's how expensive change has become. - **The closing reframe.** The advantage belongs to organizations that have made adaptation cheap. If adopting a standard takes six hours instead of six months, uncertainty stops mattering. The important question about llms.txt has nothing to do with llms.txt — it's whether you're ready for the next one next month, and dozens after that. - **Contested/uncertain claims.** The "accelerating pace" thesis is asserted from pattern observation, not measured data. "Adaptation cheap" is presented as nearly always the dominant strategy, which underweights cases where a wrong-but-cheap pivot still incurs real switching and reputational costs. ### 🗒️ Notes - Opening hook: the speed at which AI-standards talk turned *strategic* — every acronym becomes an investment decision. - Named standards: llms.txt, WebMCP, Universal Commerce Protocol — "whichever acronym has emerged this week." - Historical contrast: 20 years of "observe from a distance, wait for the dust to settle." Worked when change came every few years "rather than every few weeks." - Core dissent: the assumption that competing standards will consolidate and the pace will return to familiar is wrong. - Key structural claim: each wave of disruption shortens the distance to the next; time to absorb change has been shrinking for years. - Pivot line: "the conversation stops being about AI standards and starts becoming a conversation about organisational architecture." - The hard part is never the exposure mechanism — it's trust, maintenance, ownership, reuse, and dependency chains. - Thesis sentence (load-bearing): "Technical debt is what happens when future change becomes expensive." - Concrete debt picture: six CMSs, fragmented datasets, disconnected workflows, middleware layers → reduced capacity to adapt + hidden tax on every opportunity. - Three recurrences: SEO ownership fragmentation; migration governance/inventory; AI readiness ("struggle to expose that information to themselves"). - Counter-intuitive: best-prepared firms rarely call themselves AI-first; they did the "unglamorous work of reducing complexity." - The experiments-vs-projects gap framing. - Final aphorism: become "the kind of organisation that no longer needs to care." ## 📚 References - [It's time for modern CSS to kill the SPA — Jono Alderson](https://www.jonoalderson.com/conjecture/its-time-for-modern-css-to-kill-the-spa/) - [Four ways to build a website — Jono Alderson](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/) - [One website, one CMS — Jono Alderson](https://www.jonoalderson.com/conjecture/one-website-one-cms/) - [Source article — Technical debt is becoming an AI problem](https://www.jonoalderson.com/conjecture/technical-debt/) ## 🗣️ Paraphrase - Talk about any new AI standard and people immediately ask whether to invest, wait, or risk backing a loser. That caution made sense for twenty years because the web changed slowly enough to watch and wait. But the assumption that today's churn is temporary, and that things will settle back down, is mistaken. - Disruption isn't a passing storm; each wave arrives faster than the last. So the valuable skill isn't picking the winning standard — it's responding quickly to any of them. Exposing data is easy; knowing where it lives, who owns it, and whether it can be reused is hard. - Technical debt isn't just maintenance overhead. It's what makes future change expensive. Organizations buried in CMSs, fragmented data, and middleware can't adapt; every opportunity costs extra. The firms ready for AI didn't chase it — they spent years reducing complexity. The winners make adaptation cheap, so they no longer need to care which standard wins. ## 📰 Newsletter - WordPress crowd, this one's for you. Jono Alderson (yes, the SEO and web-performance voice many of you know) makes a sharp case that the panic over llms.txt, WebMCP, and the AI-protocol-of-the-week misses the point. The real question isn't which standard to adopt — it's whether your stack can adopt *anything* quickly. - His reframe lands hard for anyone juggling multiple CMSs or a tangle of plugins and middleware: technical debt is what happens when future change becomes expensive. If shipping an llms.txt feels like a six-month project, that's the debt talking. - Practical takeaway for site owners: the "one website, one CMS" discipline, clean content governance, and clear ownership aren't housekeeping — they're what lets you treat the next standard as a six-hour experiment instead of a budget battle. - Worth a read alongside his companion pieces on killing the SPA and the four ways to build a website. Read it: https://www.jonoalderson.com/conjecture/technical-debt/ ## ✅ Action Items #### DevRel - Developer advocacy: frame AI-readiness talks around "make adaptation cheap" rather than "pick the right standard"; demo a six-hour llms.txt implementation on a clean stack vs. a fragmented one. - Education: workshop on content inventory, ownership mapping, and governance as prerequisites for any AI protocol. - Developer experience: ship quickstart templates that expose structured data (feed/endpoint/API) so adoption cost drops to hours. - Developer marketing: content series on "technical debt as adaptation cost," tied to measurable time-to-adopt metrics. - Community management: survey teams on their real time-to-implement for a new standard; surface the experiments-vs-projects gap. - Internal/external/cross-project: align platform owners on shared data-exposure contracts to cut dependency chains. #### OSPO - Policy & Governance: codify data-ownership and reuse policies so new-standard adoption doesn't trigger negotiation chains. - License Compliance: ensure structured-data exports respect content licensing before exposing to AI systems. - Security Management: review trust and provenance of exposed information (the "whether it can be trusted" gap). - Software Inventory: maintain a current system/CMS inventory — the article's "six CMSs" anti-pattern is an SBOM-adjacent visibility problem. - Developer Support: consultation hours on consolidating fragmented platforms. - Community Engagement: coordinate with standards bodies on emerging AI protocols. - Strategic Alignment: report "time-to-adopt a new standard" as a leadership KPI. #### Community - Maintainers: publish governance templates for content ownership and reuse. - Contributors: onboarding paths that teach data-exposure patterns. - Sponsors: fund complexity-reduction work, not just shiny AI features. - Ecosystem: coordinate shared structured-data conventions across projects. #### WordPress - Core: evaluate first-class structured-data/endpoint exposure to lower per-site adoption cost of AI standards. - Core Performance: ensure data-exposure endpoints don't regress performance budgets. - Core AI: build guardrails and evaluation sets for exposing site content to AI agents responsibly. - **Core Program Team:** coordinate cross-team dependencies around AI-readiness features. - Mobile: parity for structured-data exposure in app contexts. - Playground: reproducible demos of llms.txt/WebMCP adoption on clean vs. debt-laden installs. - Community: meetup kits on content governance and the "one website, one CMS" discipline. - Training: lesson path on technical debt as adaptation cost. - Marketing: narrative tying WordPress consolidation to AI-readiness. - Support: knowledge base on cleaning up multi-CMS/middleware sprawl. - Design: UX audit of content-ownership and governance tooling. - Documentation: examples-first guide to exposing structured data. - Photos: taxonomy hygiene as a reuse enabler. - TV: caption and index content for machine reuse. - Polyglots: ensure structured exports cover locale coverage. - Accessibility: confirm exposed data and any UI meet WCAG 2.2 AA. - Meta: API reliability for structured-data endpoints. - CLI: commands to scaffold/expose llms.txt and structured feeds. - Hosting: cross-host defaults that make standard adoption a config flip, not a project. - Tide: score plugins on data-exposure hygiene. - Openverse: provenance and reuse policy for ingested media. - Themes: review for clean, reusable content structures. - Plugins: provenance checks for plugins that expose site data to AI. #### The WPCC - Programs: maintainer stipends for complexity-reduction and governance work. - Projects: documentation sprints on AI-readiness fundamentals. - Funding experiments: matched grants tied to measurable time-to-adopt improvements. ### FAIR - Technical independence: local metadata, provenance, and signature checks on exposed information. - Policies and covenants: transparency on who owns and maintains exposed data. - Productized governance artifacts: ownership charters and reuse scorecards. ## 🧪 Hypotheses - Organizations with lower architectural complexity (fewer CMSs, clearer ownership) adopt new AI standards in measurably less time than fragmented peers. - The pace at which new web/AI standards emerge has accelerated over the last decade (inter-arrival time shrinking). - "AI-readiness" failures correlate more strongly with content governance/ownership gaps than with technical/engineering capability. - Firms that invested in complexity reduction before the AI wave outperform self-described "AI-first" firms on time-to-adopt. - Treating standards as cheap experiments (vs. budgeted projects) predicts more total standards adopted per year. ## 📊 Methodology - **Time-to-adopt study:** instrument a cohort of organizations; measure hours/months from "decide to support standard X" to "live in production," regressed against an architectural-complexity index (CMS count, ownership fragmentation, middleware layers). - **Standards inter-arrival analysis:** build a timeline dataset of major web/AI standards (1995–present); test whether inter-arrival intervals are decreasing. - **AI-readiness audit:** structured assessment separating governance/ownership blockers from engineering blockers; correlate with successful exposure to AI systems. - **Case-control:** compare "AI-first" vs. "complexity-reduction-first" firms on adoption speed and cost. ### ❓ Questions - How do you quantify "adaptation cost" in a way executives can budget against? - At what complexity threshold does a standard flip from experiment to project? - Is there a point where reducing complexity has diminishing returns versus simply building better exposure layers? - Does the accelerating-pace thesis hold across all sectors, or only consumer web? - Who, organizationally, should own "adaptation capability" as a function? ### 🔮 Future Research - A validated architectural-complexity-to-adaptation-cost index. - Empirical measurement of standards inter-arrival times to test the acceleration claim. - Patterns for "exposing information to yourself" — internal data discoverability as an AI-readiness prerequisite. - Governance models that make data reuse default rather than negotiated. ### 💡 Implications - **Practice:** prioritize consolidation, ownership clarity, and content governance over chasing individual standards. - **Policy:** treat adaptation capability as a strategic KPI; budget for complexity reduction. - **Security:** trust/provenance of exposed information becomes a first-class concern as data is opened to AI agents. - **Education:** teach technical debt as adaptation cost, not just maintenance overhead. - **Funding models:** invest in unglamorous infrastructure work that determines adaptive speed. ### 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid Grade ~11–13 (long, subordinate-clause sentences, abstract vocabulary). Flesch Reading Ease estimated ~45–55 (fairly difficult). Formula: Flesch-Kincaid / Flesch Reading Ease, estimated by inspection. #### 👀 Visual learners - Present: one header illustration; no diagrams or charts. - Improve: an "experiments vs. projects" 2x2, a standards-acceleration timeline, a before/after architecture diagram. #### 🔊 Aural learners - Present: none (text-only essay). - Improve: a 3-minute audio summary or TTS narration of the thesis. #### 🗣️ Verbal learners - Present: strong analogies ("storms which arrived"), the "hidden tax" metaphor, clear definitional reframe of technical debt. - Improve: a short glossary (llms.txt, WebMCP, Universal Commerce Protocol, middleware). #### 🧩 Kinesthetic learners - Present: none (no hands-on tasks). - Improve: a self-audit checklist to score your own adaptation cost. #### 🧠 Logical learners - Present: a clear causal chain (complexity → expensive change → reduced adaptability). - Improve: a decision tree for experiment-vs-project; a KPI table for time-to-adopt. #### 🧑‍🤝‍🧑 Social learners - Present: a comments section (0 comments at capture). - Improve: discussion prompts, team-workshop framing. #### 🧘‍♀️ Solitary learners - Present: reflective, essayistic tone suits independent reading. - Improve: journaling prompts ("where does our change get expensive?"). #### 🌿 Naturalistic learners - Present: weather/ecosystem analogies (storms, landscape). - Improve: lifecycle framing of systems and content as an ecosystem to tend. ### 📊 Accessibility Assessment #### Screen reader semantics - Present: single H1, logical heading flow, article landmark (WordPress theme). - Improve: descriptive alt text on the header illustration (currently empty alt). #### Keyboard navigation - Present: standard article + comment form, expected tab order. - Improve: verify visible focus on the comment form fields and submit. #### Contrast and readability - Present: light theme; "color-scheme: only light" declared. - Improve: confirm body text meets 4.5:1; offer a dark-mode option. #### Text resizing and reflow - Present: responsive viewport meta tag set. - Improve: verify no clipping at 200% zoom; respect prefers-reduced-motion. #### Media and captions - Present: no audio/video; not applicable to media captions. - Improve: if an audio version is added, include a transcript. #### Forms and interactions - Present: comment form with Name/Email labels. - Improve: ensure programmatic label association, inline validation, adequate target size. #### Standards reference - Map gaps to WCAG 2.2 AA: 1.1.1 Non-text Content (empty alt), 1.4.3 Contrast, 1.4.10 Reflow, 2.4.7 Focus Visible, 3.3.2 Labels or Instructions. ### 🌍 DEIB Assessment #### Cultural breadth - Present: en-GB locale; generic global business framing. - Improve: examples beyond large enterprises; non-Western or small-org case studies. #### Inclusive language - Present: neutral, professional language; minimal jargon left undefined. - Improve: a plain-language summary; define acronyms on first use for non-specialist readers. #### Neurodiversity support - Present: short paragraphs, consistent structure, predictable flow. - Improve: more frequent subheadings; a TL;DR up top. #### Representation - Present: no named individuals or identities; abstract "organisations." - Improve: varied stakeholder voices (small teams, nonprofits, public sector). #### Psychological safety - Present: respectful, non-blaming framing of past decisions ("largely getting away with it"). - Improve: explicit "this isn't anyone's fault" framing to reduce defensiveness in org-change contexts. ### ✅ Logical Validity #### Strong reasoning - **Causal (strong):** complexity → expensive future change → reduced adaptive capacity. Located in "A business with six content management systems... has reduced its capacity to adapt." Clear mechanism; could be strengthened with measured adoption-time data. - **Inductive (moderate-strong):** the three recurrences (SEO, migrations, AI readiness) generalize to a pattern. Located in "I've seen versions of this problem appear repeatedly." Strengthen with a larger, documented sample. - **Analogical (moderate):** financial-debt analogy reframed as adaptation cost. Effective but, like all analogies, partial — strengthen by noting where the debt metaphor breaks (debt can be "good"/intentional). #### Fallacies - **False dilemma (mild):** "predict winners" vs. "make adaptation cheap" presented as the strategic choice, when both can coexist (you can pick likely winners *and* lower adoption cost). Location: "The future may not belong to the businesses which make the best predictions... Instead, the advantage increasingly seems to belong to organisations which have made adaptation cheap." Fix: acknowledge prediction still has value at the margins. - **Hasty generalization (mild):** the accelerating-pace thesis ("another llms.txt next month... dozens more") is asserted from pattern intuition without data. Fix: cite inter-arrival measurements or hedge the rate claim. - **Anecdotal evidence (mild):** career recurrences support a broad claim. Fix: supplement with quantitative or third-party evidence. #### Tone of voice - Measured, reflective, persuasive-essay register. Hedged with "I'm increasingly convinced," "I suspect," "seems" — signals intellectual honesty rather than overclaiming. Example: "I'm increasingly convinced that this assumption is wrong." ### 🛡️ DARVO Analysis - Not applicable to this source. Reason: the piece is a strategic opinion essay with no accuser/accused dynamic; it critiques an industry tendency without deflecting blame, attacking individuals, or reversing victim/offender roles. ## 🎯 Conclusion - **Bottom line.** Technical debt is best understood as the cost of future change. In a world where AI standards multiply faster than anyone can evaluate them, the winning capability is cheap adaptation, not accurate prediction. - **Next steps for readers.** Audit your own adaptation cost: count your CMSs and data silos, map content ownership, and time how long a simple new standard would actually take to ship. Invest in the unglamorous consolidation and governance work that turns six-month projects into six-hour experiments — so you can stop caring which standard wins. ## 🔄 Refactor Appendix — Technical debt is becoming an AI problem > Density: 2–5 Literature atoms (H3), 0–3 Permanent candidates (H4). > Defaults: 3 Literature, 1 Permanent. Resonance filter: if you can't > articulate in one line why a claim matters, drop it. > > Konik claim-header rules: present tense, declarative, ≤10 words when > possible, searchable, unique, mirrors annotation focus if present. > > Atomicity: one declarative sentence per atom. "and"/"also" → split. > > Tag pool: #bmf · #addendum · #xref · #articleseed · #storystem · #share · #aphorisms ### 📚 Literature Atoms (H3) #### [H1] Technical debt is the cost of future change > [!quote] ID:rw_manual_1 > Technical debt is what happens when future change becomes expensive. **Context & use**: - Mid-article thesis sentence, standalone paragraph. - Reframes debt from maintenance overhead to adaptive-capacity loss; the load-bearing idea of the whole piece. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H2] Adaptation speed beats standard prediction > [!quote] ID:rw_manual_2 > the ability to choose correctly becomes less valuable than the ability to respond quickly. **Context & use**: - Early-article pivot from prediction to organizational architecture. - Core strategic claim: optimize for response time, not forecasting. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H3] Exposing data internally is the real blocker > [!quote] ID:rw_manual_3 > exposing information to new systems is surprisingly difficult because they struggle to expose that information to themselves. **Context & use**: - AI-readiness recurrence paragraph. - The hard part is internal discoverability/ownership, not the exposure mechanism. **Tags**: #xref **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> #### [H4] Make adaptation cheap, not predictions accurate > [!quote] ID:rw_manual_4 > the advantage increasingly seems to belong to organisations which have made adaptation cheap. **Context & use**: - Penultimate section conclusion. - The prescriptive payoff: cheap adaptation dissolves the standards-betting problem. **Tags**: #xref #aphorisms **Highlight**: [view highlight](readwise://) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] Adaptation cost is the true measure of technical debt **Claim** (one sentence, Courtney's voice): Technical debt should be measured by how expensive it makes your next change, not by how much your current systems cost to maintain. **Evidence pointer**: [[#H1]] **Scope & conditions**: Holds when an organization faces continuous external change (e.g., proliferating AI standards); weaker when the environment is genuinely stable and change is rare. **Links**: - [[Organizational adaptability]] — because extends - [[Maintenance-cost view of tech debt]] — because contrasts on what debt measures - [[AI readiness]] — because applies-in standards adoption <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Test the acceleration claim: build a standards inter-arrival timeline (1995–present) — does the gap actually shrink? #fleeting #inbox - [F2] Draft a self-audit checklist scoring an org's "adaptation cost" (CMS count, ownership map, time-to-ship a simple standard). #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Map content ownership and CMS count for one client as an adaptation-cost baseline — research #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/Technical Debt Is Becoming an AI Problem.md|Technical Debt Is Becoming an AI Problem by jonoalderson.com]] ## Highlights - That makes the current debate around AI protocols feel slightly odd, because so much of it is focused on prediction. People are trying to determine which standards deserve investment, when the more important question might be whether their organisations are capable of adapting to any of them. If new interfaces, protocols and mechanisms for exchanging information continue to emerge at an accelerating rate, then the ability to choose correctly becomes less valuable than the ability to respond quickly. ([View Highlight](https://read.readwise.io/read/01kvqppef3cq4xtf7gyay482h9)) - Note: Speed beats prediction as strategy - Tags: atom/literature/h2 - Technical debt is what happens when future change becomes expensive. ([View Highlight](https://read.readwise.io/read/01kvqppcxjcqd2343w5nhnweh3)) - Note: Reframes debt as adaptation cost - Tags: atom/literature/h1 - The future may not belong to the businesses which make the best predictions about emerging technologies. There are simply too many technologies, too many standards, and too many moving parts for prediction to remain a reliable strategy. Instead, the advantage increasingly seems to belong to organisations which have made adaptation cheap. ([View Highlight](https://read.readwise.io/read/01kvqppgxje4q7n2cvmmmpeahr)) - Note: Cheap adaptation wins - Tags: atom/literature/h2