# Prompt engineering > Prompt engineering is the practice of structuring what you send a model so that it reliably produces what you need — the instruction, the context, the… Source: https://northerngo.com/glossary/prompt-engineering/ Language: en Updated: 2026-08-28 --- **Prompt engineering is the practice of structuring what you send a model so that it reliably produces what you need — the instruction, the context, the examples and the required output format. It is closer to writing a specification than to finding magic words.** ### What actually moves the result Most of the gain comes from a small number of unglamorous moves: - **Say what the output must look like.** "Return a JSON object with the keys `title` and `steps`" is worth more than any amount of politeness. Most APIs also support a schema-constrained mode, which is stronger than asking. - **Give context instead of relying on recall.** Paste the actual document, the actual error, the actual code. This is the single largest source of improvement and it also cuts [hallucination](/glossary/hallucination/). - **Show two or three examples** of input and desired output. Few-shot examples communicate tone and edge cases faster than a paragraph of description. - **State the constraints and the failure case.** What to do when the answer is not in the material, what to leave out, what not to invent. - **Split the work.** One model call per decision, chained, beats one call asked to do five things — and it gives you somewhere to inspect when it goes wrong. - **Put the critical instruction near the end** of a long prompt, where attention is strongest. For anything you will run more than a handful of times, keep a small set of test inputs and compare versions of the prompt against them. Without that you are guessing, because a change that fixes one example routinely breaks two others. ### What to watch out for **Prompts are not portable, and they are not a substitute for design.** A prompt tuned on one model often performs worse on another; changing model version is a reason to re-test, not a drop-in swap. Newer reasoning-oriented models have also made some old tricks obsolete or harmful — telling a model to "think step by step" when it already reasons internally can be noise, and elaborate role-play framing usually adds nothing over a plain, precise instruction. The wider point: prompting cannot fix a problem the model genuinely cannot do. If the task needs current data, retrieve it. If it needs a private codebase, supply it. If it needs a fixed behaviour across thousands of calls, [fine-tuning](/glossary/fine-tuning/) or program structure is the answer. Rewriting the prompt a twelfth time is how people avoid noticing that. --- NorthernGo is an AI-powered platform for building production-ready web apps with zero coding. Local AI generation via WebGPU is unlimited and free, and you own all generated source code. https://northerngo.com/