Prompt Engineering Guide

Prompt engineering has a reputation problem: it sounds like "typing nicely at a chatbot." In practice, it's the difference between an LLM feature that works reliably in production and one that breaks the moment a real user phrases something unexpectedly. This guide covers the techniques we teach hands-on in the Generative AI course's prompt engineering module.

What is prompt engineering?

Prompt engineering is the practice of designing inputs to an LLM so that its output is reliable, well-structured, and aligned with what you actually need — not just "correct in one lucky test." Because LLMs are sensitive to phrasing, structure, and examples, a well-engineered prompt can be the difference between a 60% success rate and a 95% success rate on the same underlying task, using the exact same model.

Zero-shot, one-shot, few-shot

These describe how many examples you give the model before asking it to perform a task:

• Zero-shot — you describe the task with no examples. Works well for tasks the model has clearly seen many times in training (summarization, translation, simple Q&A).
• One-shot — you give exactly one example of the input/output pattern you want, then ask for a new one. Useful when the output format is specific but simple.
• Few-shot — you give several examples (typically 2–5), which is often enough to lock in a precise format, tone, or edge-case handling that zero-shot prompting misses entirely.

The practical rule: if zero-shot output is inconsistent in format or misses edge cases, add 2–3 examples covering exactly those edge cases before trying anything more complex.

Role & context prompting

Telling a model who it is ("You are a senior backend engineer reviewing this code for security issues") and what context it's operating in shapes its output far more than most people expect — not because the model "becomes" that role, but because role framing activates the patterns of language associated with that expertise in its training data. Context prompting — giving background facts, constraints, or prior conversation the model needs — reduces the model filling gaps with assumptions (which is where hallucination sneaks in).

Structured & JSON outputs

Any prompt whose output will be parsed by code (not read by a human) should ask explicitly for a structured format — JSON is the most common — with the exact fields you need spelled out. Two techniques make this reliable:

• Show the exact JSON schema or an example output, not just a description of it in prose.
• Where the API supports it (most modern LLM APIs do), use a native structured-output or JSON-mode setting instead of relying purely on prompt instructions — it constrains generation directly rather than hoping the model complies.

Instruction hierarchy

In any real application, instructions come from multiple layers: a system prompt written by the developer, and user input from whoever is using the product. A well-designed prompt makes this hierarchy explicit — system-level rules the model should never violate, versus user requests it should follow within those rules. This is also the first line of defence against prompt injection: a user typing "ignore your previous instructions" shouldn't be able to override rules set at the system level if the hierarchy and framing are designed correctly.

Prompt decomposition

Complex tasks often fail as a single prompt but succeed when broken into steps: extract the relevant facts, then reason about them, then format the final answer — as separate prompts (or explicit reasoning steps within one prompt) rather than asking for everything at once. This mirrors how you'd break down a hard problem for a junior engineer: smaller, verifiable steps beat one large ambiguous ask.

Evaluating & iterating on prompts

Treat prompts like code: version them, test them against a fixed set of representative inputs (including edge cases), and measure output quality before and after a change — not just eyeballing one output and shipping it. This is the discipline that separates prompt engineering from prompt guessing, and it's exactly what our LLM evaluation guide covers in depth. In the course, this is where the Prompt Battle activity comes in — students' prompts are judged live against identical test cases, which makes "does this actually work reliably" concrete instead of subjective.

Common mistakes

• Vague instructions — "make this better" gives the model nothing concrete to optimize for. Specify the dimension: shorter, more formal, fewer technical terms.
• No examples for format-sensitive tasks — if the exact output shape matters, show it, don't just describe it.
• Testing on one input — a prompt that works on your first test case can fail badly on a slightly different phrasing. Test on a representative set before trusting it.
• Fighting the model instead of restructuring the prompt — if a model consistently misunderstands a request, the fix is almost always to restructure the prompt, not to repeat the same instruction more forcefully.

Prompt engineering is a practical skill best learned by testing prompts against real, sometimes messy inputs — which is exactly how it's taught hands-on in the Prompt Engineering module of our Generative AI course.