To work with AI meaningfully — to give it tasks, to trust or distrust its output, to know where it will fail — you need to understand what's happening under the hood. Not the math, but the behavior model. A large language model (LLM) is simpler than it seems, and that simplicity explains almost all of its strengths and weaknesses.
The key thing to internalize: the model doesn't think and doesn't know — it predicts. Everything else follows from that.
The model predicts the next token
At the core of an LLM is one operation: given the text so far, predict what fragment comes next. That fragment is a token (roughly part of a word). The model looks at all the text in front of it and outputs probabilities: which token is most plausible next.
"The capital of France is " → the model decides "Paris" is highly likely next. It appends it, then repeats the process with the new text, token by token. That's how an answer is born — not as a finished thought, but as a chain of plausible continuations.
An important consequence: the model produces what looks true in form, not what has been verified as true. Usually these coincide — but not always, and that's the root of hallucinations.
Where its "knowledge" comes from
The model was trained on a huge volume of text — books, code, articles, forums. In the process it tuned billions of internal parameters to predict continuations well on that data. Statistical regularities of language got "compressed" into the parameters: grammar, facts, styles, code patterns.
So the model:
- Reproduces what appeared often in training very well: typical code, common facts, standard phrasing.
- Is worse with the rare and new: niche libraries, fresh versions, the specifics of your project — there was little or none of that in the data.
- Doesn't know what wasn't in training: events after its training cutoff, your internal code, private documents — until you give them in context yourself.
Why it's so good at language and code
Language and code are structures with strong regularities. Much in them is predictable: an open bracket is usually followed by a closing one, a function signature by a body in a certain style, a "try" by a "catch". A model trained to predict catches these regularities very well. That's why it fluently produces syntactically valid code and coherent text.
But the same nature explains its limit: the model is good at what looks right. Looks right and works right are different things. Code can compile, be in perfect style, and contain a logic error — because the model is optimized for plausibility, not correctness.
It has no understanding in the human sense
The model has no intentions, beliefs, or world model like a human. It doesn't "understand" a task — it continues text the way people in the training data would have. This doesn't make it useless (quite the opposite), but it sets the right expectations:
- It sounds confident whether it's right or wrong — tone is not a signal of truth.
- It doesn't check itself by default — unless you ask and provide tools.
- It's sensitive to phrasing: however the question is framed, it continues accordingly.
Understanding this isn't a reason to distrust AI — it's a reason to set up the work correctly: give a clear input, verify the output, and don't take a confident tone as a guarantee.
What this means in practice
An AI model is a very powerful text predictor, not an oracle or a fellow engineer. All the product engineer's further work with AI flows from this: the more precise the input and context, the better the output; a confident answer needs verifying; the rare and specific should be supplied, not left for the model to guess.
What's next
This picture explains the model's other properties. Work through them one by one: why the model makes up facts, what tokens are and how cost is calculated, why context matters, how the model calls tools, and what agents are.