Pylimitics

Metaphors are a tool for easily understanding and explaining something. They’re comparisons. If you say “the AI industry is a house of cards,” anybody who shares enough experience and language with you knows you’re saying the AI industry is fragile and could collapse at any moment. The Metaphors We Live By, a 1980 book by George Lakoff and Mark Johnson, is an excellent discussion of how much we use metaphors.

The facility people have with metaphors, and the difficulty we have trying to avoid them, explain the popularity of large language models. Before LLMs, trying to use metaphors to interact with computer systems wouldn’t work. With very few exceptions, the deterministic matching systems instantiated in software did not include metaphorical connections, not even in their keywords. Metaphors are bigger than keywords. It can take paragraphs to explain one. Entire novels and movies can themselves be metaphors.

LLMs, though, are giant documents that contain human linguistic content, and humans, as Lakoff and Johnson show, think and express themselves in metaphors. If you type “the AI industry is a house of cards” to Claude or ChatGPT, you’ll see the results of a nondeterministic matching system respond to the metaphor rather than the specific words. LLMs contain the contexts expressed by people.

“Technical debt” is a familiar and useful metaphor you’ll frequently find in discussions of software development. It’s a great metaphor. It neatly encapsulates the situation where you’re creating some new software system, and you have the choice of solving a problem in a way that will work for now, but will need to be revised later. By the way, the term “technical debt” was coined in 1992 by Ward Cunningham (who invented wiki software), after he read Metaphors We Live By.

The current generation of “artificial intelligence” software, which is dominated by large language models, has a complex intersection with the metaphor of debt. “Technical debt” in software development is generally understood as a significant problem. Solving development problems quickly but incompletely will eventually show up as system defects and failures. By then, the software will have expanded, sometimes enormously, and so will the complications and dependencies. So solving your technical debt later on can be expensive, difficult, and maybe even impossible. But LLM coding agents are turning out to maybe change that calculation. Reviewing thousands of lines of code is a task a coding agent can perform, so ferreting out and correcting long-standing technical debt in software might be much more feasible going forward.

Another aspect of AI, in this case the vendors rather than the software itself, is financial debt. Most of the LLMs from the big US vendors require unprecedentedly enormous data centers and super-expensive processors, and that’s required the companies to take on astonishing levels of debt. There is plenty of speculation about this, but because the companies are not yet public, nobody outside their core investors really knows very much about where the money is, where it’s going, and what their paths to profitability are going to be.

There is yet another aspect of the metaphor of debt around AI. I haven’t seen this one discussed very much, and it doesn’t yet have a handy moniker, so I’m calling it, somewhat clumsily, information complexity debt.

When you direct an LLM to generate informational text, whether it’s a README file explaining a piece of code, an analysis, a report, or the like, what you get is almost always quite long, quite wordy, and (arguably) overly detailed. It often includes errors and confabulations as well (which a number of lawyers have already discovered, to their chagrin). In a word, or perhaps a pair of them, LLM-generated content is too complicated.

Among other things, I’ve worked as a technical writer, an interaction designer, and an educator (“instructional designer”). Those fields are intended to bolster human understanding. When you’re doing that it’s important to simplify. You’re trying to help someone understand something or complete a task, and they need to focus on the subject, not on your presentation. The simpler you can make it (without omitting crucial details), the better. When documentation, tutorials, and really any information is overly complicated, it means that at some point somebody is going to have to simplify it; either for themselves or for everybody. Putting off a costly operation is a form of debt. The more LLM-generated content we have, the more information complexity debt we’re going to have to eventually deal with. The AI industry is maybe a house of cards. But it’s definitely a mansion of metaphor.