Prompt Engineering Introduction

What Is a Prompt?

A prompt is the input you give to an AI language model to get a response from it. In simple terms, a prompt is the message you write to the AI. It can be a question, an instruction, a piece of text to process, or a combination of all of these. In technical terms, a prompt is the complete text (and sometimes other data, such as images) that is sent to a Large Language Model (LLM) as input. The model reads this input and generates output text that continues from it in the most appropriate way it has learned.

Example: A Simple Prompt

What is the capital of Japan?

Possible output:

The capital of Japan is Tokyo.

Example Explanation

• The prompt is a direct question with one clear answer.
• The model does not need extra information, because the question is unambiguous and the answer is common knowledge.
• This works well because the task (answer a factual question) and the expected output (a short answer) are both obvious from the question itself. Most real tasks are not this simple. As soon as a task has more than one reasonable interpretation, the quality of the prompt starts to control the quality of the answer.

  A Prompt Is More Than a Question

  A prompt can contain several kinds of information at once:

  Translate the following customer review into French.
  Keep the tone informal.
  Review: "The course was super easy to follow and the projects were fun!"

  This single prompt contains: | Part | Content | Purpose | |------|---------|---------| | Instruction | Translate the following customer review into French. | Tells the model what task to perform | | Constraint | Keep the tone informal. | Controls how the task is performed | | Input data | The review text | Gives the model the material to work on | You will study these parts in detail in later lessons. For now, the important idea is that everything inside the prompt influences the response.

  ---

  What Is Prompt Engineering?

  Prompt engineering is the practice of designing, writing, testing, and improving prompts so that an AI model produces useful, accurate, and consistent outputs for a specific task. In simple terms, prompt engineering means learning how to ask an AI model in a way that it understands exactly what you want.

  Why Is It Called "Engineering"?

  Writing one good prompt for a chat conversation is a writing skill. Prompt engineering goes further and treats prompts the way a developer treats code: | Engineering Activity | What It Means for Prompts | |----------------------|---------------------------| | Design | Deciding what the prompt must contain: task, context, data, format | | Implementation | Writing the prompt, often as a reusable template inside an application | | Testing | Running the prompt against many different inputs, not just one | | Measurement | Checking outputs for accuracy, format, tone, and consistency | | Iteration | Changing the prompt based on failures and testing again | | Versioning | Keeping track of prompt changes, because a small edit can change behavior | A prompt that powers a real product (for example, a support-ticket classifier that processes thousands of messages a day) must work reliably for inputs its author never saw. Reaching that level of reliability requires a systematic process, which is why the word engineering is used.

  ---

  Why Prompt Engineering Is Needed

  The Model Does Not Know Your Situation

  A language model has learned patterns from a very large amount of text, but it knows nothing about:

• Who you are
• Who your audience is
• What you plan to do with the answer
• What format your application expects
• What rules your business follows If this information is missing from the prompt, the model fills the gaps with assumptions. Sometimes the assumptions match what you wanted. Often they do not.

  Example: An Ambiguous Prompt

  Write about Python.

  This prompt has many valid interpretations:

• Python the programming language, or the python snake?
• A beginner explanation, or an advanced technical article?
• Three sentences, or three pages?
• A blog post, a tweet, a lesson plan, or interview questions? The model will pick one interpretation, usually the most common one in its training data, and you have no control over which one. The response may be well written and still useless to you.

  Example: The Same Request, Engineered

  Write a 150-word explanation of what the Python programming language is,
  for complete beginners who have never written code.
  Include:

• What Python is used for (give 3 real examples)
• Why beginners often choose it as a first language Use simple language and avoid technical jargon. Format the answer as two short paragraphs.

  ### Example Explanation
  | Change | Why It Helps |
  |--------|--------------|
  | `Python programming language` | Removes the ambiguity about which "Python" is meant |
  | `for complete beginners` | Tells the model what level of knowledge to assume, which controls vocabulary and depth |
  | `150-word` | Controls length, so the output fits where it will be used |
  | `Include: ...` list | Defines the required content, so important points are not skipped |
  | `avoid technical jargon` | Sets a constraint on style |
  | `two short paragraphs` | Defines the output format |
  Nothing in the improved prompt is a "trick". It simply contains the information that was in the writer's head but missing from the first version. This is the core idea of prompt engineering: **transfer your intent from your mind into the prompt, explicitly**.
  ### What Happens Without Prompt Engineering
  When prompts are written carelessly, typical problems include:

• Off-target answers — the model solves a different problem than the one you had.
• Wrong level of detail — too basic for experts, too advanced for beginners.
• Unusable format — a paragraph when your code expects JSON, or a list when you needed a table.
• Inconsistent results — the same prompt produces different structures on different runs, which breaks automated processing.
• Invented information — when the model lacks the facts it needs, it may produce plausible-sounding but incorrect content (often called hallucination). Prompt engineering reduces each of these problems. It cannot remove all of them, as explained later in this lesson.

  ---

  How a Language Model Uses Your Prompt

  You do not need to understand neural networks to write good prompts, but a basic mental model explains why prompting techniques work. The next lesson covers this in depth; here is the essential idea.

  Text Is Processed as Tokens

  A model does not read text as whole words. It splits text into smaller units called tokens. A token can be a whole word, part of a word, a number, or a punctuation mark. For example, a common word may be one token, while a long or rare word may be split into several. Tokens matter for two practical reasons:

1. Limits — every model has a maximum number of tokens it can handle at once (the context window), covering both your prompt and its response.
2. Cost — API usage is usually billed per token, for both input and output.

   The Model Predicts What Comes Next

   At its core, an LLM generates a response one token at a time. At each step, it calculates how likely each possible next token is, given everything that came before: your prompt plus the part of the response it has already produced. It then selects a token and repeats the process. This has an important consequence:

   The prompt is the starting point for every prediction the model makes. If your prompt mentions beginners, tokens that fit a beginner explanation become more likely. If your prompt shows a JSON example, tokens that continue a JSON structure become more likely. Prompt engineering works because changing the input changes the probabilities that drive the output.

   Modern Models Are Trained to Follow Instructions

   Early language models simply continued text. If you wrote "The capital of France is", the model completed the sentence. Modern chat models are additionally trained to follow instructions and behave like assistants. This is why you can write direct commands such as "Summarize this article" and get a summary instead of a continuation of your sentence. Instruction-following is powerful, but it is not mind-reading. The model follows the instructions it receives; it cannot follow instructions you did not write.

   ---

   The Building Blocks of a Prompt

   Most effective prompts are assembled from a small set of components. Lesson 4 and Lesson 13 of this series cover them in detail; this table gives you the vocabulary you will see throughout the tutorial. | Component | Question It Answers | Example | |-----------|--------------------|---------| | Instruction | What should the model do? | Classify the following email. | | Context | What background does the model need? | The emails come from customers of an online course platform. | | Input data | What should the model work on? | The email text | | Output indicator / format | What should the answer look like? | Reply with one word: Billing, Technical, or Other. | Not every prompt needs every component. "What is the capital of Japan?" is only an instruction. A production prompt that classifies customer emails usually needs all four.

   Example: All Four Components Together

   You are helping the support team of an online course platform.   <- context
   Classify the customer email below into one category.            <- instruction
   Email:
   "I was charged twice for the Django course this month."          <- input data
   Answer with exactly one word: Billing, Technical, or Other.      <- output format

   Expected output:

   Billing

   Example Explanation

• The context tells the model what domain it is working in, so it interprets "charged" as a payment issue.
• The instruction defines the task as classification rather than, for example, writing a reply to the customer.
• The input data is clearly separated with the Email: label and quotation marks, so the model does not confuse the customer's words with your instructions.
• The output format restricts the answer to one of three words. This matters when a program reads the result: code can easily check if result == "Billing", but it cannot reliably parse a friendly paragraph. If you remove the output format line, the model may answer with something like "This email appears to be about a billing issue because the customer mentions a double charge." The classification is still correct, but your program now has to extract it from a sentence, which is fragile.

  ---

  Where Prompts Are Used: Chat Interfaces vs Applications

  Prompt engineering applies in two different situations, and it is useful to distinguish them early.

  1. Interactive Chat

  When you use a chat interface (such as ChatGPT, Claude, or Gemini), you write the prompt yourself, read the answer, and can immediately ask follow-up questions. Mistakes are cheap: if the answer is wrong, you clarify and try again.

  2. Applications That Call a Model Through an API

  When a developer builds a product feature with an LLM, the prompt is written once by the developer and then reused for every user request. The user often never sees the prompt. Examples include:

• A blog platform that generates SEO meta descriptions for every new article
• A helpdesk that summarizes and categorizes incoming tickets
• A coding tool that explains error messages
• An e-commerce site that extracts product attributes from supplier descriptions In this situation, there is no human correcting each answer. The prompt must handle every input correctly on its own. This is where prompt engineering becomes a core development skill.

  Comparison

  Aspect	Interactive Chat	Application (API)
  Who writes the prompt	The end user	The developer
  How often it is reused	Usually once	Thousands of times
  Error correction	User asks a follow-up	Must be handled by the prompt and code
  Output consumed by	A human reader	Often a program
  Format requirements	Flexible	Usually strict
  Testing needed	Minimal	Essential

  Example: A Prompt Inside a Python Application

  The following example shows how a prompt becomes part of real code. It uses the official OpenAI Python SDK and its Responses API, which OpenAI recommends for new projects. Requirements:

1. Python 3.8 or newer
2. The OpenAI SDK, installed with:

   pip install openai

3. An OpenAI API key stored in an environment variable named OPENAI_API_KEY. The SDK reads this variable automatically, so the key never appears in your source code.

   # macOS / Linux
   export OPENAI_API_KEY="your-api-key"
   # Windows (PowerShell)
   $env:OPENAI_API_KEY="your-api-key"

   Code (ticket_summary.py):

   from openai import OpenAI
   client = OpenAI()  # Reads OPENAI_API_KEY from the environment
   # Replace with any model that is available in your OpenAI account.
   MODEL = "gpt-5.4"
   INSTRUCTIONS = """You summarize customer messages for the support team
   of an online course platform.
   Respond in exactly this format and nothing else:
   Issue: <one sentence describing the problem>
   Category: <Billing | Access | Technical | Other>
   Urgency: <Low | Medium | High>
   If the message does not contain enough information for a field,
   write "Unclear" for that field."""
   def summarize_ticket(ticket_text: str) -> str:
    response = client.responses.create(
        model=MODEL,
        instructions=INSTRUCTIONS,
        input=f"<message>\n{ticket_text}\n</message>",
    )
    return response.output_text
   if __name__ == "__main__":
    ticket = (
        "I paid for the Python course yesterday but it still shows as locked. "
        "My exam is on Monday, please help!"
    )
    print(summarize_ticket(ticket))

   Run it:

   python ticket_summary.py

   Possible output:

   Issue: The customer paid for the Python course but still cannot access it.
   Category: Access
   Urgency: High

   The exact wording varies between runs and between models, but the structure should stay the same because the prompt defines it explicitly.

   Code Explanation

   client = OpenAI() Creates the API client. With no arguments, it looks for the OPENAI_API_KEY environment variable. Keeping keys in environment variables instead of source code prevents them from being committed to Git by accident. MODEL = "gpt-5.4" Selects which model processes the prompt. Model names change over time as providers release new versions, so check the model list in your account and the provider's documentation. Keeping the model name in one variable makes it easy to change later. INSTRUCTIONS This is the engineered part of the prompt. It is written once and reused for every ticket. It contains:

• Context — the model is summarizing messages for a support team of a course platform.
• Output format — three labeled lines with fixed allowed values for Category and Urgency. Fixed values make the output easy for code to process, for example to route Billing tickets to the finance team.
• A rule for missing information — write "Unclear". Without this rule, the model might guess a category when the message is vague. Telling it what to do when information is missing reduces invented answers. instructions=INSTRUCTIONS In the Responses API, the instructions parameter carries guidance that applies to the whole request, similar to a system message in chat-based APIs. The model treats it as higher priority than the content in input. This separation matters: your rules stay in instructions, while user-provided text goes into input. input=f"<message>\n{ticket_text}\n</message>" The customer's text is wrapped in <message> tags. These tags act as delimiters: they mark exactly where the customer's text begins and ends. This helps the model treat the message as data to summarize rather than as instructions to obey. (Delimiters are covered in detail in Lesson 37.) response.output_text A convenience property in the SDK that returns all the text the model generated as a single string.

  What Happens If You Change Parts of This Prompt?

  Change	Likely Effect
  Remove the format block	Output becomes a free-form paragraph; code that expects Category: breaks
  Remove the allowed values <Billing | Access | ...>	The model invents categories such as "Payment Issue" or "Login Problem", making routing inconsistent
  Remove the "Unclear" rule	Vague messages get guessed categories that may be wrong
  Remove the <message> tags	Usually still works, but a message containing text like "Ignore the format above" is more likely to confuse the model
  Put everything into input instead of instructions	Usually still works, but your rules and the user's text are no longer clearly separated

  This kind of reasoning — predicting how each part of a prompt affects the output, then verifying it by testing — is what prompt engineering looks like in practice.

  Note: The OpenAI SDK also provides the older Chat Completions API (client.chat.completions.create) with a list of system and user messages. It is still supported, but the Responses API is the recommended choice for new projects. The prompting principles in this tutorial apply to both APIs and to other providers.

  ---

  Model Settings That Influence Output

  The prompt is not the only thing that affects a model's answer. When you call a model through an API, you can usually configure generation settings. They do not change what you ask; they change how the model chooses its next tokens.

  Temperature

  Simple meaning: Temperature controls how predictable or varied the response is. Technical meaning: Temperature adjusts the probability distribution over possible next tokens. A low temperature makes the most likely token even more likely to be chosen, producing focused and repeatable answers. A higher temperature flattens the distribution, so less likely tokens are chosen more often, producing more varied and creative answers. | Temperature | Behavior | Good For | |-------------|----------|----------| | Low (close to 0) | Focused, predictable | Classification, extraction, factual Q&A, code | | Medium | Balanced | General writing, explanations | | High | Varied, creative, less predictable | Brainstorming, story ideas, slogans |

  Top P (Nucleus Sampling)

  Simple meaning: Top P limits the model to choosing from its most likely options. Technical meaning: With top_p, the model considers only the smallest group of candidate tokens whose combined probability reaches the value of top_p. A low value such as 0.1 restricts choices to the few most confident tokens. A value of 1 allows the full range. A widely followed recommendation is to adjust either temperature or top_p, not both, because both control randomness and changing them together makes the effect hard to predict.

  Maximum Output Length

  Most APIs let you limit how many tokens the model may generate (in the Responses API, this is max_output_tokens). This controls cost and prevents overly long answers. If the limit is too low, the response is cut off in the middle, which can break structured output such as JSON.

  Important Notes on Settings

  Note: Supported settings differ between models and providers. Some newer reasoning-focused models do not accept temperature or top_p at all and offer other controls instead. Always check the documentation for the specific model you use before relying on a setting. Note: Even at a temperature of 0, outputs are not guaranteed to be identical on every run. Treat low temperature as "much more consistent", not "perfectly deterministic".

  Settings vs Prompts

  Settings and prompts solve different problems:

• If the answer is about the wrong thing or in the wrong format, fix the prompt.
• If the answer is correct but too repetitive or too random, adjust the settings. Beginners often try to fix a vague prompt by changing temperature. This rarely helps, because the model is still guessing what you want; it is just guessing more or less randomly.

  ---

  What Prompt Engineering Can and Cannot Do

  Understanding the limits of prompting prevents wasted effort and wrong expectations.

  What Prompt Engineering Can Do

• Clarify the task so the model solves the right problem.
• Control format — lists, tables, JSON, fixed labels, word limits.
• Control tone and audience — formal, casual, beginner, expert.
• Improve reasoning on multi-step problems through techniques such as asking the model to work step by step (covered in the Chain-of-Thought lessons).
• Increase consistency across many inputs.
• Reduce unsupported claims by instructing the model to rely only on provided information and to say when information is missing.

  What Prompt Engineering Cannot Do

• Add knowledge the model does not have. A model cannot know your company's internal policies or events after its training data ends unless you provide that information. Providing relevant documents to the model at request time is called Retrieval-Augmented Generation (RAG) and is covered later in this series.
• Guarantee correctness. A well-designed prompt reduces errors but does not eliminate them. Important outputs, such as medical, legal, financial, or security-related content, still need verification.
• Guarantee security. Instructions in a prompt can be undermined by malicious input, a problem called prompt injection. Prompts are one layer of defense, not a complete security solution. This is covered in the Prompt Safety lessons.
• Overcome hard capability limits. If a model is fundamentally unable to perform a task well, rewording the prompt has limited effect. A more capable model, a different approach, or additional tools may be required.

  ---

  Prompt Engineering vs Fine-Tuning vs RAG

  These three approaches are often confused because all of them aim to improve model output. They work at different levels. | Aspect | Prompt Engineering | RAG | Fine-Tuning | |--------|--------------------|-----|-------------| | What changes | The input text | The input text, plus automatically retrieved documents | The model's internal weights | | Main purpose | Clarify task, format, and behavior | Supply current or private knowledge | Teach a consistent style or specialized behavior | | Required skills | Clear writing, testing | Prompting plus search/database engineering | Machine learning workflow, dataset preparation | | Required data | None, or a few examples | A document collection | Many high-quality training examples | | Cost to start | Very low | Medium | Higher | | Speed of iteration | Minutes | Hours to days | Days to weeks | | Adds new knowledge | Only what you paste into the prompt | Yes, from your documents | Not reliably; better for behavior than facts |

  How to Decide

1. Start with prompt engineering. It is the fastest and cheapest approach, and many problems are solved here.
2. Add RAG when the model needs information it does not have, such as your product documentation, recent data, or private records.
3. Consider fine-tuning when you need highly consistent behavior across a very large number of requests and prompt engineering with examples is not enough. These approaches are not alternatives you choose between permanently. Real systems often combine them: a RAG system still depends on a well-engineered prompt to tell the model how to use the retrieved documents.

   ---

   Real-World Uses of Prompt Engineering

   Prompt engineering is used wherever LLMs are part of a workflow. Some realistic examples: | Domain | Task | What the Prompt Must Control | |--------|------|------------------------------| | Content publishing | Generate meta descriptions for blog posts | Length limit, keyword inclusion, no exaggerated claims | | Customer support | Classify and summarize tickets | Fixed categories, consistent format, handling of vague messages | | Software development | Explain error messages or generate unit tests | Programming language, framework version, test style | | Education | Generate practice questions from a lesson | Difficulty level, question type, answer key format | | E-commerce | Extract product attributes from descriptions | Exact field names, JSON structure, missing-value rules | | Data analysis | Convert plain-language questions into SQL | Correct table and column names, read-only queries | | Internal tools | Answer employee questions from policy documents | Use only provided documents, cite the source section, admit when the answer is not present | In each case, the same pattern repeats: the prompt must state the task, provide the necessary context, separate the input data, and define an output that people or programs can use reliably.

   ---

   Common Misconceptions and Mistakes

   Mistake 1: Believing in "Magic Words"

   What it is: Searching for secret phrases that supposedly unlock better answers, and copying "ultimate prompts" without understanding them. Why it happens: Viral prompt collections present prompting as a set of tricks. What it causes: Prompts that work by coincidence on one example and fail on others. When they fail, you do not know why. How to fix it: Focus on clarity of task, context, input, and output format. Effective prompts are usually clear rather than clever.

   Mistake 2: Assuming Longer Is Always Better

   What it is: Adding more and more text to a prompt in the hope of improving it. Why it happens: Since missing information causes poor results, it seems logical that more information is always better. What it causes: Important instructions get buried among irrelevant details. Contradictory instructions appear. Costs and response times increase. How to fix it: Include information only if it changes the output. For each sentence, ask: "Would the answer be worse if I removed this?" If not, remove it.

   Mistake 3: Testing With Only One Input

   What it is: Writing a prompt, trying it once, and deciding it works. Why it happens: In a chat, one good answer feels like success. What it causes: The prompt fails in production on inputs that are shorter, longer, messier, in another language, or unusual in some way. How to fix it: Test every reusable prompt against several realistic inputs, including difficult edge cases: empty input, very long input, irrelevant input, and ambiguous input. Prompt testing is covered in the Prompt Evaluation lessons.

   Mistake 4: Treating Model Output as Verified Fact

   What it is: Publishing or acting on AI output without checking it. Why it happens: Model responses are fluent and confident, which makes them sound reliable. What it causes: Incorrect facts, invented references, or wrong code reach real users. How to fix it: Verify important claims against reliable sources, test generated code, and keep a human review step for high-impact content.

   Mistake 5: Mixing Instructions and Untrusted Data

   What it is: Inserting user-provided text directly next to your instructions with no separation. Why it happens: Simple string concatenation is the quickest way to build a prompt. What it causes: The model may confuse data with instructions. A user can write text such as "Ignore previous instructions and..." and change the model's behavior. How to fix it: Keep instructions and data in clearly separated sections, use delimiters, and pass rules through the instruction or system channel when the API provides one, as shown in the Python example above.

   Mistake 6: Expecting One Prompt to Work Everywhere Forever

   What it is: Assuming a prompt that works with one model will behave identically with another model or a newer version. Why it happens: Prompts look like plain language, so they seem universal. What it causes: Unexpected changes in output style, length, or format after switching or upgrading models. How to fix it: Re-test prompts whenever you change models or model versions, and keep a record of which prompt version was tested with which model.

   ---

   Best Practices for Getting Started

   Start simple, then refine. Write the simplest prompt that describes the task, observe the output, and add only what is needed to fix specific problems. This makes it clear which change caused which improvement. Be specific about the task. Use precise action verbs such as summarize, classify, extract, translate, or rewrite instead of vague ones like handle or deal with. Provide the context the model cannot guess. State the audience, purpose, domain, and any rules that apply. If you would need to explain it to a new colleague, the model needs it too. Define the output format explicitly. If a program reads the output, specify the exact structure and allowed values. If a person reads it, specify length and layout. Tell the model what to do when information is missing. Rules such as "If the answer is not in the text, reply 'Not found'" reduce invented answers. Separate instructions from input data. Use labels, delimiters, or the API's instruction/system channel so that data is never mistaken for instructions. Test with varied, realistic inputs. A prompt is only as reliable as the range of inputs you tested it with. Version your prompts. For application prompts, store them in version control with your code. A one-word change can affect thousands of outputs, so changes should be tracked and reviewable. Keep humans in the loop for important outputs. Use prompt engineering to make outputs better and more consistent, and use human review for decisions with real consequences.

   ---

   Try It Yourself

   Use any AI chat tool for this exercise. The goal is to observe how each improvement changes the output.

   Step 1: Start With a Weak Prompt

   Give me some interview questions.

   Run it and note the problems. You will likely get generic questions for an unspecified job, at an unspecified level, in a format you did not choose.

   Step 2: Add the Task Details

   Give me 5 interview questions for a junior Django developer position.

   What changed: The role, technology, and level are now specified, so the questions become relevant.

   Step 3: Add Context and Purpose

   I am preparing for an interview for a junior Django developer position
   at a small web development agency. I know Python basics and have built
   two Django projects with user authentication.
   Give me 5 interview questions I am likely to be asked.

   What changed: The model now knows your experience level and the type of company, so it can choose questions that match a realistic interview at that level.

   Step 4: Define the Output Format

   I am preparing for an interview for a junior Django developer position
   at a small web development agency. I know Python basics and have built
   two Django projects with user authentication.
   Give me 5 interview questions I am likely to be asked.
   For each question, provide:

4. The question
5. Why interviewers ask it (one sentence)
6. A short model answer suitable for a junior developer Mix technical Django questions with one question about teamwork.

   **What changed:** The output now has a predictable structure, includes explanations that help you prepare, and has a specified balance of question types.
   ### What to Observe
   Compare the four outputs and notice:

• Which step produced the biggest improvement in relevance?
• Which step made the output most useful for your actual goal?
• Did any step make the output worse or unnecessarily long? Then run the Step 4 prompt two or three more times. The questions will differ between runs, but the structure should remain the same. This illustrates an important principle: a well-engineered prompt does not force identical answers, but it makes the shape and quality of answers consistent.