Skip to content
AtomicReps

Say the thing you want

A lesson from Working With AI: Context, Tools, Agents and Evals. Play it above, or read it through below.

Level I · What You Send to the Model
  • Say what you want, not who to be

    The common read: A detailed expert persona focuses the model on the right knowledge, so opening with twenty years of experience is worth the tokens it costs.

    The elaborate persona is rarely the part that improves the reply. Anthropic's current reference gives role prompting two sentences: a role in the system prompt focuses Claude's behaviour and tone, and even a single sentence makes a difference. Its only example is the whole system prompt: "You are a helpful coding assistant specializing in Python." The blog that covers the technique warns that an over-specific role can limit the model's helpfulness rather than focus it.

    What replaced it is stating the outcome. The docs' golden rule is to show your prompt to a colleague with minimal context and ask them to follow it, on the argument that if they would be confused the model will be too. Their worked example sets "Create an analytics dashboard" against "Create an analytics dashboard. Include as many relevant features and interactions as possible. Go beyond the basics to create a fully-featured implementation."

    A common failure is a review thread where two engineers argue about which persona works better, on a prompt whose actual defect is that neither version says what the output should contain. Delete the persona and write the acceptance criteria. The specific request is the part that generalises, and the guidance states it directly: if you want above-and-beyond behaviour, request it explicitly rather than relying on the model to infer it from a vague prompt.

  • Give a reason, not emphasis

    The common read: An instruction in capitals with MUST in it is how you get a rule followed, so the strongest wording is the safest wording.

    The capitals compensated for a model behaviour that has since changed. The reference says Claude Opus 4.5 and 4.6 are more responsive to the system prompt than previous models, that prompts written to stop a model underusing a tool may now make it overuse one, and that the repair is to write Use this tool when... where you used to write CRITICAL: You MUST use this tool when.... The capitals are not neutral: they tell the model to weight that rule more, and current models do.

    What does still improve compliance is a reason. Against NEVER use ellipses, the docs put: "Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." The docs' stated benefit is generalisation, because a rule whose reason is stated extends to cases nobody enumerated, and no amount of capitalisation does that.

    A common failure is a bug filed against a model upgrade, "it has started calling the database for things it already knows", on a team whose config changed by zero lines because the offending line was written in 2024. Re-read your all-caps rules first. Anthropic names the ones written to stop a model skipping a tool as the ones that may now make it call that tool too often.

  • Your formatting is an instruction you did not mean to give

    The common read: The model reads my prompt for its content, so how I lay the prompt out is a matter of my own convenience.

    Name what a markdown-heavy prompt does to the reply, then read on.

    It may produce a markdown-heavy reply. The docs say your prompt's formatting style may influence the response style, and removing markdown from your prompt can reduce markdown in the output. The same page, read 2026-08-27, says Claude's latest models default to LaTeX for maths. Two pages disagree on length: the best-practices page says the latest models are less verbose than earlier ones, and Anthropic's Claude Opus 5 page says Opus 5's default replies run longer than earlier Opus ones. Put the length you want in the prompt.

    A common failure is a complaint that the assistant "answers everything in bullet points now", filed against a model version, by someone whose own prompt template is a heading and a bullet list. Write the prompt in the layout and tone you want the answer in. Matching the layout is the cheapest change in this lesson: it adds no instruction and only changes how the existing ones are written.

  • Prompting advice goes out of date before the model does

    The common read: Prefilling the assistant turn is a property of how the model continues text, so it is a technique the vendor cannot withdraw.

    Prefill on the last assistant turn now returns a 400. The migration note is precise about the boundary, which is worth reproducing rather than summarising: prefilled responses on the last assistant turn are no longer supported starting with Claude 4.6, requests carrying them return a 400 error, earlier models still support prefills, and assistant messages elsewhere in the conversation are not affected. The position of one message in the array decides whether the request works or is rejected.

    The documented replacements are not stronger wording. For a format, structured outputs constrains the response to a schema. For a preamble, the replacement is a direct system-prompt instruction plus post-processing. For a continuation, move the interrupted text into a user message and ask the model to continue from it. None of the three is a louder instruction: one is an API feature, and the other two are plain instructions in a different place.

    The case that never gets a bug report is the prompt file nobody re-read: it still opens with a persona and still has one rule in capitals. Neither line causes an error; the replies just get worse. Date your prompt techniques. Every one of them was true when someone learned it, most of the ones that stopped being true fail silently, and a prefill on the last assistant turn is the rare one that fails loudly, with a 400.

  • Say the thing you want, not the thing you fear

    The common read: A prohibition is the tightest way to express a constraint, so writing down what must not happen is the safest instruction I can give.

    Predict what a "do not use markdown" instruction leaves unsaid, then read on.

    It leaves the target unsaid: the instruction rules out one format and does not name the format you want. The docs' first steering technique is to tell the model what to do instead of what not to do, and their example is short: against "Do not use markdown in your response" they put "Your response should be composed of smoothly flowing prose paragraphs." Only the second sentence describes the output you want.

    Examples carry a similar risk. The docs recommend three to five, wrapped in tags and diverse enough that the model does not pick up unintended patterns. Anthropic's July 2026 write-up reports a narrower finding: on its newest models, examples of tool use "constrains them to a certain exploration space", so it recommends more expressive tool parameters instead, such as a status enum of pending, in_progress and completed. The reference docs still call examples one of the most reliable ways to steer output format, tone and structure.

    A common failure is an agent that solves every task the same way: the team files the behaviour as a creativity problem, and the cause is five examples that share a structure nobody noticed writing. State the outcome and vary the examples. Both rules have one basis: describe the output you want, and make the examples differ in everything you do not care about.

  • Cut the prompt before you add to it

    The common read: A longer prompt covers more cases, so the safest thing to do with a prompt that is not working is to add to it.

    Guess how much of its own system prompt Anthropic deleted, then read on.

    Anthropic deleted over eighty percent. The 2026 write-up on its newest generation reports removing over eighty percent of Claude Code's system prompt with no measurable loss on their coding evaluations, and gives the diagnosis in the same paragraph: they had been overconstraining the model, through the system prompt and through instruction files and skills. The report comes from a vendor describing its own product, and it is the strongest available evidence for a claim most prompt authors resist.

    The same write-up says what the extra text cost. Reading their own transcripts, they found conflicting messages inside a single request, with the system prompt, the skills and the user's request clashing. Anthropic reports that the model usually still reached the right answer, and spent more thinking to resolve the conflict.

    The case that never gets a bug report is a prompt that has grown for a year and that nobody has tested by removing a paragraph. Cut before you add: prompt text that changes no output only costs tokens. The thank-you at the bottom of the long prompt in the figure is Loop's. Loop has been polite to the model for a year and never checked whether that changed the reply. Nobody has, Loop is keeping it, and this course is not going to argue.