Prompting for engineers: what reliably works, and what only looks clever

The largest single improvement available to most prompts is specifying the shape of the answer with the same precision you would use for a function signature. Not 'give me a summary', but 'return JSON with keys title (string, max 80 chars), summary (string, 2 sentences), tags (array of 3 lowercase strings)'.

This works because it removes the model's freedom to choose a format, which is where most variance between runs originates. It also makes failures machine-detectable: if the response does not parse, you retry, rather than silently passing malformed text downstream.

Where the platform supports structured output or a JSON schema natively, use it instead of describing the schema in prose. Enforcement at the decoding level is strictly more reliable than instruction-following.

• Name every field and its type.
• State length limits numerically, not as 'brief' or 'concise'.
• Define what to emit when the answer is unknown — an explicit null beats an invented value.

A model cannot know your codebase conventions, your data schema, or your product's edge cases, and no amount of instruction phrasing substitutes for supplying them. In practice, the difference between a mediocre and an excellent result is almost always the quality of the material in the prompt rather than the cleverness of the wording.

Supply concrete examples of correct output — two or three is usually enough, and they should include one awkward case rather than three easy ones. Few-shot examples that only show the happy path teach the model that the happy path is all there is.

Be deliberate about what you leave out. Long contexts degrade attention to any single element, and models reliably attend more to material at the beginning and end of a prompt than to the middle. If something is critical, do not bury it in paragraph fourteen of a pasted document.

A prompt that asks a model to extract, classify, rewrite and rank in one pass will do all four adequately and none well. Splitting the work into separate calls — extract, then validate, then transform — costs more tokens and produces dramatically more stable output, because each step has one measurable success criterion.

Decomposition also makes debugging tractable. When a single monolithic prompt regresses after an edit, you cannot tell which sub-task broke. When step three of four regresses, you know exactly what to fix.

This is the same argument as writing small functions, and it has the same answer: the pipeline is easier to reason about even though it has more parts.

Emotional pressure — telling the model your job depends on the answer, or offering it a tip — produced measurable effects on some older models and has largely washed out on current instruction-tuned ones. It is not harmful, but building it into a production prompt is cargo cult.

Role assignment ('you are a world-class senior engineer') has a small effect on tone and essentially none on correctness. It is worth one line if you want a specific register; it is not a quality lever.

Elaborate 'chain of thought' instructions are largely redundant on reasoning-tuned models, which already allocate internal reasoning, and can make output worse by forcing verbose intermediate text into the response. Ask for reasoning only when you intend to read or verify it.

Threatening, all-caps insistence and repeated 'IMPORTANT' markers work in the sense that emphasis marginally raises attention, and fail in the sense that when everything is marked important, nothing is.

• Emotional bribery: negligible on current models.
• Persona framing: affects tone, not accuracy.
• Forced step-by-step on reasoning models: often counterproductive.
• Ten IMPORTANT tags: cancels itself out.

If a prompt runs in production, it needs a test set. Twenty to fifty representative inputs with known-good outputs is enough to catch most regressions and is achievable in an afternoon. Without it, every prompt edit is an uncontrolled experiment and 'it seems better' is the only available metric.

Score what you actually care about: does the JSON parse, is the extracted field correct, is the classification right. Human-judged qualities like tone can be scored by a second model call, but only after the mechanical checks pass.

Version prompts in the repository alongside code, with the eval results recorded. Prompts drift, models get deprecated and replaced, and a prompt that worked perfectly on last year's model can degrade quietly on its successor. A stored eval turns that from an outage into a failing test.

Models fabricate confidently when the answer is absent from the context. The defence is not a stern instruction; it is giving the model an explicit escape value and rejecting outputs that do not use it. 'If the stipend is not stated in the source text, return null' is enforceable. 'Do not hallucinate' is not.

Models also drift toward the average of their training data when the instruction is vague, which is why generic prompts produce generic writing. Specificity in the input is the only reliable cure.

Finally, assume the model will occasionally return something unparseable, rate-limited or truncated. Retries with backoff, a fallback model, and a hard timeout are not optional in production; they are the difference between a feature and an incident.