Prompt Engineering

Prompt engineering is the discipline of designing the input to a language model — instructions, context, examples, constraints, and output format — so the model produces reliable, useful results.

The name undersells it. A prompt in production is not a clever sentence; it is an interface specification. It defines the model's role, supplies the evidence it may use, shows examples of good output, and pins down the exact format downstream code will parse. Getting that specification right is the cheapest, fastest lever in all of applied AI — no training, no infrastructure, just better instructions.

How it works

The techniques that survive contact with production are surprisingly stable:

• Be specific and unambiguous. "Summarize in 3 bullet points for a non-technical executive, 20 words max each" beats "summarize this" every time.
• Assign a role. "You are a senior security reviewer" shifts tone, rigor, and what the model chooses to notice.
• Show, don't just tell. Few-shot examples — two or three input/output pairs — teach format and judgment better than paragraphs of description.
• Give the model room to think. Asking it to reason step by step before answering measurably improves accuracy on math, logic, and multi-step tasks (the chain-of-thought effect).
• Constrain the output. Demand JSON with named fields, or a fixed template, so the response is machine-parseable.
• Permit uncertainty. An explicit "if the context doesn't contain the answer, say so" clause is one of the most effective anti-hallucination lines ever written.

Beyond single prompts, the craft extends to structuring context: what to include, in what order, and how much — because every token of context spends budget and competes for the model's attention.

Why it matters

The same model with the same data can be useless or excellent depending on the prompt. Teams routinely see large accuracy swings from prompt changes alone — which also makes prompts dangerous: they are code that does not look like code. Untested prompt edits break production systems exactly the way untested code does. That is why serious teams version their prompts, review changes, and run evals on every edit.

A worked example

Weak prompt: "Is this email suspicious?" — output rambles, varies in format, and cannot be parsed.

Engineered prompt: "You are a phishing analyst. Classify the email below as SAFE, SUSPICIOUS, or PHISHING. Respond in JSON with fields verdict and reasons (max 3, each citing specific evidence from the email). If evidence is insufficient, use SUSPICIOUS and say why." Followed by two worked examples, then the email.

The output is now consistent, auditable, parseable, and honest about uncertainty. Nothing about the model changed — only the specification did.

How miatz teaches it

Prompt engineering at miatz is drilled like any other rep: learners rewrite failing prompts against a fixed eval set and watch scores move, rather than admiring prompts in isolation. The COSTAR framework gives beginners a checklist scaffold, and War Rooms include incidents where an unreviewed prompt change was the root cause — because in the AI era, that is a real outage class.