What Is an LLM?

A large language model takes text and produces the next piece of text, over and over, one piece at a time. It was trained by being shown an enormous quantity of writing with parts hidden, and adjusted until its guesses about the hidden parts got good. That's the whole trick, and every capability and failure comes out of it.

This sounds too simple to explain what these systems do. But predicting the next word well, across every kind of writing, requires representing an extraordinary amount about how language, arguments, code, and facts fit together. Capability is a side effect of doing prediction properly at scale.

Models don't read characters or words — they read tokens, chunks of a few characters each. "Learning" might be one token; an unusual name might be four. As a rough guide, a token averages around three-quarters of an English word.

Two consequences worth knowing. Pricing is per token, so cost is roughly proportional to text length in and out. And each model has a context window — the maximum tokens it can hold at once, covering your prompt, any documents you paste, and its own reply.

Every row on the right follows from the same fact: the model is producing plausible text, not consulting anything. Arithmetic fails because a correct sum and a plausible-looking sum are different targets. Recent events fail because they weren't in the training data. Private systems fail for the same reason.

A fabricated answer is usually called a hallucination, which makes it sound like a malfunction. It isn't. The model is doing exactly what it does at all times — producing likely-looking text. A citation that doesn't exist looks precisely like a citation that does, from the inside of the mechanism.

Worse, confidence is a property of the writing style, not of the model's certainty. Text that hedges is trained on text that hedges. A wrong answer delivered in the register of a textbook is the default output, not a warning sign.

• Give it the source material instead of relying on recall — pasted documents are checkable, memory isn't
• Ask for the reasoning, then check the reasoning rather than the conclusion
• Never accept a fact you can't verify in a domain where being wrong is expensive
• Treat named citations, statistics, and API signatures as unverified until checked

1. 01Supply context rather than assuming knowledgePaste the actual file, the actual error, the actual document. Almost every bad answer traces to missing context.
2. 02Say what the output should look likeFormat, length, audience. Ambiguity gets filled with the most average possible choice.
3. 03Ask for options, not one answerThree approaches with trade-offs is a far better use of the tool than one confident recommendation.
4. 04Verify anything that would be costly to get wrongRun the code. Check the citation. The verification step is not optional, it's part of the workflow.