Prompt engineering that actually works (and what does not)

Prompt engineering has a bad reputation because most of it is superstition. But underneath the "you are a helpful assistant" cargo-culting, there are a handful of techniques that reliably work — and they're grounded in how the model actually behaves.

Let me separate the real patterns from the folklore. These are the ones that move quality measurably, not the magic phrases people paste around without knowing why.

Why prompting works at all

A model predicts the next token conditioned on everything before it. Your prompt is that condition. So prompting isn't casting spells — it's setting up a context in which the desirable continuation is the most probable one. Every technique below is just a different way of doing that.

The techniques that actually move the needle

1. Be specific about the output, not just the task. Vague in, vague out. Don't ask for "a summary" — ask for "three bullet points, each under 15 words, focused on financial risk." You're narrowing the probability space toward exactly what you want.

2. Give examples (few-shot). Showing the model two or three input/output pairs is often worth more than paragraphs of instruction. The model is extraordinary at pattern-matching; demonstrate the pattern and it follows. This single move fixes more formatting problems than any amount of description.

3. Let it think before it answers (chain-of-thought). For anything involving reasoning, telling the model to work through the steps before giving a final answer measurably improves correctness. Rushing straight to an answer is where models make careless mistakes — the same as people.

4. Assign a role with purpose. "You are a senior security engineer reviewing this code" genuinely shifts the output — not because of flattery, but because it conditions the model toward a specific register and body of knowledge. Use it when the framing changes the answer; skip it when it's just decoration.

5. Decompose hard tasks. Instead of one prompt that does five things, chain five prompts that each do one. Each step is easier to get right, easier to test, and easier to debug — the same instinct that makes good software modular, which is how I approach everything I build.

What doesn't work

Politeness and threats. "Please" and "or you'll be penalized" are noise. Save your tokens.
Vague superlatives. "Give the best possible answer" tells the model nothing it can act on.
Over-stuffing. A prompt crammed with ten caveats often performs worse than a clean, focused one — the important instruction drowns.

The mindset

Stop thinking of a prompt as a wish and start thinking of it as a specification. The clearer and more constrained your spec, the more reliable the output. When a prompt underperforms, don't add magic words — add precision.

That shift, from incantation to specification, is the whole difference between prompt superstition and prompt engineering. More of how I apply it at www.divyakush.com.