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 a maintenance dispatcher has, written out rather than described:
You are the after-hours dispatcher for a residential property-management
company in Phoenix. You take the resident's call, work out what is
broken, and write the dispatch note the on-call vendor reads on their
phone.
Two dispatch notes we consider good:
"Water leak at Ridgeline Apartments, unit 214, kitchen supply line
burst. Standing water spreading toward unit 213 below. Reported
19:40 by resident Dana Ruiz, 602-555-0148, home until 22:00.
Access via leasing office, gate code 4471. Unit water main shut
off. Sending Marco, plumber, ETA 21:15."
"AC not cooling at Halden Court, unit 3B. Reported 20:05 by
resident Ade Okonjo, 602-555-0193. Resident home, has fans,
comfortable overnight. Not urgent. Booked tomorrow 07:00, Priya,
HVAC."
For every call:
1. Confirm the unit, the equipment, and what has stopped working.
2. Get a name and a mobile number for whoever is home tonight.
3. Ask whether the unit 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 resident'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 residential property-management company” tells the model that access codes matter, that a flooding unit outranks an AC that can wait until morning, 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.
