# Prompt engineering that actually works (and what does not)

> Source: <https://dev.to/dev-into-space/prompt-engineering-that-actually-works-and-what-does-not-2hg9>
> Published: 2026-08-15 12:20:49+00:00

**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.

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.

**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](https://www.divyakush.com).

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](https://www.divyakush.com).

**Divyakush Punjabi** · Full-Stack & AI Engineer

[Portfolio](https://www.divyakush.com) · [GitHub](https://github.com/Divyakush2006) · [LinkedIn](https://linkedin.com/in/divyakush-punjabi)