Do these techniques work with every LLM?

Yes. Specificity, few-shot examples, chain-of-thought, role-setting, and output formatting work across GPT, Claude, Gemini, Llama, Mistral, and other models. They exploit the structure of how transformers process context, not quirks of a specific model version.

Is prompt engineering a real skill or just a fad?

The flashy title may fade, but the underlying skill, structuring inputs to get reliable outputs from AI systems, is a core part of building software with LLMs. As models improve, the prompts can get simpler, but the discipline of clear instructions, good examples, and explicit constraints will remain valuable.

How do I test whether my prompt is working?

Run the same prompt with 10 to 20 different inputs and check whether the outputs are consistently correct. If the model fails on certain edge cases, adjust the prompt (add an example of that edge case, add a constraint). This iterative testing process is essentially building an eval suite for your prompts.

What Is Prompt Engineering? Techniques That Survive Model Updates

Why prompt engineering matters

The same model can give you a brilliant answer or a useless one depending on how you ask. The model does not read your mind. It reads your tokens. If your prompt is vague, the output will be generic. If your prompt is specific, structured, and constrained, the output follows.

This is not about finding magic words. It is about clear communication. The same principles that make you a better writer, be precise, give context, set expectations, make you better at prompting.

Model-specific tricks (like "let's think step by step" boosting GPT-3.5 scores on benchmarks) decay with every update. The techniques below are structural, and they work because of how transformer models process sequential context.

Technique 1: Be brutally specific

The number one improvement you can make is replacing vague instructions with specific ones.

Before (vague):

Write a product description for our app.

After (specific):

Write a 2-paragraph product description for PesaPal, a payment gateway 
used by Kenyan e-commerce stores. 

Paragraph 1: What the product does (accept M-Pesa, cards, and bank 
transfers through one API). 
Paragraph 2: Who it is for (online stores selling to Kenyan customers 
who want to check out in KES). 

Tone: professional but not corporate. No buzzwords. 
Length: 80 to 120 words total.

The second prompt constrains the output in five ways: topic, structure, audience, tone, and length. The model has far less room to drift.

Technique 2: Show, do not just tell (few-shot prompting)

Instead of describing the format you want, show the model 2 to 3 examples. This is called few-shot prompting.

Classify each customer message into one of these categories: 
billing, delivery, product_question, complaint, other.

Examples:

Message: "I was charged twice for my order"
Category: billing

Message: "When will my package arrive in Mombasa?"
Category: delivery

Message: "Does this phone come with a charger?"
Category: product_question

Now classify:

Message: "The screen was cracked when I opened the box"
Category:

Few-shot examples are powerful because they implicitly communicate your classification logic, output format, and edge case handling without you having to write rules for every scenario. The model pattern-matches from the examples.

Two to three examples usually suffice. Adding more helps with complex or ambiguous tasks but increases token cost.

Technique 3: Ask for reasoning before the answer

For tasks that require logic, math, or multi-step reasoning, asking the model to show its work before giving the final answer improves accuracy.

A matatu owner in Nairobi charges KES 70 per trip. The matatu makes 
12 round trips per day (24 single trips). Fuel costs KES 8,000 per day. 
The driver gets 20% of total fares. The conductor gets 15% of total fares. 

What is the owner's daily profit?

Show your calculations step by step before giving the final answer.

Without the "show your calculations" instruction, the model often jumps to a final number and gets the arithmetic wrong. With it, the model writes out each step, catches its own errors mid-stream, and arrives at the correct answer more often.

This technique works because the model generates tokens left-to-right. When it writes out intermediate steps, those tokens become context for the next step. It is literally thinking on paper.

Technique 4: Set a role and constraints

The system prompt is where you define who the model is and what it should never do. This is especially important for user-facing applications.

// System prompt for a Kenyan real estate assistant
const systemPrompt = `You are a helpful assistant for HouseFinder, 
a Kenyan property listing platform.

Rules:
- Only answer questions about Kenyan real estate.
- If asked about properties outside Kenya, say you only cover Kenya.
- Quote prices in KES. Never convert to USD unless asked.
- If you do not know the answer, say "I don't have that information" 
  instead of guessing.
- Never recommend specific agents or brokers by name.
- Keep responses under 200 words unless the user asks for detail.`;

Explicit constraints ("never," "only," "if X then Y") are more reliable than hoping the model infers boundaries from vague instructions. State what the model should do, what it should refuse, and what format to use.

Constraints in the system prompt apply to every message in the conversation. Constraints in the user prompt apply only to that turn.

Technique 5: Specify the output format

If you need structured data from the model, specify the exact format. Do not leave it to chance.

Extract the following fields from this M-Pesa confirmation message 
and return them as JSON:

Message: "RCA3B7X1KD Confirmed. Ksh2,500.00 sent to Jane Wanjiku 
0712345678 on 4/8/26 at 2:15 PM. New M-PESA balance is Ksh1,230.50."

Return a JSON object with these exact fields:
{
  "transaction_id": string,
  "amount": number (in KES, no commas),
  "recipient_name": string,
  "recipient_phone": string,
  "date": string (ISO 8601),
  "balance": number (in KES, no commas)
}

Return ONLY the JSON. No explanation, no markdown fences.

The more precisely you define the output structure, the more reliably the model follows it. For production systems, combine this with structured output modes (like OpenAI's JSON mode or function calling) to guarantee valid JSON.