Can we talk about the term “prompt engineering”?
I’ve spent my career doing actual engineering. Building distributed systems. Debugging race conditions at 2am. Designing ledger architectures at a financial infrastructure company where a decimal point in the wrong place means real money moves wrong. Engineering has rigor. It has constraints you can’t sweet-talk your way past.
Writing a good prompt isn’t that. It’s writing clear instructions. That’s a valuable skill. It’s not a new engineering discipline.
What This Actually Is
When someone says they’re a “prompt engineer,” what they mean is they’ve gotten good at writing clear, specific instructions for a language model. That’s useful. It’s also something anyone who’s ever written a decent bug report already knows how to do.
Here is the entirety of what works:
- Be specific about the task.
- Be explicit about constraints.
- Be clear about the output format.
- Give an example if the task is ambiguous.
That’s it. That’s the “engineering.”
The Template Everyone Overcomplicates
A prompt that works:
Role: [Who the model should act as]
Task: [What to do]
Constraints: [What to avoid]
Output: [Format expected]
Input: [The actual material]
You don’t need all of these every time. You probably don’t need a 47-step chain-of-thought framework with recursive self-evaluation. You need a clear ask.
I’ve watched people build elaborate prompting frameworks with classes, inheritance hierarchies, and configuration files. For what? For telling a model to summarize a paragraph. The overhead is absurd.
Specificity Beats Cleverness
The prompts that fail aren’t failing because of technique. They’re failing because the author was vague. “Make this better” is a bad prompt. “Rewrite this paragraph in two sentences for a technical audience, preserving the core claim” is a good prompt.
This isn’t a breakthrough insight. This is what writing a good Jira ticket looks like.
The models get worse when prompts are long and contradictory, not when they’re short and clear. More words doesn’t mean more clarity. Usually the opposite.
Where People Waste Time
I see three recurring mistakes:
Prompt archaeology. Spending hours A/B testing whether “You’re an expert” works better than “You’re a specialist.” The performance difference is noise. Spend that time on your actual product.
Framework addiction. Wrapping prompts in three layers of abstraction before you have validated that the output is even useful. Ship the raw prompt first. Abstract later, if ever.
Ignoring the actual failure mode. The model hallucinated because you didn’t provide the context it needed, not because your chain-of-thought phrasing was suboptimal. Ground the model in real data. That’s the fix.
The Part That’s Actually Hard
The real challenge isn’t the prompt. It’s everything around it. Validating outputs. Handling failures. Managing cost. Versioning prompt changes and measuring impact. Building eval sets. Deciding when a model output is good enough to show a user.
That’s engineering. The prompt is just the input.
If you want to call yourself a prompt engineer, fine. But recognize that the hard problems in AI systems have nothing to do with word choice and everything to do with systems design.
My Advice
Treat prompts like specs. Write the smallest prompt that could work. Run it. Look at where the output fails. Fix the spec. Repeat.
Don’t build a framework. Don’t attend a “prompt engineering bootcamp.” Write clear instructions, iterate on failures, and spend your real engineering effort on the system that wraps the model call.
The model doesn’t need a therapist. It needs a clear brief.