Prompt engineering explained: how relevant is it today?
What prompt engineering covers, why it matters as models improve their understanding and where it still makes a measurable difference.
Reading time: 11 min
The prompt engineering is the practice of writing and structuring instructions given to a language model to achieve a reliable result and repeatable. It is not the search for the magic phrase: it is precisely defining the task, the necessary context, the format of the output and the criteria to judge it correct.
The word "engineering" misleads. There is nothing particularly technical about writing a good prompt: the skills that are needed are knowing how to describe a process and knowing how to recognize the wrong output. Those who know their craft well write better prompts than those who know computer science well.
There is, however, an honest question to ask: how much more is needed, today that models interpret well even badly written requests? The short answer is that for occasional use it counts much less than two years ago, While in production it still counts a lot — and this guide explains why.
In summary
- It is to write instructions that give results repeatable, not just good once.
- The key competences are of domain, not programming.
- For occasional use today counts much less from two years ago.
- In production it still counts, because there it serves the same quality on thousands of cases.
- In real systems the context weighs more than the formulation.
- A prompt is evaluated on a sample of real cases, never on three chosen examples.
What does it really include
A useful prompt is not a sentence: it is a structure. It almost always contains these elements, explicitly or not.
| Item | What it is used for | Typical error |
|---|---|---|
| Task | Telling what it has to produce | "Analyze this" without saying what you do with it |
| Background | Giving the necessary information | Giving too many, or the wrong ones |
| Format | Define the output shape | Don't specify it and then have to fix it by hand |
| Constraint | What he doesn't have to do | List only bans, without saying what to do |
| Criteria | When it's done right | Leave it implied and then complain about the result |
| Examples | Show the expected result | Using examples that are all the same |
The biggest leap in quality, in practice, comes from two trivial things: specify output format and give two or three examples of correct answer. It is also the two that are skipped most often.
Because today counts less than before (for daily use)
Until a couple of years ago, we needed devices that are largely outdated today: formulas to get step-by-step reasoning, turns of words to avoid waste, rigid structures to have ordered outputs.
Recent models handle a lot of this on their own. Asking in a normal way almost always works, and some techniques spread years ago today are useless or counterproductive: they stiffen the response without improving it.
It remains true, however, everything about the Clarity: a poorly defined task remains a problem even for the best model.
Where it still makes a measurable difference
The point that changes everything is the difference between use the AI and put it into production.
Where it still matters a lot
- Automatic processes that run thousands of times with no one watching
- Outputs that must always have the same structure to be processed by another system
- Tasks where an error costs: amounts, deadlines, personal data
- Domains with specific vocabulary, where words have a precise meaning
- Systems that have to say "I don't know" instead of inventing
Where it matters little
- Ask for a summary or rewording on the fly
- Exploring an idea in conversation
- Tasks where you always read the output before using it
- Occasional and non-repetitive use
The difference is that in conversation correct on the fly: if the answer does not go, reformulate. In an automatic process no one reformulates, and the same defect is repeated on each run.
Prompt engineering and context engineering
It is the most useful distinction to be clear about, and the one that moves results the most into real systems.
- The prompt engineering It's about the instructions: what you ask for and how.
- The context engineering It's about information: what data you make available, how you select it, how much you put in.
In a system that responds on business documents, a prompt written beautifully on wrong documents produces wrong answers with great elegance. The real leverage is retrieve the right piece of information, which is a problem of selection, not formulation: it is the theme of RAG.
It's also worth the opposite of what you think: more context is not better. Filling the window with unremarkable material worsens responses and raises costs, because all that text you pay for — see What Are Tokens.
How to evaluate a prompt (the only way that matters)
You don't rate it by reading the output and saying "yes, it looks good." You rate it like this:
- Collect a sample of real cases, at least fifty, including difficult and strange ones. Not invented examples.
- Define what it means to be correct, before looking at the answers. If you can't write it, the task is not clear to you either.
- Run and count: how many times it is correct, how many times it is wrong, how many times it is ambiguous.
- Change one thing only and run again on the same sample. Two edits together and you won't know which one worked.
- Resume when changing model: a prompt is calibrated to a precise model.
This is also why the "perfect prompt" does not exist: it is always the combination of a task, a model and a data type. Change one and the job needs to be done in part. For daily practice see how to get started with prompt engineering and the prompt collection for the company.
Techniques that still stand the test
By unraveling what has aged, few things remain that continue to make a measurable difference.
Give examples of the desired output. It is the most effective single lever, and should be used well: two or three examples different from each other, which also cover a case limit. Three examples all the same teach the model to handle a case only.
Secure the format in a verifiable manner. Not "answer in an orderly way", but the exact structure: what fields, in what order, what to put when a given is missing. If the output is to be read by another program, this is not an aesthetic preference: it is a requirement.
Foresee the security exit. A line that authorizes the model to say that the information is not there. Without it, the model fills the void, and that is how most of the invented answers are born.
Separate instructions and data. Keeping "what you have to do" apart from "what you do it about" reduces misunderstandings and makes it much easier to change a single thing when something is wrong.
Ask only one task at a time. A prompt that asks to extract, evaluate and summarize together does all three things worse than three separate steps.
| Technique | How much it weighs today | When it is indispensable |
|---|---|---|
| Examples of output | High | Always, in production |
| Explicit format | High | Output read from another system |
| "I don't know" release | High | Business data, where inventing is serious |
| Separate instructions and data | Medium | Long texts or attached documents |
| One task at a time | Medium | When quality is uneven |
| Formulas for Reasoning | Low | Almost Never: Recent Models Do It On Their Own |
How much does a misspelled prompt cost
There is an economic aspect that is only noticed when the volume grows. Each execution pays all what you send them: instructions, examples, context. A system prompt twice as long as needed, multiplied by tens of thousands of calls, becomes a real cost item.
The account has three components that add up:
- The text of instructions, which you send back identical to every single call
- The context which alleges, often much larger than it would serve
- The re-executions, because when the output is wrong someone raises — and you pay twice
The practical consequence is that the quality of the prompt and the cost of the system are the same problem seen from two sides: a more precise prompt costs less, because it reduces unnecessary context and repeated attempts.
Practical examples
Real estate agency, 6 people. Property descriptions were generated with different demands each time, and the result was uneven: some boards with square meters at the beginning, others no, variable lengths. The useful work was not finding better words, but fix the format: order of data, maximum length, what never write (promises on returns, references to the neighborhood). From there the human review went from rewriting to control.
Law firm, recurring practices. The system had to extract deadlines and withdrawal clauses from a contract. The initial prompt was reasonable but on a sample of fifty contracts it was recurrently wrong on those with multiple attachments. The correction was not to rewrite the request: it was change what was being fed to the model, moving from the entire file to the relevant sections only. Context problem, not prompt.
Mistakes to Avoid
- Looking for the magic formula. The lists of "secret prompts" are almost always calibrated on old models.
- Evaluating on three well chosen examples. We need a sample that also contains the unpleasant cases.
- Changing more things together. You lose the ability to figure out what worked.
- Filling in the context. More material does not mean better answers: often it is the other way around.
- Not allowing for "I don’t know". A system that must always respond, sooner or later invents — see How to avoid hallucinations.
- Giving as good a prompt after a model change. It must be reverified on the same sample.
How to apply it in the company
For an SME, prompt engineering is not a role to assume: it is a practice to put where processes repeat.
Three concrete moves, in order:
- Identify repetitive tasks where today someone writes a different request every time by hand. They are the ones who earn the most from a fixed structure.
- Write a shared prompt for each, with output format and correctness criteria. Put it where everyone finds it, not in personal chats.
- Measure on real cases and retests when changing instrument or model.
When these tasks become automatic and no one reads any more output, the prompt stops being a text and becomes a system component: from then on it is worth as a piece of software, and should be versioned and tested as such. It is the passage that leads AI Agents and all process automation.
Conclusion
Prompt engineering is less exotic and more useful than how it is told: it is describe a task well and verify it on real cases. For daily use today, clarity is enough; in production, method is needed, because the same instruction runs there thousands of times without anyone correcting it.
And when the results do not arrive, before rewriting for the tenth time the request is better to look elsewhere: almost always the problem is what information the model is seeing, not as you asked.
Do you want to understand what processes in your company can be automated with AI? Giallo Studio can help you turn the problem into a real workflow.
Giallo Studio guides: methodology and sources
How we apply it in the company
Related resources
Prompt engineering: what it is and how to get started
AI prompts: a complete guide to effective instructions
AI Hallucinations: What They Are and How to Avoid Them
AI tokens: how they are counted and priced in October 2026
AI agents: what they are and how they work
Claude Opus 5.5 prompts: what to remove, what to add and examples
AI, AGI and ASI: differences between intelligence and autonomy
Does superintelligence already exist? Evidence in 2026FAQ
What is prompt engineering?
It is the practice of writing and structuring instructions given to a language model to achieve a reliable and repeatable result. It is not finding the magic phrase: it is defining task, context, output format and correctness criteria.
Is prompt engineering still needed?
For occasional use, it matters much less than two years ago because models interpret imprecise requests better. In production, it still matters a great deal: the challenge is not getting a good answer once, but achieving the same quality across thousands of runs.
What is the difference between prompt engineering and context engineering?
Prompt engineering is about instructions; context engineering is about what information you make available to the model and how you select it. In real systems, the latter often weighs more than the former.
Do you need to be a programmer?
No. Useful skills are knowing how to describe a process accurately, knowing the domain and being able to assess whether an output is correct. Programming is used to integrate, not to write the prompt.
How do you tell if a prompt is good?
Test it on a sample of real cases, say fifty, and count how often the output is correct according to someone who knows the work. A prompt that works on three selected examples proves nothing.
Is there a perfect prompt?
No, and searching for one wastes time. A prompt is calibrated for a model, a task and a data type: if any of the three changes, the prompt must be checked again.