arrow_backBack to field notes
AI Published 4 Aug 2026

Prompt Engineering Basics: A Practical Glossary Entry

A clear, no-fluff explanation of prompt engineering fundamentals, with examples and techniques you can use right away.

Prompt engineering is the practice of writing input text that gets a language model to produce the output you actually want. It sits somewhere between writing and debugging: you're not coding in the traditional sense, but you are testing hypotheses about how a model interprets instructions and iterating when it gets things wrong.

What a prompt actually is

A prompt is everything you send to a model before it generates a response — instructions, context, examples, and the actual question or task. Most modern chat models split this into roles: a system message (sets behavior and constraints), user messages (the actual request), and sometimes assistant messages (prior turns or examples). If you're using an API like OpenAI's or Anthropic's, you'll set these explicitly in code. If you're using a chat interface, the system prompt is often hidden or set once at the start of a conversation.

Why the same question gets different answers

Language models predict the next token based on everything that came before it, including your phrasing, word order, and even punctuation. Ask "Explain recursion" and you'll get a generic textbook answer. Ask "Explain recursion to a junior developer who understands loops but not recursion, using a single Python example with a base case and recursive case" and you'll get something far more useful. The specificity of your input directly shapes the specificity of the output. This is the core insight beginners need: the model isn't reading your mind, it's pattern-matching against your words.

Core techniques worth learning first

Zero-shot prompting means asking directly with no examples: "Write a regex that matches US phone numbers." This works fine for common, well-defined tasks.

Few-shot prompting means giving the model one or more examples of the input/output pattern you want before asking it to continue the pattern. If you want a model to classify support tickets into categories, showing it three labeled examples first will produce more consistent results than describing the categories in prose alone.

Chain-of-thought prompting asks the model to reason step by step before giving a final answer, often by literally adding "think step by step" or by asking it to show its work. This helps with math, logic, and multi-step tasks, though it also increases token usage and response length.

Role prompting assigns the model a persona — "You are a senior security engineer reviewing this code for vulnerabilities" — which can shift tone, vocabulary, and the kind of detail it prioritizes. It doesn't grant the model new capabilities, but it does anchor its output style.

Structure matters more than cleverness

Beginners often assume prompt engineering is about finding a magic phrase. In practice, structure beats cleverness almost every time. Break your prompt into clear parts: context, task, constraints, and format. For example:

Context: You're reviewing a Python Flask app for a security audit.
Task: Identify SQL injection risks in the code below.
Constraints: Only flag issues in the /login and /search routes.
Format: Return a numbered list with the line number and a one-sentence explanation.

This kind of explicit formatting reduces ambiguity and makes outputs easier to parse programmatically if you're chaining prompts together in a script.

Common mistakes early on

A frequent error is vagueness disguised as brevity — asking "make this better" without defining what "better" means (faster? more readable? more secure?). Another is stuffing a single prompt with five unrelated tasks, which tends to produce shallow answers to all five instead of a solid answer to one. Beginners also forget that models have no memory between separate API calls unless you explicitly pass prior conversation history back in, which trips people up when building anything stateful.

Testing and iterating like an engineer

Treat prompts like code you version and test, not one-off text you throw away. Keep a log of prompt variations and their outputs, especially for anything you'll reuse in production, like a customer support bot or a code review assistant. Small wording changes — "summarize" vs "summarize in exactly three bullet points" — can produce meaningfully different results, and the only way to know what works for your use case is to run the comparison yourself rather than assume.

Where this fits into building real things

Once prompts get reliable, the next step is usually programmatic use: calling an API with temperature and max_tokens settings tuned for your task, adding retry logic for malformed outputs, and validating responses before they hit a user. That's where prompt engineering starts overlapping with regular software engineering discipline, and it's a good point to move from experimenting in a chat window to writing actual scripts.

If you want to go further, check out Korra Studio's segments on working with LLM APIs in Python and on building small AI-powered tools from scratch.

Written with AI assistance, reviewed and published by Michal Pilch (CISSP), Korra Studio.

Ready to go further?

This is one note from the Korra Studio knowledge base — the platform pairs every topic with 1-to-1 mentoring.

Get started freearrow_forward