Context engineering vs. prompt engineering

Writing a good letter vs. running the post office

Prompt engineering is like carefully wording a single letter — choosing precise phrasing, giving clear examples, being polite but direct, so the person reading it understands exactly what you want.

Context engineering is running the entire postal system that gets the right letter, attachments, and background paperwork to the right desk, in the right order, without losing anything or overwhelming the recipient. You can write the most beautifully worded letter in the world, but if it arrives with 200 irrelevant attachments and the important page buried in the middle, it won't get read properly.

Both matter. But they solve different problems, and confusing them is one of the most common mistakes people make when they start building real LLM applications.

Defining both terms precisely

Prompt engineering is the craft of wording a single instruction or question to get better output from a model. Its concerns are things like:

• Being specific instead of vague ("Summarize this in exactly 3 bullet points" vs. "Summarize this")
• Giving the model a role ("You are an expert C++ code reviewer")
• Providing a few examples of desired output format (few-shot prompting, covered in Module 4)
• Asking the model to reason step by step (chain-of-thought, also Module 4)

Context engineering is the broader discipline of designing the entire information pipeline that decides what content — including that carefully engineered prompt — ends up inside the model's context window. Its concerns are things like:

• Which documents get retrieved and why (Module 5)
• How much conversation history to keep, summarize, or drop (Module 6)
• How to order information so the model actually notices the important parts (Module 4)
• How to stay inside the token budget from the last lesson while still including everything that matters
• What format (JSON, markdown, plain prose) makes the information easiest for the model to use correctly

                    CONTEXT ENGINEERING
        (decides everything that goes on the desk)
┌───────────────────────────────────────────────────┐
│  system instructions                              │
│  retrieved documents  ◀── chunking, ranking, RAG  │
│  conversation history ◀── summarization, memory   │
│  ┌─────────────────────────────────────────────┐  │
│  │         PROMPT ENGINEERING                  │  │
│  │  (the wording of the actual instruction/    │  │
│  │   question placed at the end)               │  │
│  └─────────────────────────────────────────────┘  │
└───────────────────────────────────────────────────┘

Prompt engineering lives inside context engineering — it's one component (arguably the smallest one, in terms of engineering effort) of the bigger system.

A concrete example of the difference

Say you're building a customer support bot for a software company. A prompt engineering fix might be rewriting the system prompt from "Answer questions about our product" to "You are a support agent for Acme CRM. Always cite the exact feature name. If you don't know, say so — never guess." That's a real, valuable improvement, and it takes minutes.

A context engineering fix is deciding: which of the company's 4,000 help articles get pulled in for a given question, how they get chunked and ranked, how much of the last 10 messages of conversation history to keep, whether to inject the user's subscription tier (so the bot doesn't recommend a feature they can't access), and how to keep all of that under the token budget while leaving room for a useful answer. That's a system, not a sentence, and it's usually where the real engineering effort — and the real quality improvement — happens in production LLM applications.

Why this distinction became a big deal

Early on (2020–2022), "prompt engineering" got most of the attention because most people were interacting with models directly through a chat window — there was no pipeline, just a text box. As people started building real applications — chatbots with company knowledge, coding assistants that read your whole codebase, agents that call tools and remember past actions — it became obvious that wording alone couldn't fix problems caused by missing or badly organized information. You can't prompt-engineer your way around a model that was never given the right document in the first place.

This is why the field shifted toward "context engineering" as the more accurate description of the actual job: most of the effort in a good LLM application goes into building the pipeline that decides what the model sees, not into wordsmithing the final instruction.

The math connects the two

Recall the budget equation from the last lesson:

$C \geq S + H + R + U + O$

Prompt engineering mostly affects $S$ (the system prompt) and $U$ (how the user's request is phrased) — usually a small, fairly fixed number of tokens. Context engineering is responsible for architecting $H$, $R$, and the trade-offs against $O$ — the parts of the equation that grow, shrink, and require active decisions on every single request. If your application is failing because $H + R$ keeps blowing past what's left of $C$, no amount of clever wording in $S$ or $U$ will fix it.

Common mistakes

1. Assuming a bad answer always means "reword the prompt." Sometimes the model simply never received the relevant information — no wording fixes a missing document.
2. Over-investing in prompt tweaking, under-investing in retrieval quality. Teams often iterate endlessly on system prompt wording while the actual bottleneck is that their retrieval step is pulling in the wrong documents.
3. Treating the two as competitors. They're complementary. A well-engineered context with a sloppy prompt still underperforms a well-engineered context with a clear, specific prompt.

A few more concepts worth knowing

• Prompt templates: a reusable prompt structure with placeholders filled in per request (seen throughout this course's C++ examples) — the standard way production systems keep prompt engineering and context engineering cleanly separated in code.
• System, user, and assistant roles: most chat-based APIs structure context into distinct roles rather than one flat block of text — the system role typically carries persistent instructions, user carries the human's input, and assistant carries the model's own past replies, giving the model an explicit structural signal about who said what.
• Prompt versioning: as a system evolves, treating prompt templates like code — tracked in version control, tested before deploying — avoids silent regressions when someone tweaks wording without realizing it affects a live production system.
• Meta-prompting: using a model to help write or refine a prompt for another (or the same) model — a practical technique, but still ultimately subject to the same context engineering principles about structure and clarity covered in this lesson.

Summary

Prompt engineering is about wording a single instruction well; context engineering is about designing the whole pipeline — retrieval, memory, ordering, formatting, budgeting — that decides everything else the model sees alongside that instruction. Prompt engineering lives inside context engineering, as one relatively small piece of a much bigger system. This closes out the foundations module. Module 2 goes deep into the actual numerical representations — tokens and embeddings — that make all of this possible under the hood.