The words AI, machine learning, deep learning, generative AI and LLM are often used as if they meant the same thing. They do not: each one is a narrower kind of the one before it. Getting this ladder straight removes most of the confusion in later chapters.

A token is the unit of text a model reads and writes. It is often a word, part of a word, or a punctuation mark. Anthropic describes a model's context as the set of tokens it is given when it generates a response, so every piece of information the model receives is counted in tokens.

The model's one job is: given the tokens so far, choose a likely next token. It appends that token and repeats. A paragraph, a SQL query or a Java class all come out of this same loop.

The program below is not an LLM. It is a deliberately tiny stand-in that shows the same two phases: it learns which word tends to follow which from a small text, then generates new text one word at a time. A real LLM replaces the lookup table with a neural network that considers far more than the previous word, but the loop is the same shape.

• Learning: after "the" the text contained cat twice and dog, fish, log, mat once each, so those counts are the model's whole "knowledge" of what follows "the".
• Generating: each new word was drawn at random in proportion to those counts. "cat" is the most probable next word after "the" but not the only one, which is why three runs differ.
• Fluent but shallow: the samples look grammatical because the training text was, yet "the dog sat on the cat sat on" means nothing. Looking only one word back is too little context; modern LLMs look at a very large window of preceding text.

Every model lives through two very different phases. Training is the expensive, one-time (per model version) process in which the model's internal numbers are adjusted so its predictions match large amounts of text. Inference is what happens every time you use it: those numbers are now fixed, and the model simply generates a response to your input.

Two practical consequences follow directly:

• The model has a knowledge cutoff. Anthropic lists a "reliable knowledge cutoff" per model; the current Claude 5.5 models list June 2026 (see the model table in Source 1). Anything newer — a library release, an API change — is unknown unless you supply it.
• Using the model does not teach it your code. The model's numbers stay fixed during a session. Your project knowledge reaches it only through the text you give it, which is the subject of the next section.

The context window is everything the model can look at when it produces a reply. Anthropic's documentation calls it the model's "working memory": it holds the system prompt, every earlier message, tool results, attached files and the reply being generated.

As of the date at the top, the Claude models Fable 5.1, Opus 5.5, Sonnet 5.5 and Haiku 5.5 each list a 1M-token context window and up to 128K tokens of output (Source 1). Anthropic's note on its current tokenizer gives a feel for scale: 1M tokens is roughly 555 thousand words, whereas models before it fit about 750 thousand words in the same 1M tokens. The same text can cost a different number of tokens on a different model, so token counts are model-specific.

Anthropic states that as the token count grows, accuracy and recall degrade, a phenomenon it calls context rot, and that curating what is in the context matters as much as how much room exists (Source 2). Its engineering article describes this as a finite attention budget: each added token uses up some of it. The recommended goal is the smallest set of high-signal tokens that makes the desired result likely.

A hallucination is output that is fluent and confident but factually wrong or inconsistent with the context you gave. Anthropic's guide says plainly that even the most advanced models, Claude included, can produce such text (Source 3).

The reason follows from the mechanism in Chapter 2. The model produces the most plausible continuation; it is not looking facts up in a database and checking them. A plausible-sounding method name or library flag is exactly what a text predictor is good at producing, whether or not it exists.

Several properties of programming line up with what a language model does. These are explanations of fit, not performance claims; this page makes no benchmark claims.

• Code is text. Source files, build output, logs and commit messages are all sequences of tokens the model can read and write.
• Conventions are strong. Frameworks such as Spring Boot repeat patterns heavily, and predicting the next plausible line works well where the pattern is regular.
• Answers can be checked mechanically. A compiler, a linter or a test suite can reject a wrong guess immediately. That feedback is what turns a text generator into a useful agent in Chapter 3.
• Intent is expressed in words. Requirements, tickets and review comments are natural language, which is the model's native input.

The flip side is the same mechanism: where conventions are weak, requirements are ambiguous, or a fact is newer than the model's cutoff, plausible-but-wrong output becomes more likely. Your engineering judgement is still the final check.