For weeks I have been seeing the same thing in meetings with clients and inside SUMāTO: two people ask the same artificial intelligence the same thing and receive answers that seem to come from different tools. One walks away frustrated, saying "this is useless"; the other gets a draft almost ready to use. The difference is rarely in the model. It is in how the question was framed. In this electrifying start to 2023, following the arrival of ChatGPT, we are beginning to call this prompt engineering, and I want to tell you why I believe it is one of the most profitable skills you can develop this year.
The short version: Prompt engineering is the art and discipline of giving a language model clear instructions to obtain useful, reliable answers. The quality of what you ask determines, to a large extent, the quality of what you receive. And when the prompt is no longer enough, there are paths such as RAG or fine-tuning.
A language model does not "understand" in the human sense: it predicts, word by word, the most likely continuation of what you wrote. That means the text you provide is not a simple search button, but the full context that steers that prediction. A prompt is that instruction, and prompt engineering is the practice of designing it with intent.
I like to think of it as delegating a task to a very capable but newly arrived person who doesn't know your company, your customers, or the outcome you expect. If you ask them to "write a summary," you'll get something generic. If you explain who it's for, what tone to use, and what to emphasize, the result changes completely. AI works the same way.
Because the model has only what you give it plus what it learned during training. If your instruction is ambiguous, the model fills the gaps with assumptions, and those assumptions almost never match what you had in mind. A vague question produces a vague answer; it is not bad luck, it is by design.
At SUMāTO we have found that most complaints that "the AI doesn't understand" are better resolved by improving the instruction than by switching tools. Before concluding that a model is no good for your case, it is worth checking whether we are asking for things the right way.
There is no magic, but there are patterns that work consistently. These are the ones I recommend most:
Here I need to be candid, because the enthusiasm of these weeks sometimes clouds judgment. An impeccable prompt improves the odds, but it does not guarantee the truth. The most important risk to understand is hallucination: the model can generate statements, data, or citations that sound plausible and are simply false. It does not lie on purpose; it predicts convincing text, and sometimes what is convincing is not what is correct.
That is why I insist on two internal rules. First: any factual information coming from a model must be verified before being used in a decision or published. Second: the model does not know your private data, your contracts, or what happened after its training date, so don't ask it for certainties it cannot have. Treating the output as an intelligent draft, and not as an oracle, avoids most of the problems.
There is a point at which improving the instruction stops paying off, and recognizing it in time saves a lot of frustration. If you need the AI to answer based on your documents, your policies, or your catalog, no prompt is going to invent that knowledge. That is where other approaches come in:
The practical rule we use: start with the prompt, which is the fastest and cheapest; if the problem is one of knowledge, think about RAG; if it is repeatable behavior at scale, consider fine-tuning. It is exactly the kind of decision we address in our AI-first approach and in the artificial intelligence work we do with our clients.
You don't need anything technical to become competent. Take a real task from your week, write a first prompt with context and constraints, look at the result, and adjust it two or three times. Save the ones that work: over time you'll have a small library of proven instructions for your usual tasks. That library, more than any isolated trick, is what multiplies the value.
Do I need to know how to program to do prompt engineering?
No. Most of it is done by writing clear instructions in natural language. The ability to explain precisely what you want helps more than any knowledge of code.
Does the same prompt work identically in every tool?
Not always. The principles of clarity, context, and examples carry over well, but each model has its nuances, so it pays to test and adjust when switching tools.
How do I reduce the risk of hallucinations?
Ask the model to rely only on the information you provided, ask it to indicate when it is not sure, and always verify factual data before using it. For critical cases, consider RAG.
Is it worth investing in this, or is it a fad?
I believe it is a skill that is here to stay. Knowing how to ask AI well is, at bottom, knowing how to think and communicate clearly, and that never goes out of style.
If you are seeing the potential of these tools but don't know where to start in your company, that is exactly the moment to talk. At SUMāTO, we help teams in Mexico, Bogotá, and across the region move from curiosity to use cases with real value, deciding with judgment when a good prompt is enough and when RAG or fine-tuning is the better fit. Write to us at sumatogroup.com/contacto and let's take that first step together.