What makes a prompt actually work

There's no shortage of "10 prompt engineering tricks" content out there. Most of it is either trivially obvious ("be specific!") or unfalsifiable ("use emotional appeals!"). This is the actual short list of things that move output quality across every model.

The patterns hold whether you're prompting Claude, ChatGPT, Gemini, or a local model. They predate any specific model and will outlast any specific version.

The mental model

Treat the model as a brilliant but new employee who:

• Has read more than anyone you've ever worked with
• Has zero context on your company, your project, your norms
• Will guess at what you want if you don't tell them
• Wants to be helpful, sometimes to a fault — including by making things up rather than admitting it doesn't know

The "brilliant but new" framing is load-bearing. It tells you what to invest your time in:

• Not: explaining concepts the model already knows
• Yes: explaining your specific context, your output format, your constraints, and what success looks like

The colleague test

Before sending a prompt, read it as if a colleague got it cold — no context about you, your project, or what you've been working on. Could they:

• Tell what you want done?
• Tell what the output should look like?
• Tell what success looks like?

If a colleague would be confused, the model will be too. Most prompt failures are just instruction failures.

The five patterns that actually move quality

1. Be specific about the output format

The default model output drifts toward "essay." If you want something else — a table, a JSON object, a numbered list, three bullet points max — say so explicitly.

Less effective:

Summarize this meeting

More effective:

Summarize this meeting as:
- Decisions (3 max)
- Action items (each with owner + due date)
- Open questions

Max 200 words total. No preamble.

The second version eliminates 80% of the ways the output could disappoint you.

2. Add the why, not just the what

Models do better when they understand why you want something. Without the why, they'll make plausible-but-wrong defaults. With it, they can generalize.

Less effective:

Never use ellipses.

More effective:

Never use ellipses. The output will be read aloud by a text-to-speech engine that pronounces them as "dot dot dot."

The second version lets the model figure out edge cases (e.g. what to do with "...") instead of having to ask.

This pattern compounds. The more your prompt explains the intent behind each instruction, the better the model handles edge cases you didn't anticipate.

3. Use examples (when you can)

A few good examples will outperform a paragraph of description. This is called few-shot prompting. (See Few-shot examples: when they help, how to write them for the deep dive.)

The shortest version: if you want the output to look a particular way, show 1–3 examples of what you mean. The model will match the shape much more reliably than from a description alone.

4. State the role and audience

Telling the model who it is and who it's writing for sharpens the output. A 1-line role assignment changes the register, vocabulary, and depth of explanation.

Less effective:

Explain how rate limiting works.

More effective:

You are a senior backend engineer explaining rate limiting to a product manager who is debating whether to add it to their API. Be concrete about the failure modes that justify the work.

The second version makes about a dozen quality decisions automatically: what vocabulary to use, what to skip, what to emphasize.

5. State constraints up front

Length, tone, things to avoid, things to include — every constraint you don't specify is a guess the model has to make.

Less effective:

Write me a LinkedIn post about our launch.

More effective:

Write a LinkedIn post about our launch.

- Audience: senior engineers at SaaS companies
- Length: under 200 words
- Tone: technical, not hype-y
- Include: the specific problem this solves and why we built it now
- Avoid: emojis, "thrilled to announce," exclamation points, hashtag spam
- End: with a soft CTA (question, not "DM me")

The constraint list is half the prompt. That's how it should be.

The thing nobody tells you about "prompt engineering"

Most of the time, when a prompt fails, the problem isn't that you used the wrong technique. It's that you didn't bother to write the prompt carefully.

A 20-second prompt produces a 20-second-quality answer. A 5-minute prompt — one where you actually thought about format, audience, constraints, and what success looks like — produces a 5-minute-quality answer.

The leverage from prompt engineering isn't in finding magic words. It's in slowing down enough to specify what you actually want.

What to read next

• Structuring prompts with XML, roles, and sections — the formatting patterns that make long, mixed-input prompts work
• Few-shot examples: when they help, how to write them — the deep dive on the single highest-leverage technique
• How to verify AI output before you trust it — the other half of the workflow