00. Prompt Engineering — The Five-Year-Old Version¶

Module 06 covered fine-tuning the model. This module covers giving the model instructions it can reliably follow.

Imagine you hired a very fast contractor. The contractor is strong, quick, and tireless. But one thing is unusual. The contractor is extremely literal. If your instruction is fuzzy, the work becomes fuzzy. If your instruction is contradictory, the work becomes contradictory. If your instruction is neat, layered, and testable, the work becomes useful. That is prompt engineering.

In this module, the prompt is not a clever sentence. It is the full work package. You write the standing rules once. You hand over the current work order. You attach sample deliverables. You add a red-ink list saying what must never happen. You attach the reply form. Then you decide how much freedom the contractor gets. Simple, no?

Now look at the problem. A smart contractor will still fail on a bad brief. The standing rulebook may say, "stay grounded." The work order may say, "answer this customer question." The sample deliverables may show the right tone. The red-ink list may ban legal advice. The reply form may force JSON. The creativity dial may be low for billing. The revision ledger may record which version worked best. Prompt engineering is the craft of arranging all that.

See the pattern. We are not begging the model. We are designing a production instruction stack. We are deciding what stays fixed. We are deciding what changes per request. We are deciding what examples teach fastest. We are deciding what bad behavior gets blocked early. We are deciding how output becomes machine-readable. We are deciding how to test, compare, and roll back prompts. That whole system is the module.

Here is a tiny picture.

customer need
    │
    ▼
┌─────────────────────┐
│ standing rulebook   │
├─────────────────────┤
│ work order          │
├─────────────────────┤
│ sample deliverables │
├─────────────────────┤
│ red-ink list        │
├─────────────────────┤
│ reply form          │
└─────────────────────┘
    │
    ▼
 literal contractor
    │
    ▼
 model answer

Now a tiny worked example. Bad work order: "Write something about refunds." The contractor may produce marketing fluff. Better work order: "Summarize the refund rule in three bullets for a support agent. Use only the policy text below. If a detail is missing, say unknown." Same contractor. Very different result. So what changed? Not the brain. The brief.

This module will make that brief systematic. We will study system prompts. We will study few-shot placement. We will study negative examples. We will study reasoning prompts. We will study structured outputs. We will study versioning, experiments, debugging, and security. By the end, you should look at a prompt and ask, "Where is the standing rulebook weak?" "Which sample deliverable is teaching the wrong pattern?" "Why is the reply form leaking?" That is the right habit.

The placeholders you will see called back¶

Placeholder	Meaning
Standing rulebook	The always-on instructions that define role, boundaries, and priorities.
Work order	The task-specific request for this one job.
Sample deliverables	Examples that show the exact pattern to imitate.
Red-ink list	Explicitly wrong outputs, forbidden moves, or refusal patterns.
Reply form	The required structure of the final answer, like JSON or tagged sections.
Creativity dial	The sampling settings that trade strictness for variety.
Revision ledger	The version history, experiment notes, and rollback record for prompts.

What's coming¶

01-why-prompts-matter.md — why the same model can look brilliant or useless.
02-system-prompt-anatomy.md — how to build the standing rulebook in layers.
03-few-shot-placement.md — where examples go, how many help, and why order matters.
04-negative-examples.md — how the red-ink list sets sharp boundaries.
05-chain-of-thought.md — when step-by-step reasoning helps and when it backfires.
06-structured-output.md — how the reply form turns text into reliable machine input.
07-temperature-sampling.md — how the creativity dial changes risk and variety.
08-prompt-chaining.md — how one careful prompt feeds the next stage.
09-prompt-versioning.md — how the revision ledger makes prompts behave like code.
10-ab-testing-prompts.md — how to compare prompt variants with real metrics.
11-prompt-debugging.md — how to diagnose why the model did that strange thing.
12-prompt-security.md — how to defend the instruction stack from prompt injection.
13-honest-admission.md — what still feels brittle, mysterious, or unresolved.

Bridge. Before tuning the brief, we need one hard truth. The prompt is not decoration around the model. In production, it is part of the product. → 01-why-prompts-matter.md