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 > ## 🧭 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  One of the more interesting things about the current wave of AI standards is how quickly the conversation around them has become strategic. Mention llms.txt, WebMCP, Universal Commerce Protocol, or whichever acronym has emerged this week, and the discussion almost immediately turns to investment decisions. Should we implement this? Should we wait? Is it worth the effort? What happens if we back the wrong horse? I understand the instinct. Most businesses have spent the last twenty years learning to be cautious around emerging technologies. New standards have traditionally arrived slowly enough that organisations could afford to observe from a distance, wait for the dust to settle, and only commit resources once a clear winner emerged. That approach worked reasonably well when meaningful shifts in the web ecosystem happened every few years rather than every few weeks. What strikes me, though, is how much of the current discussion assumes that we’re living through a temporary period of uncertainty. The underlying belief seems to be that, sooner or later, these competing standards will consolidate, the market will settle down, and we’ll return to a more familiar pace of change. Businesses simply need to identify the winners and position themselves accordingly. I’m increasingly convinced that this assumption is wrong. The web industry has a habit of viewing technological disruption as an event. We talk about mobile, social media, cloud computing and AI as though they were storms which arrived, changed the landscape, and eventually passed. Looking back, however, the more significant pattern is that each wave of disruption has shortened the distance between the next one. The time available to absorb change has been shrinking for years. 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. Viewed through that lens, the conversation stops being about AI standards and starts becoming a conversation about organisational architecture. After all, most of these standards are not especially complicated. Exposing information through a feed, an endpoint, an API or a structured document is rarely the difficult part. The challenge usually lies elsewhere. The challenge is understanding where information lives, whether it can be trusted, how it is maintained, who owns it, and whether it can be reused without triggering a lengthy chain of internal dependencies. That’s why I’ve become increasingly sceptical of the way technical debt is often discussed. We tend to frame it as a maintenance problem. [Legacy systems are expensive to run](https://www.jonoalderson.com/conjecture/its-time-for-modern-css-to-kill-the-spa/). [Complex architectures create operational overhead](https://www.jonoalderson.com/conjecture/four-ways-to-build-a-website/). [Multiple CMSs introduce inefficiencies](https://www.jonoalderson.com/conjecture/one-website-one-cms/). Whilst all of those things are true, they arguably miss the more important consequence. Technical debt is what happens when future change becomes expensive. A business with six content management systems, fragmented datasets, disconnected workflows and layers of middleware doesn’t merely have a maintenance burden. It has reduced its capacity to adapt. Every new opportunity arrives carrying a hidden tax, because the organisation must first untangle its own complexity before it can respond to the outside world. I’ve seen versions of this problem appear repeatedly over the years. Sometimes it surfaced through SEO, when a business couldn’t implement relatively straightforward technical recommendations because ownership was fragmented across teams and platforms. Sometimes it appeared during website migrations, where the biggest challenges turned out to be governance and content inventory rather than technology. More recently, I’ve seen it emerge through discussions around AI readiness, where organisations discover that exposing information to new systems is surprisingly difficult because they struggle to expose that information to themselves. What’s particularly interesting is that the businesses which seem best prepared for the current moment rarely describe themselves as AI-first organisations. In many cases, they’ve simply spent years doing the unglamorous work of reducing complexity. They’ve consolidated systems, rationalised content, improved governance, clarified ownership, and invested in architectures which make information easier to access and reuse. None of that sounds especially exciting when compared to launching new AI products or publishing ambitious transformation strategies. Yet those investments often determine whether a business can adapt quickly when circumstances change. The result is a widening gap between organisations which can treat new standards as experiments and those which must treat them as projects. One group can implement support, observe what happens, and move on. The other must evaluate, prioritise, budget, coordinate and negotiate before any meaningful work begins. The difference is rarely a question of technical capability. More often, it’s a reflection of how expensive change has become. That’s why I find the current obsession with AI standards so revealing. Not because I think llms.txt is particularly important, or because I have strong opinions about which protocol will eventually dominate. The interesting thing is what these conversations expose about the organisations having them. For years, businesses have been accumulating complexity whilst largely getting away with it. The web moved slowly enough that inefficiencies could be tolerated, technical debt could be deferred, and fragmented ecosystems could continue functioning. What we’re beginning to discover is that those decisions have consequences in a world where new opportunities emerge continuously. 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. That feels like a subtle distinction, but it changes almost everything. If adopting a new standard takes six months, you need confidence that it’s worth doing. If adopting it takes six hours, uncertainty becomes much less of a concern. At that point, success depends less on forecasting the future and more on building systems, processes and organisations capable of responding when the future arrives. Which is why I suspect that the most important question raised by llms.txt has very little to do with llms.txt itself. The more useful question is whether your organisation is prepared for a future in which there will be another llms.txt next month, another the month after that, and dozens more after that. Because if the pace of change continues to accelerate, the challenge won’t be deciding which standards matter. The challenge will be becoming the kind of organisation that no longer needs to care., Technical Debt Is Becoming an AI Problem, jonoalderson.com, 01kvqp2fsde4apd3ett2mss3sb.