Prompt Engineering 101

This post traces what actually happens to your prompt so the techniques stop feeling like folklore. The payoff is that once you understand conditioning, the context window, and structure, every named technique — few-shot, chain-of-thought, delimiters — turns out to be an obvious consequence of how the model works. The cover frames the whole post as seeing the machine behind the words.

The first mechanic is conditioning. The model reads your entire prompt and computes a probability distribution over the next token, conditioned on every token that came before. There is no separate stage where it "understands" you and then decides — the prompt directly shapes the distribution from which the next token is drawn.

This explains why specificity works. Adding relevant, concrete context shifts probability mass toward the continuation you want, because that context makes your desired answer the statistically likely next thing to say. Vague prompts leave the distribution broad and the output wanders; precise prompts narrow it. Every technique in this post is ultimately a way of reshaping that distribution.

The pipeline diagram lays out the journey of your prompt: the text is tokenized into integer ids, a forward pass through the network produces probabilities for the next token, the sampler picks one, and the loop repeats, each new token appended to the input for the next step. The reply is built one token at a time, never all at once.

Seeing these stages explicitly demystifies behavior that otherwise looks arbitrary. Output randomness comes from the sampling stage. Cost comes from the token counts at the ends. The fact that the model can be steered at all comes from the conditioning at the forward-pass stage. Each technique you'll learn intervenes at the input, which is the only stage you control.

This contrasts zero-shot and few-shot prompting. Zero-shot is a bare instruction with no examples. Few-shot embeds several worked input-to-output pairs directly in the prompt. Because the model is a pattern continuer, showing it three examples of the exact format you want makes continuing that pattern the most likely next move — so it produces a fourth answer in the same shape.

The reason examples often beat explanation is mechanical: an example demonstrates the target distribution directly, while a prose description only points at it. Telling the model "be concise and structured" is weaker than showing two concise, structured answers, because the examples literally shift the probabilities toward that form. This is why few-shot is one of the highest-return techniques you can apply.

The code shows few-shot for sentiment classification. Three labeled examples establish the pattern — a review followed by an arrow and a label — and then a fourth review is presented with the arrow but no label. The model, having seen the pattern three times, overwhelmingly continues it by emitting the correct label.

Notice there is no instruction explaining what "POS" or "NEG" means; the examples carry the entire specification. That is the power and the trap of few-shot: the examples must be correct and representative, because the model imitates them faithfully, including any mistakes or biases they contain. Well-chosen examples are doing real work here, not decoration.

This explains why "think step by step" improves accuracy on hard problems. Because every token is conditioned on the tokens before it, letting the model write out intermediate reasoning gives the later tokens — including the final answer — better material to build on. The model effectively uses its own generated text as a scratchpad.

The trade is explicit: you spend extra output tokens on the reasoning in exchange for substantially higher accuracy on multi-step tasks like arithmetic, logic, and planning. It is not magic; it is giving the model room to compute incrementally instead of forcing a single leap to the answer. For simple lookups it adds cost with no benefit, so it's a technique to apply where the task actually has steps.

The code shows a chain-of-thought prompt that stays parseable. It poses a multi-step arithmetic problem, asks the model to think step by step, and then — crucially — instructs it to put the final answer on its own line with a fixed prefix. The reasoning helps accuracy; the prefix lets your code extract the answer cleanly afterward.

The pattern resolves the main objection to chain-of-thought: that the verbose reasoning is hard to consume programmatically. By specifying a delimiter for the final answer, you get both benefits — the model reasons in the open and you still get a clean, extractable result. This is the bridge between a technique that helps the model and output that's usable by software.

This introduces the context window: the fixed token budget that must hold everything — the system prompt, examples, retrieved context, conversation history, and the current user message. Exceed it and either the oldest content is silently dropped or the call fails outright, depending on the API.

A subtler point is positional weighting: models tend to attend more strongly to the beginning and end of a long prompt than to the middle, an effect often called "lost in the middle." That means placement is a real variable. Critical instructions buried in the center of a huge context can be effectively ignored, which is why the next slide cares about ordering and structure.

The stack diagram shows the typical contents of a context window in order: the system prompt with rules and persona, few-shot examples that demonstrate format, retrieved context such as documents or data, the conversation history, and finally the current user message. Together these compete for the same fixed token budget.

The operational lesson is that the window is a budget you allocate, not infinite space. Every example, every retrieved document, and every past turn you keep costs tokens that could go elsewhere and pushes you toward the limit. Good prompt engineering includes deciding what earns its place in the window — trimming stale history, retrieving only the most relevant context, and using the fewest examples that work.

This covers structure and ordering. Delimiters — Markdown headers, triple quotes, or XML-like tags — give the model an unambiguous boundary between your instructions and the data you're handing it, so it doesn't mistake content for commands or vice versa. This is both a clarity tool and, as the next post shows, a safety one.

Ordering compounds the effect. Putting the instruction at the top, the data in a clearly delimited block, and the desired output format last means the format is the freshest thing in context when generation begins, which makes the model more likely to honor it. These are small structural choices, but they reliably improve adherence because they align with how the model reads and weights the prompt.

The code shows delimiters doing their job. The instruction asks the model to extract a company name from text inside <text> tags and to reply with only the name. The tags create a clear fence: everything between them is data to be processed, not instructions to be followed. The model extracts "Acme Corp" rather than being confused by the surrounding sentence.

This pattern is the foundation of safely handling any external or user-provided content. Without the fence, text that happens to contain instruction-like phrasing could derail the model. With it, the model has a structural cue for what is data — a habit that pays off immediately when the content comes from an untrusted source, as the mistakes post will drive home.

Tracing the prompt through tokenization, conditioning, sampling, the context window, and structure gives you a model of why techniques work rather than a list to memorize. Few-shot reshapes the distribution; chain-of-thought gives later tokens a scratchpad; delimiters and ordering align with how the model reads. Each is a deliberate intervention at the one stage you control: the input.

The next post turns this understanding into running code — a reusable prompt builder, few-shot and chain-of-thought in practice, structured output, and a small harness that proves one prompt is actually better than another.