Prompt engineering is briefing a model the way you would brief a junior employee: a role, examples of good work, the task in numbered steps, and a hard limit. Four parts, two minutes, and the output stops being generic.
Is prompt engineering still a real skill?
When ChatGPT landed, prompt engineering got called the skill of the decade, and then a year later it got called a fad. It sits between the two. Nobody needs a certificate in it, and it has not gone away either.
What it does is separate people who get usable work out of a model from people who get slop back and conclude the tool is broken. Same model, same subscription, different brief.
It matters more now than it did in 2023. Back then a bad prompt cost you one bad paragraph that you read and rewrote. Now an agent takes your brief and runs on it for several minutes without you watching, so a bad brief costs you the whole run and you find out at the end.
Why one-line prompts do not work
Google trained everyone for twenty years: keywords, one line, hit enter, scan the results. Most people use ChatGPT the same way. The first thing language models were good at was question and answering, which fitted that habit perfectly, so nobody had to break it. Then agents arrived and the habit came along with them.
I always say to business owners: treat the model and the agent as a junior employee. You would not hand a new hire one sentence and expect the finished job back. You would write a brief with examples of what good looks like. A prompt is that brief, and two minutes on one is normal for work that matters.
What makes a good prompt? The four parts
A role, examples of good work, the task broken into steps, and a constraint. In that order. Here is the whole thing for a job an HVAC operator has, written out rather than described:
You are the after-hours dispatcher for a commercial HVAC company in
Phoenix. You take the call, work out what is broken, and write the
dispatch note the on-call technician reads on their phone.
Two dispatch notes we consider good:
"Chiller down at Ridgeline Medical, 4th floor. No cooling since
19:40. Site contact Dana Ruiz, 602-555-0148, on site until 22:00.
Access via loading dock, code 4471. Rooftop unit 2, Trane RTU.
Sending Marco, ETA 21:15."
"Rooftop unit tripping the breaker at Halden Logistics warehouse 3.
Reported 20:05 by night supervisor Ade Okonjo, 602-555-0193.
Warehouse staffed overnight, access fine. Holding at 74F, not
urgent. Booked tomorrow 07:00, Priya."
For every call:
1. Confirm the site, the equipment, and what has stopped working.
2. Get a name and a mobile number for whoever is on site tonight.
3. Ask whether the building is accessible now, and how.
4. Decide tonight or tomorrow morning, then write the note.
Keep the note under 300 characters. If you do not have the site
contact's number, write "no contact number" in the note rather than
leaving it out.The role does more than set a tone. “After-hours dispatcher for a commercial HVAC company” tells the model that access codes matter, that a chiller in a medical building outranks a warehouse holding at 74F, and that it is writing for someone reading on a phone at 9pm. Swap in “you are a software architect” and the same four steps produce a code review. The role is what the model measures its own output against.
The examples are the part people skip. Those two notes teach the model the length, the order the facts come in, what gets abbreviated, and that a phone number appears every time. That is four rules you never had to write down. “Write clear, professional dispatch notes” teaches it none of them.
The steps are numbered on purpose. Sequencing is an instruction. A paragraph of intent is not.
The constraint is a number: 300 characters here, two pages elsewhere, whatever the real limit is at your shop. Give the figure. And say what you want when the model comes up short, which is the last line of the prompt above. That sentence is what stops it inventing a phone number.
How much context should you give an AI model?
The newer models are action-oriented. They take longer to come back because they are doing work in between: opening documents, calling tools, checking themselves.
Underspecify and that work goes sideways. The model does not know where to look, so it reads through a pile of the wrong documents, burns time and tokens, and hands you something you cannot use.
Overspecify and it stops listening. We did this to our own agents: we connected every tool we had to them rather than the ones each job needed, and they ignored the instructions altogether. The brief was fine. It just was not being read.
The middle ground is enough context to know what to do and nothing past that, which is the same discipline as managing a context window. The stronger the model, the more the mistake costs you.
How to write follow-up prompts
Most people put real effort into prompt one, then follow up with “make it shorter” or “try again”. The follow-ups are where the output gets shaped, and two words give the model nothing to shape it with. Write the second and third prompts as briefs too: the role stays, the examples stay, and the task becomes whatever you now want fixed.
Do this for the work you would have checked if a junior employee produced it, and for anything you have handed to an agent that runs while you are on a roof or on a call. How much rope that agent gets is the next lesson, agent autonomy.
