Prompting Is API Design

A prompt is not a magic incantation — it is the interface definition of a function you cannot see the source of. Engineers who get reliable output treat prompts the way they treat API contracts: explicit inputs, a specified output shape, named failure modes, and examples of the tricky cases.

The parts of a production prompt

• Task statement: one sentence, imperative. "Classify this support ticket."
• Input schema: what's being injected, clearly delimited. Never let user text blur into instructions — use delimiters and treat everything inside them as data.
• Output contract: the exact shape you parse. "Return JSON: {"category": one of [billing, bug, abuse], "confidence": 0-1}."
• Refusal path: what the model should emit when input is malformed or out of scope. Underspecified failure modes become silent garbage downstream.
• Examples: two or three input/output pairs beat a paragraph of description. Include one weird case.

Injection is real input validation

Anything a user can type into a field that ends up in your prompt can rewrite your instructions. "Ignore previous instructions" is the '; DROP TABLE of this interface. The defenses are the same shape: delimit untrusted content, keep system and user roles separate, validate the output before acting on it, and never let a model response execute privileged actions unguarded.

Iteration discipline

Prompts need regression tests like code does (covered in the evals lesson). Every time you fix a failure by tweaking wording, capture that failure in a fixture — otherwise the next wording change regresses it silently.

Field notes

• Temperature is a dial, not a mood: 0 for extraction/classification where you want determinism, higher only for open-ended generation.
• "Be concise" is a token cost, not a style — every instruction you add competes for the model's attention. Delete instructions that don't change outputs.
• Version prompts in code, review them in PRs, deploy them like config. A prompt change is a code change.