Prompt engineering 101: a crash course for 2026

Our prompt engineering crash course on YouTube has been watched more than 200,000 times since 2023. It was recorded when GPT-3.5 was the model everyone was poking at, "let's think step by step" was a party trick, and half the internet was selling PDFs of magic prompt templates.

Four model generations later, most of that video still holds up. That's the interesting part. The models got dramatically better at guessing what you meant, which killed the tricks and left the fundamentals standing: say what you want, give the model what it needs to know, show it the shape of a good answer, and iterate.

So this is the crash course, rewritten for the 2026 model landscape. We'll cover the elements of a prompt, what prompts are actually good for, the tips that survived, the techniques that control output, the hacks worth keeping, and how to iterate. Then we'll get into the part almost no prompting guide covers: prompting is different when the model is listening to audio instead of reading text. If you work with speech-to-text or transcripts, the rules invert, and knowing where they invert saves you a lot of wasted effort.

The five elements of a prompt

A prompt can carry five things. None of them are mandatory — you can type half a sentence and let the model complete it — but a good prompt has at least one instruction or one question in it.

Mix and match them. The classic few-shot pattern is just examples plus a question with the answer left blank — you set up "Q: … A: Paris," then ask your real question in the same format and let the model fill in the pattern.

What changed since 2023: the output-format element got a real API. Instead of asking nicely for JSON and hoping, you pass a schema and get structured output back. If you're wiring prompts into production code, use the schema. Prose instructions about formatting are for humans.

What prompts are actually good for

The use-case list from the original crash course has held up almost perfectly. Summarization. Classification. Translation. Text generation and completion. Question answering, either open-ended or grounded in input you supply. Coaching, where you hand over a draft and ask how to improve it. Image generation, which in 2023 was a novelty bolted onto a couple of models and is now table stakes.

Two categories got added since:

• Extraction into structure. Pull entities, decisions, action items, or numbers out of unstructured text and return them as typed fields. This is where most production LLM work actually lives — it's less glamorous than chat and far more useful.
• Tool use and agents. The prompt no longer just produces text; it decides which function to call. That shifts the craft from wording to context: what the model knows about the user, the session, and the tools available.

Notice the pattern in both. The valuable prompts aren't clever. They're well-supplied.

Eight tips that still work

These are the guidelines from the original video, with 2026 annotations where the model landscape moved.

1. Be clear. One direct instruction or one unambiguous question. Ambiguity is still the single biggest cause of bad output.
2. Be concise. Long prompts aren't better prompts. Every sentence that isn't doing work is a sentence competing for the model's attention.
3. Supply the relevant data as context. If your application already knows something — the customer's name, the account tier, the meeting agenda — put it in the prompt instead of hoping the model infers it.
4. Show an example when the format matters. Few-shot is still the fastest way to communicate a shape you can't easily describe. Try it whenever you can describe the output better by demonstrating it than by explaining it.
5. Specify the output format. "Yes or no." "Bullet points." "A short answer, then your reasoning." Constraints make outputs comparable across runs, which is what makes evaluation possible.
6. Push the model toward being factual. "Answer only using reliable sources and cite them." "Select one or two quotations from the text to back up your claims." "If you don't know, say so." Grounding requirements reduce invention.
7. Align the prompt with the goal. If you want a conversation with a helpful support agent, set that scene: "This is a conversation between a customer and a polite, helpful customer support agent." Then start the conversation. Matching the prompt's framing to the outcome you want is unglamorous and works.
8. Use a persona when you want a specific voice. "You are a kind customer support agent" shifts register reliably. It does not make the model smarter — a persona is a style control, not a capability upgrade, and treating it as the latter is the most common beginner mistake.

Techniques for controlling the output

Once the prompt works, these are the dials:

• Length. "Write a 150-word summary." Word counts are approximate, but the direction is respected.
• Tone. "Write a polite response."
• Style. "Give me the summary as bullet points" versus "as one paragraph."
• Audience. "Explain this to a five-year-old." Still the fastest way to force plain language.
• Context depth. How much of what you know you actually pass in. This is a real decision, not a freebie — more context costs tokens and latency.
• Scenario framing. "You are a support expert handling a billing dispute."

Chain-of-thought prompting, and what happened to it

Chain of thought was the headline technique of 2023. You either demonstrated the reasoning in an example or appended "let's think step by step," and complex questions suddenly got answered correctly.

The classic demo: "I went to the market and bought 10 apples. I gave two apples to the neighbor and two to the repairman. I then went and bought five more apples and ate one. How many apples did I remain with?" You'd supply a worked answer — started with 10, gave away four, six left, bought five more, 11, ate one, 10 remain — and then ask your real question in the same shape.

In 2026, reasoning models do this internally. Telling a reasoning model to think step by step is mostly redundant, and on some models it makes things worse by constraining a process that was already running. The technique didn't die, though — it moved:

• Explicit decomposition still helps. "Follow these steps: 1) … 2) … 3) …" is not the same as "think step by step." You're specifying the procedure, not asking for deliberation, and that's still valuable when the procedure is non-obvious.
• Worked examples still help when the reasoning path is domain-specific — a pricing rule, a triage policy, a scoring rubric the model can't derive.
• Reasoning effort is a parameter now. Where you used to prompt for more deliberation, you configure it.

Four hacks worth keeping

The original crash course pulled four techniques from Anthropic's docs. Three of them are now standard practice and one has been absorbed into the models.

Let the model say "I don't know." Explicitly permitting non-answers — "answer only if you know; otherwise tell me you don't know" — remains one of the most useful sentences in prompting. Models default to producing an answer. You have to authorize the alternative.

Give the model room to think. The 2023 version was a scratchpad: instruct the model to write out relevant quotes first, in a space that won't be shown to the user, then answer. Extended thinking has largely replaced the hand-rolled version, but the underlying idea — extract evidence before concluding — is still the right structure for any grounded question-answering task.

Break complex tasks into subtasks. "Please follow these steps: step one, do this. Step two, do that. Finally, write the essay." Explicit decomposition beats one enormous request, and it makes failures debuggable — you can see which step went wrong.

Check comprehension. Give the context and the instruction, then ask "do you understand the instruction?" before letting the model proceed. This one is less about the model and more about you: if the model's restatement is wrong, your prompt is ambiguous. It's the cheapest prompt debugger there is.

How to iterate

Finding a good prompt is trial and error, and the trial part should be systematic:

• Try genuinely different prompts, not variations of one phrasing.
• When few-shot examples aren't landing, add a direct instruction alongside them. Examples plus instruction usually beats either alone — most people list examples and hope the pattern carries.
• Rephrase the instruction more concretely, or less. "Translate this" versus "translate from English to Spanish" can change the output entirely.
• Swap personas to see how style shifts.
• Vary the number of examples. More isn't always better; sometimes two well-chosen examples beat six.
• Change one thing at a time, and write down what you changed. A prompt you can't reconstruct isn't a result.

Prompting a speech-to-text model works differently

Here's where the general crash course stops being enough.

Everything above assumes the model reads your prompt and follows it. When you prompt a speech-to-text model, that assumption breaks. Our flagship async model, Universal-3.5 Pro, accepts a prompt — but the prompt isn't an instruction. It's a description of the audio.

The transcription instruction is built in and managed for you. Verbatim behavior, punctuation, and formatting are already optimized. Formatting and behavioral commands in the prompt are ignored. What the prompt does is prime the model for the vocabulary your audio is likely to contain.

Two mechanisms, and they're worth keeping straight:

• Contextual prompting (prompt) — a natural-language description of what the audio is about: the domain, the scenario, or the full details of the conversation.
• Keyterms prompting (keyterms_prompt) — an explicit list of terms you want recognized accurately, up to 1,000 words or phrases on async, 100 keyterms per session on streaming.

A two-second clip from a League of Legends interview transcribes as "And so look who I've been a dear." Add the prompt "League of Legends roles" and it becomes "In solo queue, I ban Azir." Nothing about the instruction changed. The model just knew what kind of sound to expect.

from assemblyai.prerecorded.v2 import Transcriber, TranscriptionConfig

audio_file = "https://assembly.ai/prompt-8"

config = TranscriptionConfig(
  language_detection=True,
  prompt="League of Legends roles",
)

transcriber = Transcriber(api_key="<YOUR_API_KEY>")
transcript = transcriber.transcribe(audio_file, config)

print(transcript.text)

Three levels of context, with the numbers

Contextual prompts work at three levels of specificity. Use the least specific level that covers your use case, then add detail when the audio contains names or terms the model can't otherwise know.

We benchmarked all three levels on 20,000 real voice agent calls. The gains are monotonic, and they're largest for exactly the entities each level describes. Every figure is a relative reduction versus no prompt:

Scenario context is the practical default — it only needs the kind of information any application already has, and it cuts word error rate about 10% while dropping name and place errors 16–21%. Detailed context is the upper bound: when your app can pass in the caller's name, the order ID, and the product, name errors nearly halve.

The counterintuitive result is in the second row. Hallucinated words go down as context goes up. Describing the audio makes the model less likely to invent content, not more, because the model stays grounded in what it actually heard. Context that turns out to be irrelevant doesn't corrupt the transcript — which means you can safely send the same call description with every session of a long conversation.

Three rules that follow from all this, and each one is the opposite of standard LLM advice:

• Describe, don't command. Write plain sentences about the recording. You're describing audio, not instructing a model.
• Don't stuff keywords into the contextual prompt. That's what keyterms_prompt is for. One block of prose in the prompt; the list goes in the list parameter.
• Start with nothing. Test with no prompt and no keyterms first. Add context only for the errors you actually see. Padding a keyterm list with common words invites overcorrection.

Prompting a live stream, mid-conversation

Streaming transcription takes the same two parameters, set when you open the WebSocket:

import json

CONNECTION_PARAMS = {
    "sample_rate": 16000,
    "speech_model": "universal-3-5-pro",
    "prompt": "Cardiology consultation about chest pain symptoms.",
    "keyterms_prompt": json.dumps(["Dr. Smith", "AssemblyAI", "ECG"]),
}

The part that has no equivalent in text prompting: you can update both mid-stream, without reconnecting. A voice agent that moves from identifying the caller to collecting payment can re-prime the model for the stage it's actually in.

# Update the contextual prompt as the conversation evolves
client.update_configuration(prompt="Now collecting payment details.")

# Replace or establish a new set of keyterms
client.update_configuration(keyterms_prompt=["Universal-3"])

# Remove keyterms and reset context biasing
client.update_configuration(keyterms_prompt=[])

A new keyterms array replaces the previous set entirely; an empty array clears context biasing and resets to default. New values take effect immediately for subsequent audio.

Universal-3.5 Pro Realtime adds a related parameter that isn't prompting at all but solves a similar problem: agent_context, where you pass your voice agent's own question so that short or mumbled replies — spelled-out account IDs, one-word confirmations, addresses — resolve correctly. Across 20,000 voice agent audio files, passing agent context cut word error rate 10.2%.

If you want the deeper, model-specific treatment of transcription prompts — verbatim controls, temperature, and per-industry prompt templates tested across 10,000-plus variations — that's covered in our practical guide to prompt engineering for Universal-3 Pro. This post is the general-purpose primer; that one is the product manual.

Prompting an LLM over a transcript

Once you have a transcript, you're back in familiar territory — with one wrinkle. Transcripts are long, messy, and full of disfluencies, and they'll blow past a naive prompt's context budget.

The LLM Gateway handles the plumbing: one API to Claude, GPT, Gemini, and more, with a transcript_id parameter that injects a transcript's text into your prompt wherever you put the literal tag {{ transcript }}.

curl -X POST "https://llm-gateway.assemblyai.com/v1/chat/completions" \
  -H "Authorization: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-2.5-flash-lite",
    "messages": [
      {"role": "user", "content": "hi there"},
      {"role": "assistant", "content": "Hi! How can I help?"},
      {"role": "user", "content": "Here is a transcript: {{ transcript }}. Return the text verbatim."}
    ],
    "transcript_id": "065a71ac-dc3e-4e38-9374-e54c0bea564f"
  }'

Only the first occurrence of the tag in the first message containing it gets substituted, and the tag has to be exactly {{ transcript }}, spaces included. Variants like {{transcript}} pass through untouched.

Four things to remember when the input is speech rather than writing:

• Tell the model it's reading a transcript. The original crash course made this point in 2023 and it's still true: "Here is a transcript of a podcast about generative AI" primes the model to expect interruptions, filler, and imperfect grammar instead of treating them as content.
• Ask for quotations as evidence. "Select one or two quotations from the transcript to back up each claim" is the single best anti-invention instruction for transcript work, because you can verify it against the source.
• Use speaker labels. Diarized transcripts let you ask speaker-scoped questions — "what did the customer commit to?" — which is usually what you actually want. See our walkthrough of summarizing meeting transcripts with LLMs for a worked example.
• Chunk long recordings deliberately. Summarize per topic or per speaker turn, then summarize the summaries. One 90-minute call in one prompt gets you a vague answer about the middle third.

Context beats cleverness here too, which is exactly what Metaview found when they moved their recruiting notetaker over:

"Since moving to AssemblyAI, we've seen a meaningful improvement in the confidence tail of our production transcripts....What stands out is not just the model quality, but the way [they] let us bring real meeting context into transcription, from calendar titles to organizations, domains, and participant names, so recruiting conversations come through with the nuance our customers depend on."

— Shahriar Tajbakhsh, Co-founder and CTO, Metaview

What prompt engineering became

The 2023 version of this skill was about wording. Find the phrasing, the persona, the magic suffix that unlocks the model.

That era is over, and the crash course we recorded then aged well precisely because it wasn't about tricks. What's left is a different job: deciding what the model should know, in what form, at what moment. Which is why the most valuable prompt in a modern speech pipeline isn't clever at all — it's the sentence describing who's on the call, and it works because your application already knew.

The skill isn't writing prompts anymore. It's plumbing what you know to where the model can use it. Start with nothing, add context only where you see errors, and measure every change. That's the whole discipline.

Frequently asked questions

What is prompt engineering in simple terms?

Prompt engineering is the practice of structuring the input you give an AI model so it returns the output you actually want. A prompt can carry up to five elements: an instruction, a question, input or context, examples, and a desired output format. Getting good at it means being specific about all five rather than searching for magic wording.

How should I learn prompt engineering?

Learn the five elements of a prompt, then practice on a task you can evaluate — summarizing your own notes, classifying your own support tickets — so you can tell whether a change helped. Change one variable at a time and record the result. Most people learn faster by building a small evaluation set of ten examples than by reading another list of prompt templates.

Does "let's think step by step" still work in 2026?

Mostly not, because reasoning models already do it internally, and on some models adding the phrase constrains a process that was already running. What still works is explicit decomposition — spelling out the steps of a procedure the model can't derive on its own — and supplying worked examples for domain-specific reasoning like a pricing rule or a triage policy.

What's the difference between contextual prompting and keyterms prompting?

Contextual prompting (prompt) is a short natural-language description of what the audio is about, and keyterms prompting (keyterms_prompt) is an explicit list of words and phrases you want recognized accurately. Use context when you can describe the conversation, and keyterms when you have a vocabulary list like contact names or a product catalog. On Universal-3.5 Pro you can use both together.

Can you prompt a speech-to-text model the way you prompt an LLM?

No — the prompt describes the audio rather than instructing the model. Transcription behavior, punctuation, and formatting are managed internally on Universal-3.5 Pro, so formatting and behavioral commands in the prompt are ignored. Write plain sentences about the recording instead, and put term lists in the keyterms parameter.

How much does prompting actually improve transcription accuracy?

Across a benchmark of 20,000 real voice agent calls, domain-level context cut word error rate 5%, scenario-level context cut it 10%, and detailed context cut it 21% versus no prompt. Entity accuracy improves even more sharply — detailed context reduced name errors 49% and place errors 44%. Hallucinated words dropped at every level, so more context made the model less likely to invent words, not more.

‍