Prompt Engineering & Architecture
Move beyond chatting. Design prompts an application can depend on.
There is a wall people hit after a few months of daily AI use: the answers are good enough to impress a colleague and nowhere near good enough to put behind a button a customer presses. Crossing that wall is what this module is about, and it has almost nothing to do with clever wording. A prompt in a chat window has a human filter after it — you read the output, you notice it is wrong, you retry. A prompt inside an application has no such luxury. It has to return the same shape every time, fail in a way your code can catch, and survive inputs no one imagined. So we work on the things people skip. Structured output, because parsing prose is how integrations rot. Few-shot examples, because one worked example carries more instruction than a paragraph of adjectives. Decomposition, because a chain of three checkable steps beats one heroic prompt that no one can debug. And token economics, because a prompt that costs too much or answers too slowly is broken regardless of quality. Magic phrases die with each model release. Specification, evaluation and structure do not.
Prerequisites
- Several months of regular work with an AI assistant, or module 01
- Ability to read JSON — writing code is optional
- One real task you want to automate, with real examples of it
What you can do afterwards
- Force structured, schema-valid output and handle the runs that break it
- Design few-shot examples that teach the edge case, not just the happy path
- Split a task into a chain of checkable steps instead of one fragile mega-prompt
- Separate system and user prompts so untrusted input cannot rewrite your rules
- Cut token cost and latency without losing quality, and prove it with a test set
- Version a prompt and catch a regression before your users do
Sessions
Structured output and schemas
The moment a prompt feeds code, prose becomes a liability. You will force JSON that matches a schema, validate it, and design what happens on the run that ignores you anyway — because it will. Most integrations that "worked in testing" died on a stray sentence of preamble before the opening brace.
Covered
Few-shot design and example selection
Examples are the highest-leverage part of a prompt and the worst-used. Three well-chosen ones outperform two pages of instructions — but the model copies whatever it sees, including your accidental habits. You will learn to pick examples that carry the hard case, and to spot when the model has anchored on a pattern you did not mean to teach.
Covered
Chaining, decomposition and reasoning patterns
One prompt doing five things is a prompt you cannot debug: when it fails you have no idea which of the five broke. Decomposition trades a little cost and latency for the ability to inspect every step. We cover chain-of-thought, tree-of-thought and self-critique honestly — including the cases where the extra tokens buy you nothing but a bigger bill.
Covered
System prompts and architecture
A system prompt is your product’s constitution: it holds the rules that must survive whatever a user types. That separation is not cosmetic — it is your first defence against someone pasting "ignore your instructions" into a form field. You will design the boundary between fixed rules and untrusted input, and test it by attacking your own prompt.
Covered
Evaluating and shipping a prompt
This is the session that separates a demo from a product, and the one people resent most. A prompt you cannot evaluate is a prompt you cannot improve — without a test set every change feels like progress and you never learn what you broke. Twenty real cases, a rubric written before you look at any output, and the discipline to change one thing at a time.
Covered
Build a prompt-powered application: take one real task, ship a working tool driven by a versioned prompt that returns structured output, and defend it with a 20-case test set showing your score before and after, plus one regression you caught.
Offered in
Questions
Will better models make prompt engineering pointless?
The trick-based version is already dead — magic phrases stopped working long ago, which is exactly why this module contains none. What survives is specification: stating a task precisely, deciding what "good" means, and measuring it. Better models raise the ceiling; they still do not know your business rules, your data or your definition of correct. This module teaches the part that outlives the model you happen to use today.
Do I need to code to take this module?
You need to read JSON and be willing to click through a no-code tool; you do not need to write software. The hardest and most valuable parts here — designing examples, defining "correct", building a test set, spotting your own selection bias — are writing and judgement, not programming. If you want to build the application around the prompt rather than the prompt itself, that is module 03.
Does any of this hold up in French and Darija, or only in English?
The principles transfer — a specification is a specification in any language. The results do not transfer evenly: models see far more English than French, and far more French than Darija, so identical prompt quality yields weaker output as you move away from English, and Arabic text costs more tokens for the same meaning. That is a constraint to design around, not a reason to give up. It means your test set must be in the language your users actually write, and that reasoning language and output language become a deliberate decision. We treat that as part of the work, not a footnote.
Other modules
Ready to take this module?