From Prompting the Yes Man to Engineering Reliable AI Workflows
Bad prompts make The Yes Man worse. Vague questions get guessed answers. Wrong assumptions get politely built upon. Here is the seven-step workflow that changes that.
In Part 1 of this series, we met The Yes Man: the character inside an LLM that agrees with everything; not because it has thought about whether you are right, but because agreeing is what the pattern predicts as the most acceptable response. Ask a vague question, and it guesses your intent. Add a wrong assumption to your prompt, and it politely builds on the mistake. Demand a confident answer, and it delivers one whether confidence is warranted or not, which honestly just leaves you sorting through a mess of plausible-sounding hallucinations later.
The problem is not the tool. The problem is treating AI like a magic answer box rather than what it actually is: a fresher who is extremely capable, occasionally overconfident, and entirely dependent on the quality of the brief you give them.
You would not give a junior engineer a one-line task description and then ship their first output unreviewed.
I remember hiring a junior developer in Pune for a 3-month contract. I gave him a vague brief and he spent Rs 45,000 on AWS credits in two days.
So why do we do that with AI? Here is a seven-step workflow that stops that habit.
The difference between a bad prompt and a good one is almost always the same thing: context about what you actually need. A question tells the AI what you want to know. A goal tells it what you are suppose to accomplish. These are different.
The first prompt forces The Yes Man to guess your entire situation. The second gives The Curious Kid the context it needs to actually help.
Actually, I realise this is a tangent, but that goal-setting part is where 90% of prompts fail.
IKIA fills every gap with something plausible. Constraints are basically just you trying to fence in the model before it wanders off into making things up. A good constraint is not just what you want; it is also what you do not want, and what to do when uncertain.
Examples: "Only use information from the document I am pasting below. Do not invent supporting facts. If you are unsure about something, say so explicitly rather than guessing." Each of those three sentences directly counteracts a different bad character: The Yes Man, IKIA, and The Eloquent Speaker.
After the first response, do not accept it. Attack it. Ask: "What are the weaknesses in this plan?" "What am I missing?" "Argue the opposite case." This is the fastest way to surface The Yes Man. If the model built your first response on a wrong assumption you made, it will have agreed with that assumption. Ask it to challenge its own output and watch what surfaces.
From Part 1: ask the AI to argue against your idea, not for it. If it suddenly has a lot to say that contradicts the first response, The Yes Man was there in round one.
Before you use anything that matters, ask the three questions from Part 3 of this series. What is the source? What is the test? What could be wrong? For code specifically: run it. Do not read it and assume it works. The Eloquent Speaker can produce code that looks exactly right and fails at runtime for reasons that are invisible on the page.
When an AI gives you a plan or a process, run the smallest possible version of it first. Not because the AI is probably wrong; but because finding out at small scale costs almost nothing, and finding out at full scale can be expensive. This is standard engineering practice. Apply it to AI outputs the same way.
A junior collaborator who never receives feedback does not improve; and more importantly, you do not learn where they tend to go wrong. When an AI output is not quite right, do not just regenerate. Identify specifically what was wrong and tell it. "The tone was too formal. The third paragraph repeated the first. The constraint I gave about length was ignored." Then re-run. This is the revision loop that turns a first draft into something usable.
Trust is the output of steps one through six; not the assumption you start with. After you have asked clearly, constrained well, challenged the output, validated the facts, run a small test, and reviewed the result... then you can trust it. Conditionally. For drafts, summaries, and structure: high trust, low verification. For facts, citations, calculations, and decisions: earned trust only, after verification.
The Curious Kid earns trust through consistent, surprising usefulness. IKIA loses it through confident inaccuracy. Your job is to run enough steps to know which one showed up.
This series has been building toward one practical place. Part 1: know which character you are talking to. Part 2: understand the mechanism underneath. Part 3: know when to verify and how. Part 4: build the workflow that makes it reliable.
The goal is not to make AI perfect. It cannot be made perfect. The goal is to build a process that catches the imperfections before they reach the places where they matter.
The junior collaborator is only as reliable as the process the senior builds around them. :)