Prompt Engineering Training
A small real skill, taught honestly, rather than a discipline with a certificate.
What is prompt engineering?
Prompt engineering is the practice of giving AI tools context, examples and constraints so their output needs less correction, and it is a genuinely useful skill that is considerably smaller than the market presents it as.
Most of the quality difference comes from three things: supplying the relevant context, showing an example of what good looks like, and stating the constraints. That is the core, and it can be taught in an afternoon.
The rest of what gets sold as prompt engineering is either superstition or techniques that mattered on older models and no longer do. Phrases people repeat because a result improved once are common and mostly meaningless.
It is also a skill with a shelf life. Models get better at inferring what you want, so the techniques that matter today are fewer than two years ago and will be fewer again.
Why we call this a half day skill
Duara teaches prompt technique from Nairobi as part of practical AI work rather than as a standalone discipline.
We say plainly that this is a half day skill, not a profession. Courses selling it as a career path are selling something the market is quietly removing, and we would rather teach you the real part and let you get on with your job.
Who this is for
- Output quality varies between people
- Staff are copying prompts they do not understand
- Results need heavy correction
- You want the real skill without the mythology
Industries we serve
- Professional services
- Marketing and communications
- Financial services
- Education
- Software teams
- Customer operations
Problems this solves
These are the practical symptoms of people using AI tools without ever being shown what actually improves output.
- Output needs heavy correction. Results arrive close but wrong, because the request never included the constraints that would have made them right.
- Quality varies by person. Two people get very different results from the same tool, and nobody has established why.
- Copied prompts nobody understands. Long prompts get shared around containing phrases that do nothing, and they are edited superstitiously.
- Iterating instead of instructing. People go back and forth five times rather than stating what they needed at the start.
What we deliver
The three things that genuinely matter taught properly, the superstition removed, and practice on your own real tasks rather than on exercises.
Context, examples and constraints taught properly
Common superstitions identified and dropped
Practice on your own real tasks
A short reference people will actually use
Guidance on when prompting is not the answer
Honest coverage of the skill shelf life
Features
- Three things, taught well. Context, an example of good, and stated constraints. That is most of the difference and the rest is detail.
- Superstition removed. Phrases people repeat because something improved once are identified as meaningless rather than left in place.
- Half a day, honestly. We say this is a half day skill rather than a profession, because courses selling it as a career are selling something the market is removing.
- When prompting will not fix it. Some problems need retrieval or a different tool, and no amount of rewording helps.
- Taught on your work. Practice happens on real tasks, since a technique demonstrated on an example rarely survives contact with a real one.
Benefits
- Less correcting. Output arrives closer to usable because the request contained what it needed.
- Consistent results across people. A shared technique removes most of the variation between colleagues.
- Faster to a good answer. Stating the constraints once beats five rounds of iteration.
- No wasted effort on mythology. Time stops going into techniques that do nothing.
Technologies we use
- Context supply. Giving the background the tool needs, which affects output more than wording does.
- Examples. Showing what good looks like, which is the single most effective technique available.
- Constraints. Stating length, format, audience and what to avoid, so output does not need reshaping.
- Structured output. Requesting a specific format when the result feeds another system or document.
- Diagnosis. Recognising when a poor result is a prompting problem and when it is not.
This skill is shrinking. Models are getting better at inferring intent, so techniques that mattered two years ago are already unnecessary, and we teach that rather than pretending the discipline is growing.
How the process works, step by step
Prompt training is half a day. Anybody offering considerably more is padding, and we would rather say so than fill the time.
-
Step 1
Free needs conversation
We establish what your people are actually trying to produce, since the training is built on those tasks.
-
Step 2
The three techniques
Context, examples and constraints are taught and practised until they are habitual rather than remembered.
-
Step 3
Superstitions removed
Prompts your team already uses are examined and the parts doing nothing are dropped.
-
Step 4
Diagnosis practised
People learn to tell a prompting problem from one that prompting will not fix.
-
Step 5
Reference issued
A short sheet, deliberately brief, since a long reference does not get opened.
Quality assurance and how we work
The commitments attached to teaching a skill the market oversells.
- We say this is a half day skill. Courses selling prompt engineering as a career path are selling something models are quietly making unnecessary.
- We remove techniques that do nothing. Phrases repeated because a result improved once are superstition, and leaving them in place wastes your people time.
- We teach when prompting is not the answer. Some problems need retrieval or a different tool, and rewording will never fix them.
- We do not pad the session. If the useful content fits in an afternoon, filling a second day would be taking your money for attendance.
- We say the skill is shrinking. Models improve at inferring intent, so this matters less each year and pretending otherwise would be dishonest.
Frequently asked questions about prompt engineering
Is prompt engineering a real skill?
Yes, and a smaller one than the market presents. Context, examples and constraints are most of it and they fit in an afternoon.
Should we hire a prompt engineer?
Almost certainly not. It is a skill your existing staff can learn in half a day rather than a role, and the market is quietly removing it.
What actually improves output most?
Showing an example of what good looks like. It is more effective than any wording technique and it is consistently underused.
Do the phrases people add actually help?
Mostly not. Repeated phrases that improved something once are superstition, and we identify and drop them.
Why is the skill shrinking?
Because models are getting better at inferring intent. Techniques that mattered two years ago are already unnecessary.
How long should training take?
Half a day. Anybody offering considerably more is padding, and we would rather say that than fill the time.
Will this fix all our output problems?
No. Some need retrieval or a different tool entirely, and we teach people to tell the difference rather than reword endlessly.
Can it be taught on our own tasks?
Yes, and it should be. A technique demonstrated on an example rarely survives contact with a real piece of work.
What about very long prompts?
Usually a sign of accumulated superstition. Long prompts often work despite their length rather than because of it.
Do different tools need different techniques?
Less than people think. Context, examples and constraints work across all of them, which is why we teach those.
Should we standardise prompts across the team?
For repeated tasks, yes. Shared prompts for common work remove most of the variation between people.
What is a system prompt?
Standing instructions applied to every request in a tool, which is worth setting properly once rather than repeating each time.
Is there value in a certificate?
Little, in our view. We would rather your people could do the work than hold a credential for a shrinking skill.
Does it help with structured output?
Yes, and requesting a specific format matters most when the result feeds a document or another system.
Can non technical staff learn it?
Easily. It is a communication skill rather than a technical one, and clear writers tend to do well at it.
Do the same techniques work when prompting in Swahili?
Yes, the three techniques carry across, though model quality varies by language and we would test on your material.
Will this help with our AI systems we built?
Partly. Prompts inside a product should be version controlled and tested, which is engineering rather than training.
How do we keep the skill current?
Mostly you do not need to. The direction of travel is that less technique is required, not more.
Do you record what our staff produce?
No. Work brought into the session belongs to your team and is not retained.
What does prompt training cost?
Group size determines it, quoted after the needs conversation. It is half a day and we price it as such.
Glossary of terms
Prompting terms in plain language.
- Context
- The background information supplied with a request, which affects results more than wording.
- Few shot
- Including examples of what good output looks like, which is the most effective single technique.
- Constraint
- A stated limit on length, format, audience or content.
- Structured output
- Requesting a specific format so the result can be used by another system.
- Iteration
- Going back and forth to improve a result, usually a symptom of an underspecified first request.
- System prompt
- Standing instructions applied to every request in a tool, as opposed to a single message.
Related services in AI Training
Talk to us about prompt engineering
Take a prompt your team uses regularly and delete every phrase nobody can justify. What remains is usually just as good.
Start your project