A language model is extraordinarily capable within its domain. Outside that domain, it ranges from unreliable to actively misleading — not because it's broken, but because it was never designed for those tasks. Understanding the boundary is as important as understanding the capability.
Everything a text language model can do flows from one thing it was trained to do: predict the next token in a sequence of human-generated text.
That single training objective, applied at enormous scale, produces a model that is genuinely impressive at a wide range of tasks — because a staggering amount of human knowledge and capability is embedded in text. But the key word is text. The model optimized for patterns in language. Its strengths are exactly where language is the natural medium.
Where language is not the natural medium — where the underlying task involves pixel values, audio frequencies, numerical time series, deterministic logic, or structured databases — the model is working outside its optimization target. It may appear capable. It is often not reliable. And it almost never knows the difference.
When your only tool is a hammer, everything looks like a nail. When your only AI is a text model, every problem looks like a language problem. Some of them are. Many of them aren't. The skill is knowing which is which before you invest in the wrong solution.
Text models are the right tool when the task is fundamentally about language — generating it, understanding it, transforming it, or reasoning through it.
Writing, drafting, summarizing, translating, reformatting. The model's core capability. Given clear context and constraints, the output quality can be remarkably high. The task is precisely what it was trained for.
Reading a document and pulling out specific information. Classifying text by topic or sentiment. Identifying entities — names, dates, locations — within unstructured text. These are pattern-matching tasks over language that the model handles well.
Working through problems that can be fully expressed in language: explaining a concept, comparing options described in words, walking through a logical argument. The chain-of-thought technique works here because the reasoning itself is linguistic — each step is a sentence that sets up the next.
Code is text with very precise syntactic rules. The model was trained on enormous quantities of it. Within well-understood languages and patterns, code generation is one of the strongest practical use cases. The caveats — logic errors, hallucinated APIs, outdated library knowledge — all trace back to the limits of pattern matching rather than genuine compilation and testing.
Notice what all the strengths have in common: the task input and output are text, and "correct" is defined by whether a knowledgeable human would find the output appropriate. The model is, at its core, a very sophisticated simulator of human text production. When that's what you need, it's hard to beat. When that's not what you need, you're using the wrong tool.
Before reaching for a text model, ask: could a knowledgeable human do this task by reading and writing alone, without access to calculators, databases, sensors, or specialized software? If yes, a text model is probably appropriate. If no — if the task inherently requires computation, real-time data, structured queries, or non-text modalities — the text model is at best a front-end to other systems, not the solution itself.
List five tasks you've tried or considered using an AI for. For each one: is the task fundamentally about language, or does it require something beyond language — precise computation, real data, non-text modalities? Which ones are a natural fit for a text model, and which ones would need something else?