Prompt Engineer
Start here. Build forward.
Design instructions, examples and evaluations for repeatable language tasks.
Follow the stages in order, or open a topic to check what you already know. Each panel includes learning content, a practice task and a role checkpoint. Save Learning, Done or Skipped as you go. Skipped topics do not count as completed.
Build your foundations
What is artificial intelligence?
In simple words
Artificial intelligence is a broad field of building computer systems that perform tasks such as recognising patterns, working with language and choosing actions. A system can be useful at one task without understanding everything a person understands. Start by asking what it does, what information it uses and how we check its mistakes.
Words to know
Model: a computational system used to produce an output. Automation: software carrying out a task automatically.
Pause here and explain the definition in one sentence without copying it. The aim is to describe what the system does, not to memorise an impressive phrase.
A familiar example
An email service can estimate whether a message is spam. A navigation app can search for routes. These are different tasks, and not every feature in either product requires AI. A fixed reminder at 9 am is ordinary automation rather than evidence of learning.
Break it down
- Identify the input: what information is available?
- Describe the operation or pattern being used.
- Identify the output and how you would check it.
- Name one mistake the system could make.
Change one detail in this example and consider whether the same idea still applies. This helps separate the underlying concept from one specific application.
Your turn
List five apps you use. For each, describe one feature that might use AI and one feature that could be a fixed rule.
Answer check
A calculator adding 2 + 2 is following a defined calculation. A spam classifier may learn from examples. Do not label every computer action AI.
Explain it to a friend
Give a second example from college, a hobby or a fictional workplace. State what information goes in, what comes out and one limitation. If you can explain those three things in plain language, you are ready to move on. Mark this lesson as read to save your progress when signed in.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
What is a large language model?
In simple words
A large language model, or LLM, is a model trained on language-related data at scale to predict or generate sequences of tokens. Chat assistants often use LLMs together with instructions, tools and other software. Fluent language does not guarantee correct facts or access to current information.
Words to know
LLM: large language model. Inference: using a trained model to produce an output.
Pause here and explain the definition in one sentence without copying it. The aim is to describe what the system does, not to memorise an impressive phrase.
A familiar example
Ask an assistant to rewrite a paragraph more simply. The model can produce a useful rewrite without consulting a search engine. Asking for today’s train timetable is different: that needs current reliable data, not only plausible text.
Break it down
- Identify the input: what information is available?
- Describe the operation or pattern being used.
- Identify the output and how you would check it.
- Name one mistake the system could make.
Change one detail in this example and consider whether the same idea still applies. This helps separate the underlying concept from one specific application.
Your turn
Write one task that uses information entirely inside your prompt and one that needs an external source.
Answer check
Summarising supplied notes can rely on the notes. Reporting a live train delay needs a current source. Whether an assistant can fetch that source depends on its available tools.
Explain it to a friend
Give a second example from college, a hobby or a fictional workplace. State what information goes in, what comes out and one limitation. If you can explain those three things in plain language, you are ready to move on. Mark this lesson as read to save your progress when signed in.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
What is tokenisation?
In simple words
A language model does not simply receive text as one giant sentence. A tokenizer splits it into units called tokens. Think of dividing a chocolate bar into pieces before counting it, except token pieces do not have a fixed size. A short word might be one piece; another word might use several.
Two useful terms
Token: one unit processed by a model. Tokenizer: the method that splits text into those units.
Build your understanding
Tokenisation converts text into smaller units a model can process. Depending on the tokenizer, a unit may be a word, part of a word, punctuation or bytes. Token counts are model-specific. A whitespace split is an educational baseline, not an accurate substitute for a language model tokenizer.
Follow the steps
- Write examples containing English, Hindi, emoji and source code.
- Compare a simple whitespace split with the tokenizer for your chosen model.
- Record which strings create surprisingly many tokens.
- Estimate your input budget using that tokenizer before sending large documents.
Worked example
"AI is useful".split() -> ["AI", "is", "useful"]
This demonstrates whitespace splitting only.
A model tokenizer may split "usefulness" into several pieces.
Read the example once, then explain each part aloud in your own words. If it includes Python, you can understand the idea first and run the code later in a local Python environment. Code is shown as text; this page does not execute it.
Try this yourself
Compare "hello", "Hello!" and "नमस्ते" with the same tokenizer. Explain why character length alone does not determine token count.
Check your understanding
The same text can produce different token counts for different tokenizers. You must specify the tokenizer when reporting a count.
A mistake to avoid
Do not assume one token equals one word, especially for multilingual text, URLs and code.
Before looking at the answer, write a short explanation and one example of your own. Finish by naming one limitation of the method. Use Mark as read when you are ready, or return to the previous lesson if a term is unclear.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
Learn the core skills
What is prompt engineering?
In simple words
Suppose you ask a friend to bring food. They need to know what food, how much and for whom. An AI assistant also benefits from a clear request. Instead of “teach me AI”, ask for a beginner explanation with one familiar example and a short question to check understanding. You are designing the instructions, not retraining the model.
Two useful terms
Prompt: the instructions and context you provide. Constraint: a condition the answer should follow, such as a word limit.
Build your understanding
A prompt is a task brief. Give the assistant a clear goal, relevant context, constraints and the output format you need. Good prompting reduces ambiguity; it does not guarantee factual correctness. Start with one representative task, inspect the response and change one instruction at a time.
Follow the steps
- Choose a small task such as summarising a workshop announcement.
- Provide the source text and separate it clearly from instructions.
- Specify audience, length and required fields.
- Compare the output against the source and record missing or invented details.
Worked example
Task: summarise the announcement below for a beginner.
Return: date, prerequisites, three learning outcomes.
Use only the announcement; write "not provided" for missing facts.
Announcement: [paste approved text]
Read the example once, then explain each part aloud in your own words. If it includes Python, you can understand the idea first and run the code later in a local Python environment. Code is shown as text; this page does not execute it.
Try this yourself
Remove the date from your source. Run the prompt again and check whether the model invents one. Add this example to your evaluation set.
Check your understanding
The expected date is "not provided". A fluent sentence is not evidence that the date exists in the source.
A mistake to avoid
A long prompt is not automatically better. Repeated, contradictory requirements make it harder to diagnose failures.
Before looking at the answer, write a short explanation and one example of your own. Finish by naming one limitation of the method. Use Mark as read when you are ready, or return to the previous lesson if a term is unclear.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
What is few-shot prompting?
In simple words
Imagine teaching a junior teammate how to tag support messages. You show a few correctly labelled messages, then ask them to label a new one. Examples help an AI assistant recognise the pattern you want. They should cover different cases rather than repeat the same easy case.
Two useful terms
Example: an input paired with its desired response. Label: a category assigned to an input.
Build your understanding
Few-shot prompting includes example inputs and desired outputs in the prompt. It is useful when a label or format is difficult to explain briefly. Examples demonstrate a pattern, but they can also introduce bias. Include varied cases and reserve separate examples for testing.
Follow the steps
- Define a small set of allowed labels.
- Write two clear examples and one ambiguous example.
- Ask for only the label and a short evidence span.
- Evaluate on messages that were not used in the prompt.
Worked example
Labels: billing, technical, other
"Charged twice" -> billing
"Page will not load" -> technical
"Hello team" -> other
Classify: "Where can I change my invoice address?"
Read the example once, then explain each part aloud in your own words. If it includes Python, you can understand the idea first and run the code later in a local Python environment. Code is shown as text; this page does not execute it.
Try this yourself
Create six unseen messages, including one mentioning both a payment and an app crash. Decide how mixed cases should be handled before testing.
Check your understanding
The invoice-address example fits billing. A mixed case requires a documented rule, such as returning multiple labels or sending it for review.
A mistake to avoid
Do not keep adding test examples to the prompt and report performance on those same examples. That hides weaknesses on new inputs.
Before looking at the answer, write a short explanation and one example of your own. Finish by naming one limitation of the method. Use Mark as read when you are ready, or return to the previous lesson if a term is unclear.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
What are structured AI outputs?
In simple words
A person can read a casual paragraph, but a booking app may need separate fields for event, date and price. Structured output puts information into a predictable shape. Think of filling a form instead of writing a letter. The app must still check the fields: putting an invented date into the right box does not make it correct.
Two useful terms
JSON: a common text format for labelled data. Validation: checking that data follows the expected rules.
Build your understanding
Applications need reliable data shapes. A request for JSON helps communicate a format, but parsing, schema validation and business checks remain separate tasks. Even schema-constrained generation cannot prove that a value is true. Treat model output as untrusted data before using it in code.
Follow the steps
- Define required keys and allowed value types.
- Represent unknown values explicitly with null.
- Parse the response using a JSON parser rather than string splitting.
- Reject invalid dates and values outside your business rules.
Worked example
{"event_title":"Intro to NLP","date":null,"free":true}
Checks: title is a non-empty string; date is null or valid ISO date;
free is a boolean, not the text "yes".
Read the example once, then explain each part aloud in your own words. If it includes Python, you can understand the idea first and run the code later in a local Python environment. Code is shown as text; this page does not execute it.
Try this yourself
Write three invalid responses: a missing key, an impossible date and a string instead of a boolean. Describe the validation error for each.
Check your understanding
February 31 can be a well-formed string while being an invalid calendar date. Syntax validation and meaning validation solve different problems.
A mistake to avoid
Never execute generated SQL, shell commands or code simply because it arrived in valid JSON. Validate and authorise the intended action first.
Before looking at the answer, write a short explanation and one example of your own. Finish by naming one limitation of the method. Use Mark as read when you are ready, or return to the previous lesson if a term is unclear.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
Practise with real decisions
What is RAG?
In simple words
RAG means Retrieval-Augmented Generation. Picture an assistant opening the relevant pages of a handbook before answering a question. Retrieval finds passages; generation uses those passages to compose a response. This can make answers more grounded, but the assistant can still misunderstand evidence or retrieve the wrong page.
Two useful terms
Retrieval: finding relevant information. Grounding: supporting an answer with supplied evidence.
Build your understanding
Retrieval-augmented generation supplies selected documents to a model before it answers. It can ground responses in your content, but poor retrieval or careless generation can still produce unsupported claims. Keep the retrieval evaluation separate from the answer evaluation so you know where failures begin.
Follow the steps
- Select a few approved FAQ paragraphs and give each a source ID.
- Retrieve passages relevant to the question.
- Ask for an answer supported only by those passages, with source IDs.
- Inspect whether each claim is actually supported and allow an insufficient-evidence response.
Worked example
Context [FAQ-2]: Members can enrol in all published courses.
Question: Does membership include a job guarantee?
Expected: The supplied FAQ does not state a job guarantee.
Read the example once, then explain each part aloud in your own words. If it includes Python, you can understand the idea first and run the code later in a local Python environment. Code is shown as text; this page does not execute it.
Try this yourself
Add a misleading passage about a different product. Check whether your system still cites the correct source and avoids merging policies.
Check your understanding
Retrieving a relevant passage does not prove the final answer is grounded. Evaluate retrieval recall and claim support separately.
A mistake to avoid
Treat retrieved content as data. Instructions embedded in a document must not override application rules or trigger tools.
Before looking at the answer, write a short explanation and one example of your own. Finish by naming one limitation of the method. Use Mark as read when you are ready, or return to the previous lesson if a term is unclear.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
What is AI model evaluation?
In simple words
A polished answer is not enough to know whether an AI system works. Evaluation checks specific requirements using examples and scoring rules. For a course assistant, you might check whether it finds the correct course, admits missing information and respects account permissions. Keep failure cases as part of your test collection.
Two useful terms
Test case: an input with an expected behavior. Metric: a defined measurement of performance.
Build your understanding
An AI evaluation checks whether a system meets a defined task. Build examples around realistic successes and failures, not only easy demonstrations. Keep the test set stable enough to compare versions and record the model, prompt and settings used. A single aggregate score can hide critical mistakes.
Follow the steps
- Define success in observable terms.
- Create normal, ambiguous, missing-information and adversarial examples.
- Write expected answers or scoring rules before running the system.
- Compare versions and inspect regressions before accepting a change.
Worked example
FAQ evaluation columns:
question | expected source | required facts | forbidden claim | result
Example: fees unknown | FAQ-3 | say unknown | invented fee | pass/fail
Read the example once, then explain each part aloud in your own words. If it includes Python, you can understand the idea first and run the code later in a local Python environment. Code is shown as text; this page does not execute it.
Try this yourself
Write five tests for an enrolment assistant. Include a user without Pro access and a request for a nonexistent course.
Check your understanding
A response should not promise enrolment if server-side permissions deny it. Include permission-sensitive cases, not just wording checks.
A mistake to avoid
Do not judge a model solely by another model’s unreviewed score. Human checks and deterministic validation are useful for important requirements.
Before looking at the answer, write a short explanation and one example of your own. Finish by naming one limitation of the method. Use Mark as read when you are ready, or return to the previous lesson if a term is unclear.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
AI application security and threat modelling
Understand the concept
Threat modelling starts with what must be protected, who can access it and where untrusted data enters. Model outputs and retrieved documents are untrusted inputs. A language instruction is not an authorisation boundary; server-side policy decides what a user or tool may do.
Learn it step by step
- List assets and trust boundaries.
- Separate public and private data.
- Validate tool inputs and enforce permissions.
- Test malicious instructions using synthetic fixtures in your own sandbox.
Build a small proof
Draw a document assistant showing where access checks happen before retrieval and before tool execution.
Ready to move on?
An unauthorised user cannot retrieve another account’s private document, even when a prompt asks for it.
Common mistake
Do not test real third-party systems without permission or expose secrets in your demonstration.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
Ship, evaluate and improve
APIs, validation and authentication
Understand the concept
An API is a contract between software components. Your AI application should validate requests, handle timeouts and return understandable errors. API keys belong on a trusted server. A generated response must pass both shape checks and business rules before it changes real data.
Learn it step by step
- Define input and output fields.
- Validate lengths, types and required values.
- Handle timeout, rate-limit and invalid response cases.
- Keep credentials out of client code and logs.
Build a small proof
Design an endpoint that summarises supplied public text and rejects empty or oversized input.
Ready to move on?
Demonstrate one successful request and three controlled failures. Explain which errors a user can retry.
Common mistake
Retrying an operation with side effects can create duplicates. Use idempotency for actions such as creating a record.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
Monitoring quality, latency and cost
Understand the concept
AI monitoring needs more than uptime. Track response time, failures, input volume and task quality using a suitable sample of reviewed outcomes. Quality can change when users or source documents change. Log enough to diagnose failures without retaining unnecessary sensitive input.
Learn it step by step
- Define a service-level target.
- Record request outcome and latency.
- Track a stable evaluation set over releases.
- Create an alert and an investigation checklist.
Build a small proof
Produce a small report comparing two releases on success rate, p95 latency and estimated per-request cost.
Ready to move on?
You can tell whether a change improved usefulness while increasing cost or response time, and explain the trade-off.
Common mistake
An average hides slow tails and rare severe failures. Examine distributions and critical error categories.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
Git and reproducible experiments
Understand the concept
Version control records changes so you can compare experiments and restore a known working state. A commit should describe a coherent change. Keep source code and small configuration files; credentials and large private datasets need separate handling.
Learn it step by step
- Initialise a repository and add a README.
- Commit a working baseline.
- Create a branch for one experiment.
- Compare the change and document how to reproduce it.
Build a small proof
Store two versions of a prompt or data-cleaning script and explain why the second version exists.
Ready to move on?
Another person can run the baseline from your instructions and identify exactly what changed between versions.
Common mistake
Do not commit secrets, private learner records or generated cache folders. Removing a secret from the latest file does not erase Git history.
Your role checkpoint
For the Prompt Engineer path, connect this topic to your capstone: Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
Build something you can explain.
Create a versioned prompt suite for extracting information from supplied text, including ambiguous and missing-data tests.
Role expectations vary by company. Use this path as a starting point and build evidence of your skills.