By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
CHAPTERS
Chapter summaries
What prompt engineering is, and what you’ll build in this session
Hannah Moran defines prompt engineering as writing clear instructions, providing necessary context, and arranging information to get the best model result. She sets expectations for a hands-on walkthrough where they’ll iteratively build a prompt for a real-world-inspired scenario.
- •Prompt engineering is how you communicate with a language model to get it to do what you want
- •Clear instructions and sufficient context are core to good prompting
- •Prompt structure and information arrangement affect output quality
- •The session will build a prompt step-by-step using a practical scenario
Scenario setup: analyzing a Swedish car accident form and sketch
Christian Ryan introduces the example: an insurance claims workflow with two inputs—a Swedish accident report form and a hand-drawn sketch of the collision. The goal is to pass these images to Claude to determine what happened and who is at fault.
- •The use case is a Swedish insurance company handling car claims
- •Inputs include a standardized accident report form and a human-drawn sketch
- •The task is to extract factual details from images and assess fault
- •They will test the approach live in the Anthropic console
Baseline attempt in Console: minimal prompt leads to wrong assumptions
Christian demonstrates a very simple prompt in the console using Claude 4 Sonnet with temperature set to zero. With insufficient context, Claude misinterprets the scenario and produces an incorrect read (treating it like a skiing-related incident), illustrating why better prompting is needed.
- •A minimal prompt is used to review an accident report and assign fault
- •Claude 4 Sonnet is run with temperature 0 and a large token budget
- •The model makes an “innocent mistake” due to lack of scenario context
- •Prompt engineering is framed as iterative and empirical
Recommended prompt structure for one-shot API tasks
Hannah outlines a structure designed for API-style, single-message prompts that should succeed without back-and-forth. She describes ordering: task description, content, detailed instructions, examples when helpful, and a final repetition of critical constraints.
- •For API use, aim for a single message that “nails the task”
- •Start with a task/role description, then provide the dynamic content
- •Add step-by-step instructions for how to perform the task
- •Optionally include examples, then repeat critical requirements at the end
Add task context + tone: keep outputs factual and avoid guessing
Christian explains why the earlier attempt failed and how adding task context reduces model guessing. He also emphasizes tone requirements—staying factual and only making an assessment when confident—then shows an updated prompt that correctly frames the problem as car-accident analysis.
- •Without context, the model must guess more and can misclassify the scenario
- •Tone constraints are added: factual, confident, and no guessing when uncertain
- •They review what the form and sketch contain (checkboxes, vehicle A/B, sketch)
- •The updated version identifies relevant checked items but still lacks enough form semantics to decide fault confidently
Provide stable background details in the system prompt (and add structure)
Hannah explains that since the form structure is constant, it’s ideal to include a full description of the form in the system prompt so Claude doesn’t re-derive it each time. She also highlights using structured formatting—especially XML tags—to help Claude reliably interpret and reference different prompt sections.
- •The form’s structure is constant, so its schema can be provided up front
- •Putting this in the system prompt reduces repeated interpretation effort
- •They describe form properties: language, layout (two columns), and row meanings
- •Add guidance that human markings can vary (circles, scribbles, imperfect X’s)
- •Delimiters like XML tags and Markdown improve organization and retrieval of details
Version 3 run: better form understanding leads to a confident fault assessment
After adding detailed form background, they rerun the prompt and observe Claude spending less time explaining the form and more time extracting relevant checked items and interpreting the sketch. With the extra context, Claude becomes confident enough to state that vehicle B is at fault based on the form and sketch.
- •With form schema provided, Claude narrates less about deciphering the form
- •Claude outputs a clearer list of what was marked and what the sketch depicts
- •The model’s confidence increases due to clearer expectations and structure
- •Claude concludes vehicle B is at fault using the available evidence
Few-shot examples and conversation history as additional steering tools
Christian discusses how examples (few-shot prompting) can strongly steer behavior, especially for tricky edge cases where humans know the right conclusion. He also describes when conversation history is helpful (more user-facing applications) and notes their demo doesn’t rely on it.
- •Examples are a powerful way to steer Claude on difficult or “gray area” cases
- •Examples can include representative data and the desired breakdown/interpretation
- •A feedback loop can add examples when the system fails on certain patterns
- •Conversation history can enrich context when building a user-facing experience
- •XML structure is emphasized as a reliable way to package examples and context
Add a task reminder + ordered instructions to reduce hallucinations
Hannah adds a final reminder section that reinforces constraints like not inventing details and admitting uncertainty when inputs are unclear. She also stresses that the sequence of analysis matters: extract facts from the form first, then interpret the sketch using that context, mirroring how a human would reason.
- •Reinforce: don’t invent details; only answer when confident
- •Require evidence-based claims tied back to what’s visible in the inputs
- •Specify analysis order: read the form carefully before the sketch
- •Have Claude list extracted facts, then interpret the sketch using those facts
- •They note instruction phrasing can affect verbosity (e.g., checking every box)
Output formatting: concise summaries and machine-parseable verdicts
Christian explains that real applications often need structured outputs suitable for storage and downstream processing. He demonstrates adding guidelines for concise summarization and requiring the final verdict to be wrapped in specific XML tags so the application can extract only what it needs.
- •Production systems often need “nitty-gritty” outputs, not full preambles
- •Add explicit guidelines: clear, concise, accurate summaries
- •Require a final verdict wrapped in dedicated XML tags for easy parsing
- •The iteration shows progress from incorrect scenario to confident, formatted output
- •Formatted outputs support downstream uses like analytics or database storage
Prefill responses and extended thinking as prompt-engineering aids
Christian introduces two additional techniques: prefilling output to force a desired structure (including JSON-like or tag-prefixed formats) and enabling extended thinking to give the model time to reason. He notes the thinking transcript can be inspected to understand model behavior and then baked into the system prompt for efficiency.
- •Prefill can force outputs to begin in a specific structured format
- •Structured outputs can be made easier to parse (e.g., JSON-serializable formats)
- •Extended thinking provides additional internal space for reasoning with “thinking” tags
- •Reviewing the reasoning transcript can reveal how the model interprets the data
- •Insights from extended thinking can be incorporated into the system prompt for improvement and token efficiency
Wrap-up: where to find them and what’s next at the event
They close by inviting attendees to ask questions afterward since there isn’t time for a live Q&A. Hannah mentions upcoming sessions and demos at the event and thanks everyone for attending.
- •They’ll be available after the session for questions about prompting
- •No Q&A in-session due to time constraints
- •Hannah mentions a later session on “Prompting for Agents”
- •They point attendees to an event demo and thank the audience
