Prompt Patterns and Anti-Patterns

A small set of prompt structures solves most tasks, and a smaller set of mistakes causes most failures. The reusable shapes, and the ones to avoid.

Most prompting problems are not novel. They are one of a handful of recurring shapes, and once you can name the shape you can reuse the solution. This is the same reason design patterns exist in software: not magic, just vocabulary for structures that keep working.

Below are the patterns worth internalizing and the anti-patterns that quietly wreck otherwise good prompts. All build on the basics.

Patterns that reuse

Role and task framing. Open by stating what the model is doing and for whom. “You are reviewing a pull request for security issues” narrows the output distribution before any content arrives. This is not flattery or persona theater — it sets context that makes the rest of the prompt easier to predict against. Keep it factual and specific to the task.

Instructions before content. Put the ask first, the material second. Models weight the framing when they read the data if the framing comes first. Reversed — a wall of text followed by a buried question — the early tokens were processed with no idea what mattered.

Output contract. State the exact shape you want: “Return a JSON object with keys summary and risk_level.” Vague requests get varied output. An explicit contract is the cheapest reliability gain available, and it pairs with real structured output enforcement when you need a guarantee.

Decomposition. For a task with several steps, ask for the steps. Either walk the model through them (chain-of-thought) or split into separate calls whose outputs feed each other. A single prompt asked to do five things at once does each of them worse.

Demonstration over description. Tone, style, and format are far easier to show than to specify. Two or three examples beat a paragraph of adjectives. Reserve prose for rules that examples cannot express, like hard constraints.

Escape hatch. Tell the model what to do when it cannot comply: “If the text does not contain a date, return null.” Without this, a model handed an impossible request will invent a plausible answer rather than decline.

Patterns for reliability

These matter once a prompt runs in production, not just in a playground.

Delimit untrusted input. Wrap user-supplied or retrieved text in clear markers and say the model should treat it as data, not instructions. This is your first, weak line of defense against prompt injection — necessary but not sufficient.

Positive instructions over negative. “Respond in one paragraph” works better than “do not write multiple paragraphs.” Negations describe a large space of forbidden things without pinning the desired one. State what you want, not the infinite set of what you do not.

Put the most important instruction last when it matters most. Models attend strongly to the end of the prompt. If one rule must hold, restating it right before generation begins is cheap insurance against a long prompt diluting it.

Anti-patterns

Politeness as instruction. “Please try to make sure you carefully consider…” adds tokens and no constraint. It reads as hedging, and hedged instructions produce hedged output. Say what you want plainly.

The kitchen-sink prompt. Ten rules, three examples, two personas, and a format spec crammed together. Each addition dilutes the rest. When a prompt stops improving as you add to it, the problem is usually that it is already overloaded — cut, do not append.

Conflicting instructions. “Be concise but thorough. Be creative but strictly factual.” The model splits the difference unpredictably. When two instructions pull apart, pick the one that matters and drop the other, or separate them into different calls.

Over-specified reasoning. Prescribing the exact reasoning steps for a task the model already handles well can lower quality by forcing it off its natural path. Use decomposition where it helps, not everywhere.

Assuming the model remembers. Each request is stateless. A rule you gave three prompts ago is gone unless it is in the current context. Prompts that reference “as I said before” against a fresh call reference nothing.

Untested prompt drift. A prompt edited repeatedly by hand, never compared against the version before, silently regresses. Treat prompts as code: version them and check changes against examples.

How to develop a prompt

The reliable loop is not “write the perfect prompt”. It is:

1. Start minimal — task, contract, one example.
2. Collect cases where it fails.
3. Add the smallest change that fixes a failure class, not a one-off.
4. Re-check that the change did not break earlier cases.

Most of the work is debugging against real failures, not composing up front. A prompt that grew from observed failures beats one written in a single sitting, because it encodes what actually goes wrong.

What to remember

• A few patterns cover most tasks: role framing, instructions-first, an output contract, decomposition, demonstration over description, and an explicit escape hatch.
• For reliability, delimit untrusted input, prefer positive instructions, and place the load-bearing rule last.
• Anti-patterns share a theme: adding tokens without adding constraint — politeness, kitchen-sink prompts, conflicting rules.
• Prompts are stateless and drift silently; version them and test changes.
• Develop prompts by fixing observed failure classes, not by composing the perfect prompt up front.

Next: In-Context Learning