Prompt Engineering
A prompt that works once is a screenshot. A prompt that works on the hundredth unusual input is engineering, and the difference is testing.
Why clever prompts disappoint
Most shared prompts are tuned to one input by someone who tried until it looked good. That is a demo. The same prompt meets a user who writes in three languages at once, pastes a table, or asks something adjacent to what you designed for — and the behaviour that seemed reliable was one sample.
Production prompting is closer to writing a specification than to finding magic words. State the task, the constraints, the output shape and what to do when the input does not fit. Then run it against the inputs that actually arrive, including the ugly ones.
Structure beats persuasion
Politeness, threats and elaborate personas move outcomes far less than structure does. What reliably helps: separating instructions from data so injected text cannot be read as a command, specifying output format precisely and validating it, giving examples of the hard cases rather than the easy ones, and stating explicitly what to do when the model does not know.
That last one is the difference between a system that says "the document does not cover this" and one that invents a plausible paragraph. Both are the same model. Only one was told what to do at the edge.
Where this usually goes wrong
Untracked prompts
A prompt edited in a dashboard with no history is a production change with no diff and no rollback. Prompts belong in version control, reviewed like code, because they behave like code.
Concatenating user input into instructions
If user text lands in the same block as your instructions, a user can write instructions. Separate them structurally and treat everything from outside as data.
Judging a change by trying it twice
Model output varies. Two good runs after an edit is not evidence. A fixed evaluation set — even twenty cases — turns "seems better" into a number you can compare.
Questions people actually ask
Does prompt engineering still matter as models improve?
The tricks matter less; the specification matters more. Better models need less coaxing and still need to be told the constraints, the output shape and what counts as failure. Those are requirements, and requirements do not go away.
Should examples go in the prompt or in a fine-tune?
Start with examples in the prompt — they are free to change and easy to test. Fine-tuning pays off when you have many examples, a fixed task and enough volume that the token cost of examples outweighs the cost of training.
How many examples should I include?
Fewer than people expect, chosen for difficulty rather than typicality. Three examples covering the awkward cases usually beat ten showing the obvious one.
Build it, free
Project briefs with the assessment criteria published before you start, and written code review on what you submit. No payment to apply or to complete.