Prompting a model in a notebook and prompting a model behind a product with real users are two different disciplines. This is a placeholder post; replace it with your own write-up.
Structure your prompt like an API contract
Treat your system prompt as an interface: define the role, the inputs, the exact output format, and the failure behavior explicitly. Ambiguity that seems harmless in testing turns into inconsistent output at scale.
You are a support ticket classifier. Given a ticket, return JSON only:
{"category": string, "urgency": "low"|"medium"|"high", "confidence": number}
If the ticket doesn't fit any category, use "other" with confidence 0.
Patterns worth reaching for
- Few-shot examples — two or three well-chosen examples usually beat a longer instruction paragraph, especially for formatting consistency.
- Chain-of-thought, hidden from the user — let the model reason in a scratchpad field you don't render, then extract a clean final answer.
- Structured output / function calling — constrain the model to a schema instead of parsing free text; it removes an entire class of bugs.
- Decomposition — split a complex task into smaller prompts chained together rather than one mega-prompt trying to do everything at once.
Patterns that look good in a demo and fail in production
- Long, unstructured instructions that quietly conflict with each other as they accumulate over months of edits.
- Relying on the model to "just know" formatting conventions without an example or schema.
- No fallback path for when the model returns something that doesn't parse — always have a deterministic retry or default.
Treat prompts like code
Version them, test them against a fixed eval set before shipping changes, and log inputs/outputs so regressions are debuggable. A prompt change is a behavior change, and it deserves the same rigor as a code change.