How LLMs Work - for Designers

Here is the whole thing in a sentence: a large language model reads the text so far and predicts the most likely next chunk of text, then does it again, and again, until it has written a full answer. That is it. It is a spectacularly good autocomplete.

The chunks are called tokens - roughly a word or a piece of a word (day, light, ##ing). When you ask "a good rule of thumb for corridor width is...", the model is not consulting a rulebook. It is computing, from everything it has seen, which token most plausibly comes next - probably a number, probably in millimetres - and emitting it, then predicting the token after that, conditioned on what it just wrote.

This explains the model's superpower and its central flaw at the same time. Because it has read an enormous amount of human writing, its predictions are usually fluent, coherent and often correct. But it is optimising for plausible-sounding, not for true. A confident, well-formed, completely wrong answer is not a malfunction - it is the same machinery working exactly as designed on a case where the plausible token was not the correct one. Hold onto that: fluency is guaranteed; truth is not.

There is also a dial called temperature that controls how adventurously it picks among likely next tokens. Low temperature makes it pick the safest, most predictable word (good for factual, repeatable tasks); higher temperature lets it wander (useful when you want surprising ideas). You rarely set this by hand in a chat app, but it is why the same prompt gives slightly different answers each time.

The model got good at prediction through training on a colossal amount of text - books, code, websites, documentation, forums. During training it adjusted billions of internal numbers (its parameters, or weights) so that its next-token guesses matched the real text better and better. Nothing is stored as facts you can look up; the 'knowledge' is smeared across those weights as statistical patterns. That is why it cannot cite a source it 'read' - it did not file anything; it absorbed regularities.

Two consequences matter for you. First, a knowledge cutoff: a base model only knows the world up to when its training data ends, so it is stale on anything recent unless the app adds live search or you paste the current information in. Second, the training set shapes its instincts - it reflects what is common in its data, which skews toward well-documented, English-language, Western-defaulting material. Ask for 'a typical house plan' and you may get a suburban American one unless you specify India, a hot-dry climate, a joint family, and so on.

After raw training, models are fine-tuned and aligned to be helpful, follow instructions and stay safe - this is the step that turns a raw text-predictor into a usable assistant. It is also why models have personalities and house styles, and why they sometimes refuse, hedge, or default to bland, list-heavy prose you then have to push past.

Everything the model can 'see' at once - your instructions, the conversation so far, any files you paste, and the answer it is writing - has to fit inside a context window, measured in tokens. Modern assistants have large windows (tens to hundreds of thousands of tokens, enough for a long report or several documents), but it is still finite, and it behaves like short-term memory, not permanent memory.

Three practical rules fall out of this. One: it forgets. In a very long chat, early instructions can slide out of the window or get diluted; if the model starts ignoring a rule you set an hour ago, restate it. Two: what is in the window dominates. If you paste the actual code clause, the real product datasheet, or three precedent descriptions, the model reasons over that - far more reliably than over its fuzzy trained memory. This is the single biggest quality lever you control, and the whole idea behind retrieval-augmented generation (RAG): put the right facts in front of it. Three: position matters. Models attend best to the start and end of the window, so put your most important instruction or the key document where it will not get lost in the middle of a huge paste.

For a designer, the takeaway is blunt: do not rely on the model's memory for anything that must be right. Feed it the source, and it becomes a careful reader of your material instead of a confident guesser from its own.

Ungrounded (guesses from fuzzy memory):
  "What is the minimum clear width for an accessible ramp?"

Grounded (reasons over what you gave it):
  "Here is the accessibility clause from our project code [pasted].
   Using ONLY this text, tell me the minimum clear ramp width and
   the maximum gradient, and quote the exact line you used."

The picture so far - a lone text-predictor - is the base case, but the assistants you actually use in 2026 have several things bolted on top, and knowing them sharpens your instinct for when to trust the answer. Reasoning modes let a model 'think' before it replies - it generates a hidden chain of intermediate steps, which markedly improves maths, logic, multi-step problems and careful analysis. It is still prediction underneath, so it can still be wrong, but a reasoning model working step by step is more reliable on anything with moving parts than a model blurting the first plausible answer. Many assistants let you turn this on for hard problems and off for quick ones.

Tool use breaks the model out of its own head. A modern assistant can call a web search, run code, read a file you uploaded, or query a database, then fold the result back into its answer. This is how the knowledge-cutoff and hallucination problems get patched in practice: instead of guessing a current figure from stale memory, the model fetches it and reasons over the real thing. When an assistant cites a live source or runs a calculation you can inspect, you are on far firmer ground than when it answers from raw memory alone.

The umbrella idea is grounding - anchoring the model's output in real, retrievable material rather than its blurry internal patterns. Retrieval-augmented generation (RAG) is the formal version: the system finds the relevant documents and puts them in the context window before the model answers, so the reply is built from actual sources. You do the manual version every time you paste a brief or a code clause. The practical rule for a designer: an ungrounded answer is an informed guess; a grounded one, with a source you can check, is something you can lean on. Prefer grounded whenever the stakes are real, and treat the presence or absence of a checkable source as your first signal of how hard to verify.

A hallucination is when the model states something false as if it were true - a made-up IS code number, a fabricated citation, a product that does not exist, a plausible-but-wrong load figure. Now you can see exactly why it happens: the model is always predicting the next plausible token, and when it has no good pattern for the truth (an obscure clause, a very recent event, a specific dimension), the plausible token is not the correct one - but it emits it anyway, with the same confident fluency as everything else. It has no built-in signal that says 'I am unsure here.'

This is not a bug they will fully patch away; it is intrinsic to how the technology works. So your job is to work with it. Three habits carry you a long way. Verify anything that must be correct - numbers, codes, standards, citations, names - against a real source; treat the model's version as a lead, not a fact. Ground it with sources - paste the real document and ask it to answer only from that, and it hallucinates far less. Ask it to flag uncertainty - a simple "mark anything you are not confident about" often surfaces the shaky parts, though it is not foolproof.

The rule from Module 0 returns here in concrete form: scrutiny scales with stakes. Brainstorming ten concept directions? Hallucination barely matters - you are curating anyway. Quoting a fire-egress width that goes into a drawing? Verify every digit. The model is a brilliant, fast, well-read assistant that will occasionally lie to you with a straight face. Used with that expectation, it is enormously useful. Trusted blindly, it is a liability.