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.
Practise this phase
Hands-on exercises: write the code, run it, and press Check to have it tested automatically.