Most people think prompt engineering is a technical job. Write instructions, test outputs, ship it.
After leading prompt work across government and enterprise deployments, training bots, call bots, knowledge assistants, I can tell you the technical part is maybe 40 percent of the job. The other 60 percent is something nobody puts in the job description: managing two audiences who never talk to each other directly, and who often want different things.
Here's the actual position. My team builds the AI system for Client. But Client's own customers or citizens are the ones actually talking to it. My client evaluates success by their own criteria: did it match our brand voice, did it follow our process, did it hit the deadline. Their end users judge it by a completely different standard: did it actually solve my problem, did it understand what I asked, did it feel like talking to something competent.
Optimize purely for the client's checklist and you can ship something that technically satisfies every requirement and still fails the moment a real person starts using it.
The Pattern I See Repeatedly
Across different projects, different industries, different scopes, the same failure modes show up.
The bot hallucinates information that isn't in the knowledge base. It sounds confident. It's wrong.
The persona doesn't match what the client actually wants, even when the system prompt says exactly what they asked for. There's a gap between what a client can articulate in a requirements meeting and what they actually mean by "professional" or "friendly."
The knowledge base and the live conversation drift apart. The bot references outdated info, or can't find something that's technically in there because of how the retrieval is structured.
Follow-up logic breaks. The bot handles the first question fine and loses the thread on the second.
None of these are exotic problems. They're the standard failure modes of deploying LLMs against real business knowledge and real client expectations. What's harder to standardize is the fix.
Why "Just Fix The Prompt" Doesn't Work
The instinct, mine included, early on, is to treat every one of these as a prompt engineering problem. Tighten the system prompt. Add more constraints. Hardcode edge cases. Fine-tune the retrieval.
Sometimes that's exactly right. Often it isn't, and here's why: a lot of these failures aren't prompt failures. They're requirements failures. The client described what they wanted in a meeting, using words like "friendly" or "efficient" or "thorough," and those words meant something different in their head than what got built. No amount of prompt tweaking fixes a mismatch that started in the requirements conversation.
So the actual fix usually isn't purely technical. It's going back to the client with specific examples, "here's what the bot said, is this the tone you meant?", and letting them react to something concrete instead of abstract adjectives. It's sitting with actual transcripts of how real users phrase their questions, because what a client assumes users will ask and what they actually ask are often very different.
Sometimes the fix is technical after all. Switching models because one handles a particular reasoning pattern better than another, restructuring the knowledge base instead of the prompt, adding explicit verification steps so the model can't answer from something that isn't grounded in retrieved data.
The skill isn't knowing prompt engineering techniques. It's diagnosing correctly which category a given failure actually belongs to before you start fixing it.
What This Means Practically
On every deployment, there are constraints stacked on top of the technical problem: timeline, budget, data privacy requirements (especially working with government and enterprise clients, where data handling isn't optional, it's contractual), and the tension between what's fast to ship and what's actually reliable.
A hallucination in a casual product recommendation bot is annoying. A hallucination in a bot handling citizen services or financial guidance is a different category of problem entirely. The acceptable failure tolerance changes depending on who's on the other end of the conversation, and that has to shape the engineering approach from day one, not get patched in afterward.
The Actual Lesson
Prompt engineering, at the level where you're deploying to real clients with real end users, stops being about clever instructions and starts being about translation. Translating vague client language into concrete system behavior. Translating real user behavior back to the client so they understand what they actually asked for. Translating business constraints, deadlines, privacy rules, budget, into technical tradeoffs that still hold up in production.
The prompt is the last step, not the first one.
