Prompt Engineering at Production Quality

Two reasons structure beats clever wording every time.

First: reviewability. When your prompt has named sections, you (or a collaborator reviewing an AI's edit) can diff the constraints section specifically. You can see exactly what changed and why — no guessing.

Second: injection hygiene. When retrieved documents and user input live inside clearly delimited context blocks, the model treats them as data. When you concatenate untrusted text directly into your instructions, you've put them on equal footing — and for a system wired to an ads API, prompt injection via a client document is a real spend risk, not a theoretical one.

That said, your primary defence is still §1's tool-surface design, not wording alone.

If a machine consumes the model's output downstream, you need two layers of protection — not one.

Layer one: use the API's structured-output mode or function-calling parameters to declare a schema. This makes malformed output rare.

Layer two: validate at your boundary anyway — with Zod or equivalent. Schema-constrained decoding is not a guarantee. More importantly, this is where semantic checks live: the schema can say `budget_delta: number`, but only your validator can say `abs(budget_delta) <= 0.2 * current_budget`.

On failure: one structured retry (feed the error messages back to the model), then fail loud into the error branch. No silent swallowing.

The default is zero-shot. Today's frontier models handle most well-specified tasks without examples — don't pay the token cost until you know you need to.

Few-shot examples earn their keep when the task has format or judgment conventions that are hard to describe in words. If you add them: 2–5 examples that span the edges (not the easy middle), versioned with the prompt. Watch for rot — examples silently encode old behaviour and will quietly outvote updated instructions if you don't review them on every prompt bump.

Chain-of-thought helps on some genuinely multi-step reasoning tasks, but with modern reasoning-class models it's often redundant and costs you 3× the latency.

The rule: let the eval suite decide. Don't add complexity you haven't measured.

Treat prompts like code, because they are.

Prompts live in git, alongside your code. Every change ships as a PR with a changelog line that names the failure mode it's fixing — for example: 'added no-unsupported-claims constraint after T2 (unfaithful summarisation) appeared in error analysis.' This is how future-you (and your clients) can understand why a prompt evolved.

At runtime, your code pins the prompt version explicitly — `report-commentary@v7`, not 'the latest.' Traces record which version ran. The eval suite runs per-version so you can compare pass rates before merging.

The key test: 'Which prompt produced this bad output?' must be answerable from the trace alone. If it isn't, you're debugging blind.

If a UI-based prompt platform is in play, sync from git one-way. Git is source of truth; the platform is a view.