Technical debt is becoming an AI problem
22nd June, 2026
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. Complex architectures create operational overhead. Multiple CMSs introduce inefficiencies. 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.