What Is Prompt Engineering? Examples That Show It

Prompt engineering is the practice of writing and structuring input to a language model so it reliably produces the output you want. It's not a mystical skill — it's closer to writing a very precise spec for a very literal collaborator. The best way to understand it isn't through a definition, it's through examples of bad prompts versus good ones and seeing exactly what changed.

Below are real, concrete examples across common tasks: writing, summarization, coding, data extraction, and reasoning. Each one shows a weak prompt, why it fails, and a rewritten version that fixes it.

Example 1: Vague request vs. specified output

Weak prompt:

Write about our product launch.

This gives the model almost no constraints — no audience, length, tone, or format. You'll get generic marketing copy that could apply to any product.

Engineered prompt:

Write a 150-word LinkedIn post announcing the launch of our
API product, SubToAPI. Audience: backend developers who already
use Claude via chat but want programmatic access. Tone: direct,
technical, no hype. End with a one-line call to action pointing
to a signup link.

The difference is specificity: audience, length, tone, structure, and a defined ending. This is the core pattern of prompt engineering — replace ambiguity with explicit constraints.

Example 2: Adding a role and context

Weak prompt:

Review this code.

Engineered prompt:

You are a senior backend engineer doing a code review focused on
security and error handling, not style. Review the function below.
List issues as a numbered list with severity (high/medium/low) and
a one-line fix suggestion for each.

[code here]

Assigning a role narrows the model's focus and the requested output format (numbered list, severity, fix) makes the response usable without editing. This pattern — role + task + output format — appears constantly in production prompts, including the system prompts sent to APIs like SubToAPI's /v1/messages endpoint for consistent behavior across requests.

Example 3: Structured data extraction

Freeform prompts produce freeform text, which is hard to parse programmatically. If you're building something on top of a model's output, ask for structure explicitly.

Weak prompt:

Get the key details from this email.

Engineered prompt:

Extract the following fields from the email below and return
only valid JSON, no explanation:

{
  "sender_company": string,
  "requested_action": string,
  "deadline": string or null,
  "urgency": "low" | "medium" | "high"
}

Email:
[email text]

This is one of the most common real-world uses of prompt engineering: turning unstructured text into structured data your application can consume. Calling this through an API rather than a chat window matters here — you want the same JSON shape every time, at scale, without a human copy-pasting responses.

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4",
    max_tokens: 300,
    messages: [{ role: "user", content: extractionPrompt }]
  })
});

See /docs/messages for the full request format.

Example 4: Few-shot examples to fix inconsistent tone

Weak prompt:

Reply to customer support tickets in a friendly tone.

Without examples, "friendly" is interpreted differently every time. Few-shot prompting — showing 2–3 examples of input/output pairs — fixes this.

Engineered prompt:

Reply to support tickets using this style:

Ticket: "My order hasn't arrived, it's been 2 weeks."
Reply: "That's frustrating — 2 weeks is way too long. I've
checked your order and it's stuck in transit. I'm sending a
replacement today, no need to return the original."

Ticket: "Can I get a refund for a subscription I forgot to cancel?"
Reply: "Absolutely, that happens. I've refunded the last charge
and canceled the subscription so it won't renew again."

Now reply to this ticket:
Ticket: "The app crashes every time I open settings."

Few-shot examples anchor tone, length, and structure far more reliably than adjectives like "friendly" or "professional."

Example 5: Chain-of-thought for reasoning tasks

Weak prompt:

Should we increase our subscription price from €9 to €12?

Engineered prompt:

Analyze whether raising our Solo plan from €9 to €12/month is a
good idea. Think through this step by step:
1. Estimate likely churn impact
2. Estimate revenue impact assuming that churn
3. Consider competitive positioning
4. Give a final recommendation with confidence level (low/medium/high)

Asking the model to reason step by step before concluding produces more grounded answers on tasks involving tradeoffs, math, or multi-step logic, instead of jumping straight to a guess.

Why these patterns matter beyond chat

These examples work the same whether you're typing into a chat interface or calling a model through an API in production code. The difference is that in production, you need consistency: the same prompt should behave predictably across thousands of calls, support streaming for long responses, and let tools call external functions when needed. SubToAPI wraps your existing Claude access in a standard HTTPS API — with API keys, streaming, and tool use documented at /docs/tools — so the prompts you engineer in testing carry over directly into an application without rebuilding the integration layer. Check /docs/quickstart to see the request shape, or /pricing for plan details.

Turning examples into habits

The pattern across all five examples is the same: replace vagueness with specifics. Define the role, the audience, the format, the length, and — for anything programmatic — the exact schema you want back. Add examples when tone or style matters. Ask for step-by-step reasoning when the task involves judgment or tradeoffs. Prompt engineering examples are really just demonstrations of removing ambiguity one constraint at a time.

questions

Is prompt engineering just trial and error? Partly, but effective prompt engineering follows repeatable patterns — role assignment, output formatting, few-shot examples, and step-by-step reasoning — rather than random guessing.

Do these examples work the same in an API as in ChatGPT or Claude's chat UI? Yes. The prompting patterns transfer directly; what changes in an API context is that you also control structured output, streaming, and system-level instructions programmatically.

What's the fastest way to test prompt engineering examples like these? Start with a small, realistic input, write the weak version first, then add one constraint at a time — role, format, examples, reasoning steps — and compare outputs after each change.