When AI Gives You a Bad Answer, It's Almost Always One of Five Things
August 5, 2026 · 5 min read
The prompt engineering industry would prefer you believe this is a discipline with frameworks, acronyms, and a certification path.
It isn't. Nearly every disappointing result comes from one of five specific mistakes, and once you can recognise them, you have most of what there is to have.
Here they are, in rough order of frequency.
1. Too Vague — or Too Rigid
Everyone knows about vague. Write something professional. Make this better. Help me with my project. These force dozens of guesses: professional in what register, better in which direction, help with what.
The failure mode nobody warns you about is the opposite one.
"Write exactly four paragraphs, each containing exactly three sentences of no more than fifteen words each, using only common vocabulary, with the first word of each paragraph starting with a letter from the word PLAN…"
This is prompting as straitjacket. Constrain the output tightly enough and nothing natural can come out — you get text that satisfies every rule and works for nobody, because the constraints were about the shape rather than the purpose.
The balance point is worth stating precisely: be specific about what matters and flexible about what doesn't. Specify the audience, the purpose, the length if it genuinely matters, the tone, the things that must be included. Do not specify sentence counts, paragraph structure, or vocabulary unless there is a real reason.
Most people who over-specify are doing it because a vague prompt failed and they overcorrected. The fix for vague is not rigid. It is contextual.
2. Information Overload
The mirror of pitfall one, and increasingly common as people learn that context helps.
Everything you know about the project, pasted in, on the theory that more input produces better output. It does not. Buried in six hundred words of background, the actual request becomes one signal among many, and what comes back addresses the context rather than the question.
The discipline is relevance, not volume. Include what changes the answer. Leave out what merely establishes that you know things.
A useful check: for each paragraph of context, ask what would be different about the output if you deleted it. If nothing, delete it.
3. Assuming It Knows What You Mean
This is the subtlest one and the source of the most frustrating failures.
You ask for a summary "for the board." You have a specific board in mind, with a specific chair who hates detail, a specific ongoing dispute about the budget line, and a house style everyone follows. None of that is available. What comes back is a summary for a generic board, which is technically responsive and useless to you.
The same applies to "make it sound like us," "keep it consistent with the usual format," and "you know what I mean." It does not know. It cannot know. Every piece of situational knowledge that lives in your head or your organization has to be stated, and the things most obvious to you are exactly the things most likely to be omitted — because obviousness is what makes something invisible.
Prompt Engineering For Real Work
The practical version: write the request as if for a competent contractor on their first day. Everything they would need to ask about, supply.
4. Emotional Language and Loaded Framing
How you phrase a question shapes the answer, and this matters more than people expect.
Ask why is this approach terrible and you will get a case against it. Ask why is this approach brilliant and you will get a case for it. Both will be fluent, both will cite real considerations, and the deciding variable was your adjective.
This is a serious problem when you are using AI to evaluate something, because it means you can obtain apparent external validation for any position you already hold, and the validation will feel like analysis.
The fix is to notice when you are seeking a conclusion rather than an assessment, and phrase accordingly. What are the strongest objections to this? is a better question than is this a good idea? — and argue against this as forcefully as you can is better than either, because it removes the option of being agreeable.
5. Wrong Tool for the Job
Some tasks are not prompting problems.
If you need current information, the model's knowledge has a cutoff and no amount of phrasing changes that. If you need a specific number from a specific source, look it up. If you need deep domain expertise in a specialised field, you will get fluent output of uncertain reliability, which is worse than nothing when you cannot evaluate it. If the task is fundamentally about judgment — who to hire, whether to take the risk, how a specific person will react — the tool can lay out considerations and cannot make the call.
Recognising a task that does not belong here saves more time than any prompting improvement.
What This Adds Up To
The reason there is no elaborate methodology is that the underlying skill is not technical. It is the ability to describe what you want clearly to something that has no access to your context — which is the same skill as briefing a new colleague, writing a decent ticket, or giving usable directions.
People who are good at this are usually people who were already good at explaining things. That is genuinely all it is.
Two habits are worth building. First, when output disappoints, run the list before rewriting from scratch — it is nearly always one of the five, and identifying which one takes ten seconds. Second, keep the prompts that worked well for recurring tasks. Not a library of a thousand templates you found somewhere, but a handful of your own, for the things you actually do repeatedly. Yours will outperform anyone else's, because yours contain your context.
Prompt Engineering For Real Work: Master AI Tools to Write Better, Lead Smarter, and Deliver Faster covers core principles, crafting clear prompts, iterative refinement, context and roles, the pitfalls above, professional writing workflows, leadership communication, and building your own prompt library.








