Skip to content
All notes
#LLM#Prompt Engineering

Prompt Engineering

Updated June 10, 20262 min read

Prompt engineering earned a bad reputation as vibes-driven incantation, but the version that ships to production is closer to interface design: you are specifying a contract between your system and a probabilistic function, then verifying it holds under load.

Structure beats cleverness

The reliable levers are unglamorous. Clear role and task framing. Explicit output schemas the model must fill. Few-shot examples that demonstrate edge cases rather than the happy path. Instructions to abstain when the input is out of scope. None of this is a magic phrase — it is disciplined specification, and it survives model upgrades far better than clever wording does.

Prompts are code

A prompt that is not version-controlled, diffable, and tested is a liability. I treat prompt templates as source: they live in the repo, changes go through review, and every change runs against a fixed eval set. This is the same rigor that [[Agent Evaluation]] demands — an agent's system prompt is arguably its most load-bearing line of code.

Prompting in a retrieval world

When context comes from a [[Retrieval-Augmented Generation]] pipeline, the prompt's job shifts to conditioning the model on that context: cite sources, prefer retrieved facts over prior knowledge, and refuse gracefully when the passages do not answer the question. Query rewriting — turning a messy user question into a retrieval-friendly one — is prompt engineering aimed at the search layer rather than the answer.

Measure, do not guess

Every prompt change is a hypothesis. Without traces of inputs, outputs, and outcomes — the domain of [[LLM Observability]] — you are tuning a system you cannot see. The best prompt engineers I know spend more time reading logs than writing prompts.