Collections of prompt tips are full of claims like “put this sentence in front and performance triples.” Most do not reproduce. Somebody credited one good result to the prompt, and attaching the same incantation to the next subject does nothing at all.
Conversely, some things keep working when you change the subject and when you change the model. They have one thing in common: a person decides something the model would otherwise have had to decide for itself. All seven below take that form.
Rule 1. Assign a role
Why it works: it fixes the vocabulary, the depth and the assumptions of the answer in one move.
- Bad:
Explain Kubernetes - Fixed:
Explain Kubernetes to a backend developer who has used Docker but has never touched orchestration.
What changes is not the writing style but what gets left out. The first prompt does not know its reader, so it either re-explains containers from scratch or races ahead. The second skips the whole opening on the strength of one fact: “they know Docker.”
Rule 2. Specify the output format
Why it works: if you do not choose a format, the model chooses one. And it mostly chooses prose.
- Bad:
Summarise the problems in this log - Fixed:
Lay out the problems in this log as a table. Four columns: time / symptom / likely cause / how to check.
Demand a table and, to fill all four cells, the model has to think about the likely cause and the way to check it separately. The format forces the thinking. The same holds for JSON, a checklist or a three-part structure.
Rule 3. Give one or two examples
Why it works: one example is more precise than ten lines of description.
- Bad:
Clean up these product names - Fixed:
Clean up product names like this. e.g. "Samsung Galaxy S24 Ultra 512GB Titanium" → Brand: Samsung / Model: Galaxy S24 Ultra / Capacity: 512GB
“Clean” means something different to everyone; the example means only one thing. Whenever the format is even slightly unusual, give an example instead of a description. Two examples also pin down the edge cases.
Rule 4. Set constraints
Why it works: if you do not write down what it must not do, the model does all of it.
- Bad:
Write the code for this feature - Fixed:
Write the code for this feature. No new external libraries, reuse the functions in the existing utils.py, and do not create new files.
Constraints do not lower quality; they remove the rework. The reason output gets thrown away in practice is usually not quality but that it arrives “in a shape we cannot use here.”
Rule 5. Break it into steps
Why it works: ask for everything at once and a mistake in the middle rides all the way to the end.
- Bad:
Analyse these 500 survey responses and write me a report - Fixed:
Step one: only classify the responses into five to seven themes. I'll review the classification, then ask you for step two.
The point is creating a place for a person to intervene partway. A report built on a wrong classification has to be redone from the start, however good the sentences are.
Rule 6. Supply the criteria
Why it works: “pick the good one” means the model invents the criteria.
- Bad:
Pick the best option out of these - Fixed:
Pick one of these. Criteria: (1) implementable within two weeks (2) no changes to the existing DB schema (3) no additional operations headcount. Score each option against each criterion and write down why the others were rejected.
Give the criteria and you get not just a conclusion but the reasons for rejection. That is the part a person actually needs to review.
Rule 7. Do not try to finish in one shot
Why it works: the first result is a draft. Pointing at what to fix is faster than writing a new prompt.
- Bad: (disliking the result, rewriting the prompt from scratch)
- Fixed:
Item 3 is too generic. Rewrite it for our situation (200 users, one server). Leave the rest as it is.
“Leave the rest as it is” is the important part. Without it the whole thing gets rewritten and the parts you liked disappear with it.
Where models differ
The seven rules are universal, but how much you feel them varies.
| Item | Where they diverge |
|---|---|
| Long documents | The larger the context window, the more it pays to put the whole document in at once |
| Enforced format | Structured output such as tables or JSON is generally respected, but some models let the format slip the longer the output runs |
| Refusal tendency | Safety policies differ, so the same request sometimes has to be reworded to get through |
| Korean | Korean is fine for the instructions themselves, but on jargon-heavy work it is more stable to leave the technical terms in English |
Treating prompts as an asset
The most common waste is letting a prompt that worked wash away in the chat window. Three things are enough to change that.
- Save them. A notes app or an internal wiki — collect them as “task name → prompt.”
- Mark the variables. Leaving the part that changes each time in brackets, like
{target reader}, makes reuse easy. - Write one line on why you changed it. A note like
v2: format wasn't respected, so column names are now explicitsaves the next person (usually your future self).
You do not need to study prompt engineering separately. But the habit of not throwing away a prompt that worked is worth learning.
Frequently asked questions
Do I need to study prompt engineering separately?
You do not need a course. The seven rules in this article are close to everything that reproduces in real work, and the rest is the habit of collecting the prompts that fit your own job. As models improve, the value of tricks falls and the value of writing clear requirements rises.
Is a longer prompt always better?
No. Structure beats length. Three lines of role, format and constraints beat ten lines of piled-up adjectives. Examples and constraints do earn their length, though, so when you trim, start with the modifiers.
What can prompts not fix?
Recent information the model does not have, private material such as internal documents, and figures that need fact-checking. A prompt is a technique for getting out what the model has, not for manufacturing what it lacks. That territory has to be solved by attaching the material yourself or using a search feature.
Which is more accurate, Korean or English?
For everyday instructions there is almost no difference. On technical work with a lot of jargon it is more stable to leave the terms in English, and if the output has to be in Korean, saying “answer in Korean” explicitly is the reliable route.
Leave a Reply