Prompt Engineering
Get reliable output from AI models — on purpose, not by luck.
Most people plateau with AI after a few weeks. They get impressive demos and unreliable results, and they blame the model. The gap is rarely the model — it is that a prompt is a specification, and most people never learned to write one. This path treats prompting as engineering rather than folklore. You start with structure: what a model actually reads, why order matters, and why "be creative" fails while a worked example succeeds. You then learn to measure, because a prompt you cannot evaluate is a prompt you cannot improve — this is the step almost everyone skips, and it is the one that separates a hobbyist from a professional. From there you move into context engineering, where the real leverage is: what you put around the question matters more than the phrasing of the question. You finish on production patterns — versioning, regression testing, cost and latency, guardrails — the things that decide whether your work survives contact with real users. No tricks, no magic word lists. Those age badly. Principles do not.
What you will learn
Prerequisites
- No programming required
- Comfort writing clearly in one language
- Access to any modern AI assistant
Where it leads
- Prompt Engineer
- AI Content Strategist
- AI-augmented specialist (any field)
- Conversational AI Designer
Phases
Phase 1 — Structure
Stop guessing. Understand what the model reads and why order changes the answer.
Estimated duration · 3-4 weeksHow a model actually reads your prompt
Tokens, context window, and attention explain most "weird" model behaviour. You do not need the maths, but you need the mental model — it tells you why a long prompt drifts and why instructions at the end sometimes win.
Topics covered
What you will build
- Take one failing prompt and fix it by reordering only
- Measure token cost of your 5 most-used prompts
- Run the same prompt 10× and document the variance
The prompt as a specification
Role, task, constraints, format, examples. Most bad output is an underspecified request, not a weak model. You will rewrite vague asks into specifications a competent stranger could execute — which is exactly the bar the model needs.
Topics covered
What you will build
- Rewrite 10 vague prompts as specifications
- Build a reusable template for your most frequent task
- Force structured JSON output and validate it
Failure modes you will meet
Learn to name what went wrong before trying to fix it. A model that invents a source, a model that ignores half your instructions, and a model that answers a question you did not ask are three different bugs with three different fixes — and treating them as one is why people rewrite prompts for hours without progress. Naming the failure is most of the cure.
Topics covered
What you will build
- Build a catalogue of the 5 failures you hit most, with a reproducible example of each
- Force a hallucination on purpose, then make it impossible
- Find the length at which your prompt starts ignoring instruction #1
Phase 2 — Measurement
A prompt you cannot evaluate is a prompt you cannot improve. This is the phase everyone skips.
Estimated duration · 3-4 weeksBuilding a test set
Twenty real cases beat a thousand imagined ones. You will collect actual inputs — including the ugly edge cases you would rather ignore — and define what "good" means before you start optimising.
Topics covered
What you will build
- Build a 20-case test set for one real task
- Write the rubric before looking at any output
- Score your current prompt as a baseline
Iterating on evidence
Change one thing, re-run the set, compare. This is unglamorous and it is the whole job. You will also learn where LLM-as-judge helps and where it quietly lies to you.
Topics covered
What you will build
- Improve one prompt by 20% on your rubric — with evidence
- Build a scoring sheet you re-run on every change
- Find one case where the LLM judge is wrong
Reading your own results honestly
The hardest part of evaluation is not building the test set — it is not fooling yourself with it. You will unconsciously pick the cases your prompt already handles, score generously on a Friday, and remember the impressive answer rather than the median one. Twenty cases is a small sample: a two-point move is noise, not progress, and treating it as progress is how teams convince themselves for months that they are improving. Learn to separate a real gain from a lucky run, and to say out loud when a change made things worse.
Topics covered
What you will build
- Score 20 outputs blind, without knowing which prompt version produced them
- Re-run your best prompt 5× and check your "gain" survives the variance
- Write up one change that made things worse, and publish it to your team
Phase 3 — Context & production
Move from clever prompts to systems that hold up with real users, real cost and real risk.
Estimated duration · 4-6 weeksContext engineering
The real leverage is not phrasing — it is what you put around the question. Retrieval, compression, and knowing what to leave out. Most "the model is dumb" complaints are missing-context problems.
Topics covered
What you will build
- Build a grounded Q&A over your own documents
- Cut context size 50% without losing quality
- Make the model cite its source on every claim
Shipping and living with it
Versioning, cost, latency, failure modes, and guardrails. A prompt in production is code: it needs a history, a test suite, and someone who notices when it breaks at 3am.
Topics covered
What you will build
- Ship one prompt-powered workflow to real users
- Halve its cost without losing rubric score
- Break your own prompt with an injection, then fix it
Working across languages
Almost every guide assumes you work in English. Most people here do not. Models are measurably weaker outside English, and weaker again on dialects — Moroccan Darija mixes Arabic, French and Amazigh, switches script mid-sentence, and has no settled spelling, so a model trained mostly on English text has little to stand on. The practical questions are which language to reason in, which to answer in, and how you evaluate a translation when you only fluently read one of the two. This step is not decoration: if your users write in Darija, this is the whole job.
Topics covered
What you will build
- Build a test set of real Darija inputs, spelling chaos included
- Compare reasoning in English then answering in French, against doing both in French
- Measure the token cost of the same text in Arabic vs French
Questions
Is prompt engineering still a real skill, or will models make it obsolete?
The trick-based version is already obsolete — magic phrases stopped working years ago. What has not gone away is specification: stating a task precisely, deciding what "good" means, and measuring it. Better models raise the ceiling, they do not read your mind. This path teaches the part that survives model upgrades.
Do I need to code?
Not for phases 1 and 2 — the hardest and most valuable parts are writing and evaluation, not programming. Phase 3 touches retrieval and production, where a little Python or a no-code tool helps. If you want to build applications rather than operate them, continue with the LLM Applications path.
Why so much emphasis on evaluation?
Because it is the difference between a demo and a product. Without a test set you are tuning on vibes: every change feels like an improvement and you have no idea whether you broke the previous case. Teams that measure improve steadily; teams that do not go in circles for months. It is also the least fun part, which is why it is the most neglected — and therefore the most valuable.
Does this work 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 are trained on far more English than French, and far more French than Darija, so the same prompt quality yields weaker output as you move away from English. That is a real constraint, not a reason to give up: it means your test set has to be in the language your users actually write, and that reasoning language and output language are a decision you make deliberately rather than inherit. This path covers that explicitly, because a guide that assumes everyone works in English is useless for most of the people reading this one.
Related paths
Want to walk this path with a coach and a cohort?
Discover the 212AY Academy →