Command Palette

Search for a command to run...

Hectal
Phase 3Beginner4 of 15 in LLM Engineering

Prompting as Engineering

Treat prompts like code: write them as specifications, keep user data apart from instructions, build them with functions, version them and test them.

A prompt is the text you send to a model. Beginners treat it like a magic spell and keep rewording it until it works once. Engineers treat it like a requirements document: it says exactly what the program must do, it is written by code from clean parts, it is stored in a file with a version, and it is tested every time it changes.

This phase builds that habit from the ground up. You will see why vague prompts give vague output, learn the parts of a clear instruction, use examples instead of long explanations, keep user text safely apart from your instructions, decide what goes in the system message, and decide when to ask a model to think step by step.

Then the work becomes engineering: prompt templates as functions, prompts in files with ids and versions, and a small regression test that catches a prompt change (or a model update) that makes things worse. Runnable examples use fake models whose replies depend on what the prompt contains, so you can watch cause and effect in Python, Java and JavaScript. Three real-model labs let you try the same ideas on a real model. The phase ends with a library of tested prompt patterns you can copy.

0/9 · 0%
9 topics ~3 h 13 code blocks & diagrams
Start with the first topic
1
3.1

Prompts Are Specifications

A prompt is the requirements document for a very literal worker. A vague prompt gets a vague answer; a prompt that states the audience, length and format gets output your program can rely on.

19 min 1 code practice

2
3.2

Writing Clear Instructions

A clear instruction names the task, the context, the audience, the output format and the constraints. Say what to do first; add what to avoid only when needed. Build the prompt from named parts in code.

21 min 2 code practice

3
3.3

Examples in the Prompt (Few-Shot)

Showing the model two or three solved examples often works better than explaining the rule in words. Zero-shot has none, one-shot has one, few-shot has several. Which examples you pick, and their order, change the answer.

20 min 2 code practice

4
3.4

Delimiters: Keeping Data Apart from Instructions

A prompt mixes your instructions with someone else's text. Wrapping that text in tags, and escaping the characters that could close the tag, keeps data from being read as instructions. This is the first defence against prompt injection.

18 min 1 code practice

5
3.5

System Prompts

The system message holds the rules and role that apply to the whole conversation. It beats user requests when they conflict, but every word in it is paid for on every call, so keep it short and put only stable rules there.

20 min 2 code practice

6
3.6

Asking the Model to Think

For multi-step problems, asking the model to work step by step often makes it more accurate. Reasoning models do this on their own. Show users the final answer, check exact values in code, and never treat the written reasoning as proof.

19 min 1 code practice

7
3.7

Prompt Templates as Code

A prompt template is text with named blanks, filled by a function. A real template engine fills each blank once, complains about missing values, and never lets an inserted value act as a new blank.

18 min 1 code practice

8
3.8

Versioning and Testing Prompts

Store prompts in files with an id, a version and a changelog, and run a small regression set before every change. A change, or a model update, that lowers the score is caught before users see it.

20 min 1 code practice

9
3.9

Playbook: Prompt Patterns Library

Five prompt patterns you will use in almost every project, each built by a small function and each checked by code: classify, extract, summarise, rewrite and answer from context.

20 min 2 code practice

Practise this phase

Hands-on exercises: write the code, run it, and press Check to have it tested automatically.