Prompt engineering

In one line

Prompt engineering is the craft of specifying an LLM's task so precisely — role, instructions, context, examples, output format — that the model's behaviour becomes predictable enough to build on.

Why it's "engineering"

The same model can be brilliant or useless on the same task depending on how you ask. Because you usually can't retrain the model, the prompt is your main control surface — and treating it casually means unpredictable behaviour that breaks the moment you ship. Prompt engineering is the discipline of making that surface reliable.

Anatomy of a strong prompt

• System / role — who the assistant is and the rules it must follow ("you teach digital health; you never give patient-specific medical advice"). This is also where safety scope lives.
• Context — the grounding facts, often retrieved via RAG, clearly delimited from instructions.
• Instruction — the actual task, specific and unambiguous.
• Examples (few-shot) — one or more worked input→output pairs that show the pattern instead of describing it; usually the single highest-leverage technique.
• Output contract — the exact shape required (often a JSON schema), so downstream code never parses prose.

Techniques that move the needle

• Few-shot examples — demonstrate format and edge cases.
• Structured output — request JSON conforming to a schema; validate it.
• Chain-of-thought room — for reasoning tasks, let the model work step by step before the answer (then optionally hide the reasoning).
• Delimiters — fence context and user input clearly, which also blunts prompt injection.
• Explicit "I don't know" — instruct the model to abstain rather than invent.

Treat prompts as code

A production prompt is a versioned artefact: stored in source control, tested against an eval set, and changed deliberately. "Vibes-based" prompting dies at the first model upgrade — which is why prompt iteration is part of LLMOps.

Where it shows up in digital health

Every clinical AI surface is mostly prompt + grounding: discharge-summary drafters, coding suggestions, Vaidya's persona ("teach digital health, cite Kosha, adapt depth to fidelity, never give patient-specific medical advice"). In health the prompt is also a safety artefact — scope limits and refusal rules live there — which is why it's reviewed like one.

Common pitfalls

• Describing instead of demonstrating — a single good example often beats a paragraph of rules.
• Mixing instructions and untrusted context — without delimiters, retrieved text can hijack the task.
• No output contract — parsing free-form prose downstream is fragile; demand structure.
• Unversioned prompts — if you can't diff it, you can't trust it across model updates.

Key takeaways

• The prompt is your primary control surface — design it deliberately.
• Structure it: role, context, instruction, examples, output contract.
• Few-shot, structured output, delimiters, and an explicit "I don't know" are the reliable core.
• Version and eval prompts like code; in health they're also safety artefacts.