Prompt iteration works best when you bring a reusable template, concrete failure cases, and an evaluation set to test each change.
2
Claude generally follows instructions more closely near the bottom of a prompt, while examples often improve tone and task behavior more than elaborate wording does.
3
Simple code is often more reliable than prompting for formatting, such as using assistant prefills, XML tags, regular expressions, and API stop sequences.
Summary
Zack Witten runs a live prompt workshop using examples submitted by the audience. He tests prompts in the Anthropic console, edits them, and reruns evaluation cases to see whether the changes help. The examples cover concise medical-agent replies, JSON output, spreadsheet extraction, social-media writing, role-play personas, image reading, translation scoring, and hallucination reduction. Witten recommends clearly separating prompt sections, often with XML tags, putting information before instructions in some cases and instructions after long documents, and using short, plain sentences. He puts particular weight on carefully chosen positive and negative examples. For JSON, he recommends assistant prefills and post-processing instead of relying on repeated instructions. For difficult judgments, such as translation quality, he suggests examples for each score and advance reasoning, while admitting that model grading can be inconsistent. His advice is practical and candid about where prompt changes stop helping and code or better test data should take over.
A prompt workshop needs failure cases, not just a prompt template
Witten asks participants to submit a prompt template with variables marked by double brackets, along with examples where the prompt misbehaves. He uses those examples to decide what to change and tests the result in the Anthropic console. The console's evaluate tab lets him add multiple test cases and rerun them after editing the prompt. He describes this as the same kind of iteration he does internally in team Slack, except the audience can see the trial and error. The emphasis is on testing against the behavior that matters instead of judging a prompt from one attractive response.
Clear structure matters more than decorative formatting
Witten cleans up the first prompt by separating its information, instructions, and user input with XML tags. He says Claude saw a great deal of XML during training, so XML can work somewhat better than other formats, although the deeper point is simply to separate prompt sections clearly. He also says instructions tend to be followed more closely when they are nearer the bottom of the prompt. This is a general rule to test rather than an absolute law. Capitalization, grammar, and typos may affect performance, but Witten presents that advice as partly anecdotal and says careful writing does not hurt.
Specific length ranges work better than the word 'concise'
When a medical-agent prompt produces replies that are too long, Witten replaces the broad instruction to be concise with a sentence range. He explains that concise depends on context. A concise book review might still fill a page, while a concise answer in a short interaction could be one sentence. The workshop tries two to four sentences, then one to two sentences, and finally a limit of no more than three. The outputs become shorter while still varying in length between cases. Witten also says a long prompt does not automatically require a long response, although context can influence the result.
Assistant prefills and code are reliable ways to control JSON
For a prompt that must return JSON, Witten demonstrates an assistant prefill through the Claude API. The application places the beginning of the assistant response in the conversation, such as an opening JSON structure, so Claude continues from an already-started format instead of adding a preamble. A closing JSON tag can also make extraction easy. Witten recommends parsing the tagged content with a small amount of post-processing, and using an API stop sequence to stop after the closing tag. He argues that simple code is often cheaper and more predictable than adding many prompt instructions. The prefill is available by putting an assistant message last in the messages list.
Examples shape style and task behavior better than extra prose
For social-media writing, Witten gets only limited improvement from instructions such as 'engaging' and 'not cringe.' He recommends building a library of strong examples instead. One approach is to have Claude generate many candidate tweets, select the ones a person likes, edit them, and pair them with the source documents. These document-and-output pairs can then become examples in the prompt. He says this work often produces more improvement than the other prompt-writing techniques discussed. Positive examples should be included, and negative examples can help when they contrast a poor output with a good one for the same document. He prefers fewer high-quality examples to many weak or truncated ones.
Application code should route multi-persona conversations
For a prompt that simulates several personas, Witten recommends writing a separate prompt for each persona and using application logic to route each user message to the appropriate one. He sees dynamic routing as easier to control than asking one large prompt to decide which persona should answer. In the live console, the audience uses role and persona controls to switch between synthetic users, but Witten distinguishes that demonstration from how he would build the system through the API. He also suggests prefacing each response with the current persona's name in brackets when that makes the speaker identity clearer. He tests a small instruction to keep the persona in character and avoid unnecessary explanation.
Witten says positive instructions are generally preferable, especially because repeating a prohibition can draw attention to the very behavior being prohibited. He compares this to telling a child not to eat prunes: repeating the prohibition can create more interest and pushback. He does not reject negative prompting. He recommends stating the constraint once and moving on rather than emphasizing it repeatedly. In the persona example, a short instruction to stay in character works better than a longer explanation about what the persona should not say. He also says counterexamples are useful tools, but he would pair them with positive examples rather than use negative examples alone.
Hard evaluation checks should use code when possible
Witten prefers code-based checks for formatting because they avoid another model call. If the requirement is that output is valid JSON or that text appears inside summary tags, a parser or string check can verify it directly. He reserves model grading for softer qualities where code cannot easily decide the result. For translation scoring, he recommends examples for every category in the rubric, including explanations before each score, and warns that a one-to-five scale is not necessarily well calibrated. He suggests limiting the number of categories. For hallucination-prone summaries, his main suggestion is to make the model extract relevant quotes first, then use those quotes to support the summary.
"I think in reality most of the gains of writing a good prompt is literally just picking the perfect document that goes here, picking the perfect set of tweets that go here."51:36
Who should watch
You are iterating on prompts but lack representative examples and a repeatable way to compare revisions.
Your application needs dependable JSON or tagged output and you are currently trying to enforce it with instructions alone.
You are evaluating summaries, translations, personas, or image inputs and want practical limits on what prompting can fix.
