Prompt engineering is interface design for non-deterministic functions — structure, testability, and clear separation of instructions, data, and user input. Production prompts are diffed, evaluated, and rolled back like any other critical code path. Production prompts live in git next to the code they control — not in a shared doc that drifts from what actually ships.
System prompt architecture
Keep system prompts stable: role, hard constraints, output format, refusal policy. Put volatile business rules in retrieved documents or remote config, not paragraphs that require redeploy to change. Use XML or markdown section tags in system prompts — models parse delimited blocks more reliably than prose paragraphs mixing policy and format rules. Name sections consistently: ROLE, CONSTRAINTS, OUTPUT_FORMAT, REFUSAL_POLICY.
Document why each system instruction exists. Prompt bloat accumulates silently until latency and cost spike without quality gains. Keep system prompts under two thousand tokens where possible — long system prompts steal budget from retrieved context and user input. Move reference material to retrieval instead of stuffing static docs into system text.
Dynamic few-shot selection
Select examples by embedding similarity to the current query. Three relevant examples beat ten random ones pulled from a static file. Refresh the few-shot pool monthly from production successes — static examples go stale as product vocabulary evolves. Store examples with embedding vectors for dynamic selection rather than hardcoding order in prompts.
Curate examples for edge cases — refusals, ambiguous inputs, multilingual queries — not just happy paths. Bad few-shot examples teach bad habits faster than good ones teach good habits. Negative examples — what not to do — reduce specific failure modes faster than adding more positive examples alone. Include one refusal example for each high-risk request category your product faces.
Verification and structured output
Use chain-of-thought in a scratchpad field; expose only a final answer field to users. High-risk domains add a verifier pass for citations, numeric bounds, or deterministic rule checks. For JSON outputs, provide a schema in the prompt and validate with Pydantic after generation — retry once with the validation error in the user message. Limit retries to avoid runaway token spend on malformed outputs.
JSON mode and tool calls reduce fragile regex parsing. If you cannot diff it and eval it, it is not engineering — it is hope. Red-team prompts for injection via retrieved documents — an attacker who controls indexed content should not override system policy. Test with documents containing ignore previous instructions and similar adversarial strings.
"If you cannot diff it and eval it, it is not engineering — it is hope."
— — GenOrbit prompt disciplineWhat to do next
Start with one measurable outcome — latency, accuracy, adoption, or revenue — and design your stack around that constraint. GenOrbit ships production AI systems across healthcare, astrology, fintech, and SaaS; if you want a second pair of eyes on architecture or delivery, we are happy to talk.
Related: /services/llm-rag-agent-development · /blog/evaluating-llm-output-ragas-trulens