Prompting for Engineers: Structured Outputs Over Clever Wording

The engineering view of a prompt

In production, an LLM call is a function: inputs go in, output must be parseable and correct often enough to automate. Clever phrasing matters less than a clear contract.

A reliable prompt has four parts:

1. Role and task — what the model is doing and for whom.
2. Context — the data it needs, clearly delimited.
3. Rules — constraints, including what to do when information is missing.
4. Output format — exactly what to return.

You extract fields from support emails.
Return JSON matching the schema. If a field is not stated in the email, use null — do not guess.
 
<email>
{email_text}
</email>

Ask for structure, then enforce it

Most model APIs can constrain output to a JSON schema (often called structured outputs, JSON mode or tool calling). Define the schema in code and validate the result:

from pydantic import BaseModel, ValidationError
 
class Ticket(BaseModel):
    customer_email: str | None
    product: str | None
    severity: str  # "low" | "medium" | "high"
 
raw = call_llm(prompt, response_schema=Ticket.model_json_schema())
try:
    ticket = Ticket.model_validate_json(raw)
except ValidationError:
    ticket = None   # retry once with the error message, then route to a human

Few-shot examples beat long explanations

Two or three input–output examples covering edge cases (missing fields, ambiguous wording) usually improve consistency more than paragraphs of instructions.

Make it testable

• Keep prompts in version control next to the code that uses them.
• Build a small evaluation set of real inputs with expected outputs.
• Re-run it whenever you change the prompt, model or temperature.

Settings that matter

• Temperature: low (0–0.3) for extraction and classification; higher only for creative text.
• Max output tokens: set it, so a runaway response cannot blow up cost or latency.
• Model choice: use the smallest model that passes your evaluation set.