Large language models are language, not computer science

We filed them under the wrong discipline. The clue is in the name we gave the machine — *computer* — and computers are the province of computer science, so that is where we shelved the large language model, next to the compilers and the sorting algorithms. It was a reasonable mistake. It is still a mistake.

What a language model actually does is the oldest and least computational thing we know how to do: it reads, and it answers. Not by looking anything up, not by executing a rule, but the way a well-read person answers — from everything it has ever seen, weighted by what your sentence seems to mean. That is not computation in the sense the engineers mean it. It is closer to interpretation. It lives where language lives: in context, in implication, in the gap between what was said and what was meant.

Computer science has a beautiful map of formal languages — Chomsky's hierarchy. At the bottom, the simplest kind: the Type-3, the regular grammar, the finite automaton. Give it a symbol, it changes state, it hands you the next symbol. No memory to speak of, no sense of the whole, no ambiguity permitted. It is the grammar of a turnstile, a vending machine, a regular expression. It is wonderfully predictable, and you can prove things about it, and that is exactly why an engineer loves it.

So the temptation, when a language model lands on the engineer's desk, is to treat it like one of these. To pin it down. To write the prompt as if it were a switch statement, to demand the same output every time for the same input, to file a bug when it interprets rather than obeys. To cage a Type-0 creature — a thing that swims in the whole sea of language — inside a Type-3 box, and then be disappointed that it has stopped doing magic.

It has stopped doing magic because you asked it to stop. The interpretive faculty — the part that reads your half-formed question and answers the better question underneath it — is the same faculty that refuses to be perfectly deterministic. You cannot keep the one and discard the other. Strip the ambiguity and you are left with a slower, more expensive, less reliable regular expression. We have had regular expressions since 1956. They are not what is new here.

What is new is that, for the first time, a machine meets us in our register instead of demanding we descend into its. So meet it there. Ask the way you would ask a thoughtful colleague, not the way you would address a parser. Give it the context a human would need, and leave it room to read between your lines. Verify its work the way an editor checks a draft — for sense, for truth, for the thing that is subtly wrong — not the way a compiler checks syntax. And keep a person in the loop, because the final judgement about meaning has always been, and remains, a human one.

I am a writer by passion and a craftsman by conviction, and I have spent my life on the unglamorous truth that the tool you misunderstand will punish you for it. Treat the language model as computer science and it will behave like bad computer science: brittle, literal, faintly stupid. Treat it as language — vast, contextual, alive to nuance — and it stays what it actually is. The magic was never in the computation. It was in the language all along.