Prompt patterns that hold up for engineers

Half the prompt advice floating around reads like horoscopes. Be the model, breathe, offer it a tip. The prompt patterns for engineering work that actually hold up are far more boring and far more reliable, because they treat the model like a system you are programming with words rather than a genie you are flattering. I have built features on top of these models where the prompt is part of production code, and the patterns that survive that environment are the ones worth talking about.

The core mindset shift is this: a prompt going into a real system is not a chat message. It is an interface contract. You want the same output shape, the same behavior, every time, across inputs you have never seen. That changes everything about how you write it.

Be specific about the output, not just the task

The most common reason a prompt fails in production is that it asks for the right thing in a vague shape. If you need JSON, say exactly which fields, which types, and what to do when a value is missing. If you need a short answer, define short. Models fill ambiguity with their own assumptions, and those assumptions drift between runs, which is exactly what you cannot tolerate when something downstream has to parse the result.

I spend more words describing the output format than the task itself. It feels excessive and it pays off constantly. A parser that breaks on the one response that wrapped JSON in prose is a 3am problem you can prevent with three sentences of specification.

Constraints beat instructions

Telling a model what to do is weaker than telling it what it must never do. Positive instructions get bent under pressure from a weird input. Hard constraints hold. So I frame the important rules as boundaries:

• State what the model must not do, not just what it should do, for the rules that matter
• Give it an explicit escape hatch, like return this exact value when you are unsure, so it stops inventing
• Tell it the format to use when it cannot answer, so even failure is structured and parseable
• Put the non-negotiable rules near the end, where they get the most weight

Examples do the heavy lifting

A couple of well chosen examples teach the model more than a paragraph of description. This is the highest leverage pattern I know. Show it one input and the exact output you want, and it generalizes the pattern far better than it follows abstract instructions. The catch is that your examples have to be honest. If you only show clean cases, the model assumes the world is clean and falls apart on the messy real input.

So I deliberately include an example of a hard case, including how to handle the ambiguous or empty one. The example that shows the model how to fail gracefully is often more valuable than the three that show it succeeding.

Treat prompts like code

This is the part engineers skip and then regret. A prompt that controls production behavior deserves the same discipline as any other code. Version it. Review changes to it. Have a test set you run it against before and after every edit, because a small reword can silently break a case that used to work. I have seen a one word change to a prompt quietly tank a feature, with no error, no alert, just worse output that nobody caught for a week.

Keeping prompts in the codebase rather than scattered in someone's notes also means the whole team can see why the prompt says what it says. Every odd line usually exists because it fixed a real failure, and that history is worth preserving the same way you preserve a comment explaining a workaround.

Simple and explicit wins

The fancy tricks come and go. The patterns that have not let me down are dull on purpose: say exactly what you want, set hard boundaries, show real examples, and maintain the thing like code. A prompt that a new engineer can read and understand is also a prompt the model handles predictably. Clever prompts impress people in demos. Clear ones survive production, and survival is the only metric that counts once real users are on the other end.