Why models agree with you
Working through a hard problem with a language model can feel unusually productive. You describe the competitors, ask for an angle nobody has taken, and the reply tells you the direction you were already leaning towards is a strong one. It reads like confirmation from a well-read colleague who did the reading you skipped.
Sometimes it is. More often it is a property of the model. Language models are tuned against human feedback, and answers that agree with the person asking get rated more highly than answers that contradict them. What comes out the other side leans towards agreement, and it leans hardest once you have signalled what you want to hear. Even top AI companies are aware of this — OpenAI published a note on how it was addressing sycophancy in GPT-4o in 2025.
Founders building their first digital product carry most of this risk. A model that approves of every technology choice will help you ship version one quickly. The bill arrives later, when the stack you were encouraged to pick turns out to be the wrong one to grow on and the cost of changing it is measured in months rather than days.
Switching to a better model does not fix that. A prompt can, if it leaves no room to agree, because agreement is not one of the outputs the prompt allows. Here are five, along with what each one fails to catch.
The decision we will test
Every prompt below is filled in against the same decision, so you can see what the change in framing does to the answer rather than reading five empty forms.
The decision: an early stage product where the founder has chosen to build the entire backend on a single managed platform, using its hosted database, authentication and serverless functions. Two developers, no operations engineer, launch planned in ten weeks.
To reuse any of these prompts, replace the decision line with your own and leave the rest as it is.
1. Devil's advocate
The simplest move is to give the model a role that fails when it finds nothing wrong. Asked whether your choice is good, it has an easy path to yes. Asked to act as a sceptical architect, it has none, because producing no objections is a visible failure of the role.
The information available to the model does not change. Only the framing does. Compare the question most people actually ask — "we're planning to build our backend on a single managed platform, is that a good choice for an early stage product?" — with a sceptical-architect framing: act as a sceptical technology architect reviewing the decision, told that the goal is not to support the founder's choice but to identify the strongest arguments against it, including hidden technical complexity, long-term maintenance costs, security or compliance risks, vendor lock-in, scaling limitations, and assumptions that may prove false. The prompt asks the model to rank the issues by severity and likelihood, to explain what evidence would confirm or reduce each risk, and — critically — not to invent weaknesses merely to sound critical, explaining under which conditions the original decision would still be justified if it remains reasonable.
Two parts of that prompt do most of the work. Asking for evidence that would confirm or reduce each risk turns a list of worries into a list of things you can go and check this week. The final instruction gives the model a legitimate way to conclude that the decision is sound, and that matters more than it looks: without it, criticism is the only answer available, and you learn nothing from receiving it.
What comes back is not a verdict. A model told to argue against something will argue against it, and the severity rankings only mean anything relative to each other. Treat the output as a list of questions to investigate, and be suspicious of any risk the model cannot attach a specific piece of confirming evidence to.
2. Pre-mortem
A pre-mortem assumes the failure has already happened and works backwards to explain it. It comes from decision research rather than from prompting, and it moves the model off producing a list of possible risks and onto producing a narrative, which is harder to fake and much easier to act on.
The prompt asks the model to imagine it is three months from now and the project has failed badly, names the project and the decision that was made, and asks for a realistic account of how the failure happened — working backwards from the outcome to identify the first warning signs that were ignored, the assumptions that turned out to be wrong, the technical or organisational problems that accumulated, the decisions that were difficult to reverse, and the information that should have been collected before starting. It closes by asking for five preventative actions to take now, and explicitly rules out generic risks that could apply to any project.
A story has to hold together. A list can contain a risk that would never realistically occur alongside the others; a narrative has to explain how one problem led to the next. That constraint surfaces the compounding failures, where a limitation that was tolerable in month one got expensive once three features depended on it.
Keep the last instruction. Without it you get a competent description of how any software project fails, which you already know.
The output is only as good as the specificity of the project description. Describe your product in one abstract sentence and the model has nothing to work with; it will produce the generic version whatever else you asked for. It also anchors on the horizon you set. Failures that take a year to appear stay invisible at three months, and that covers most cost and scaling problems. Run it again with a longer window.
3. Unknown unknowns
The hardest gaps to close are the ones you do not know are gaps. Asking a model to be radical will not find them. Asking it to name the categories that evaluations of this kind routinely leave out is a narrower question, and an answerable one.
Worth setting expectations before you run it: the model cannot tell you which of the areas it names applies to you. Whether your data residency obligations are real depends on where your customers are and what you store, and it knows neither unless you have said so. You are generating questions for a lawyer, an accountant or a senior engineer, not answers from one.
The prompt names the decision, lists the criteria already considered — development speed, monthly cost at current usage, the team's existing familiarity with the platform, and time to launch — and asks the model not to repeat those, but instead to look for risks, dependencies and constraints that teams commonly overlook: legal or regulatory requirements, data ownership and deletion, backup and recovery processes, reliance on third-party providers, internal skills and staffing, accessibility, migration and exit costs, and decisions controlled by other teams. For every overlooked area it asks why it matters, how it could affect the project, and which question to investigate next, and to separate plausible blind spots from highly speculative ones.
Listing the criteria you have already considered is what makes this version work. It closes the exit the model would otherwise take: restating your own reasoning back to you in different words and calling it analysis.
The final instruction earns its place for a different reason. Once a model is asked for overlooked risks it will keep finding them, and an unranked list of thirty concerns is as unusable as no list at all. Splitting plausible from speculative gives you something you can triage.
4. Comparing alternatives
Ask a model to review one option and you invite approval of that option. Ask it to compare four against the same criteria and you get a table. A table is much harder to fill in flatteringly, because every strength you claim for your preferred choice has to be scored against the others in the same row.
The prompt states the problem to solve, the current preferred solution, and the important constraints — two developers, no operations engineer, ten weeks to launch, a low monthly budget, and customer data that includes personal details — then asks the model to select three genuinely different alternatives, including the option of keeping the current process where appropriate, and compare all options on the same criteria: implementation time, initial and ongoing cost, technical complexity, scalability, security and compliance, vendor dependence, maintenance requirements, and reversibility. It asks for the comparison as a table, a recommendation for the stated constraints, what new information could change that recommendation, and an explicit instruction not to favour the current preferred solution simply because it was mentioned first.
Copy two details into your own version. Including the option of changing nothing keeps a realistic baseline in the comparison, and for early stage products it is often the option that quietly wins. Asking what new information would change the recommendation tells you which single fact is carrying the decision, usually the one thing worth spending a day verifying.
The comparison is only as honest as the constraints you state. Give a model no budget, no timeline and no team size and it will compare the options on general merit, and general merit favours whatever is most widely written about rather than whatever fits two developers with ten weeks. The final instruction reduces the anchoring effect rather than removing it, which is why running the comparison twice, described at the end of this article, is worth doing on any comparison that matters.
5. Other people's seats
A decision that is obviously correct from your seat looks different from someone else's. Adding one managed provider is a quiet afternoon for a backend developer and a new vendor assessment for whoever owns security and compliance. A model is a fast way to see the cost your decision transfers to other people before they find it themselves.
The prompt names the decision and asks the model to analyse it from five viewpoints — a software engineer responsible for implementation, a security or compliance specialist, a finance manager, an end user, and an executive accountable for the outcome — and for each person to explain what they are likely to support, what they may object to, which risks they would notice first, and what evidence they would request before approval. It closes by asking the model to highlight conflicts between the perspectives, and not to force agreement or produce a compromise unless the evidence supports one.
In a small company most of these roles sit with the same one or two people. That does not make the exercise pointless, but it does change what you get from it. You are modelling the questions coming later from an enterprise customer's procurement team or an investor's technical adviser, so the fourth item — what evidence each person would request — is the part to keep.
The instruction not to force agreement is the one people leave out, and it does the most work in the prompt. Left alone, a model resolves the tension for you and hands back a balanced summary in which everyone is broadly satisfied. The conflicts are the useful part. They tell you which conversation you are going to have to have, and what evidence you will need when you have it.
Using the techniques together
None of these is a general purpose upgrade to paste in front of every question. They answer different questions and they work best in a rough order.
Start with the comparison. Widening the option set is worth more than stress-testing a choice you made before you knew the alternatives. Run the devil's advocate prompt on whichever option survives. Use the unknown unknowns prompt when the decision touches other people's data, money or obligations, where the expensive surprises live. Save the pre-mortem for the point just before you commit, while there is still a version of the project that can change. Bring in the perspective prompt when the decision needs approval from anyone who was not in the room.
All of this costs time and attention, and it is easy to spend both on decisions that did not need them. Reversibility is the criterion that works, and it is also why reversibility sits in the comparison table. A choice you can undo in an afternoon does not deserve a pre-mortem. A choice that will be load-bearing in six months and would take weeks to unwind deserves all five.
A critical model is still not evidence
Be clear about what these prompts change. They do not make a model more truthful. They change what it is agreeable towards. Ask for the strongest case against your decision and you will get the strongest case against your decision, whether the decision is sound or not. A model that criticises confidently is no more reliable than one that approves confidently.
That is still progress, because the failure mode is now visible instead of hidden. A list of specific objections can be checked. Unspecified approval cannot.
The checking happens outside the conversation. Structured disagreement sits alongside reading the primary documentation for the limits the model asserts, building a small spike that exercises the one thing you are least sure about, talking to someone who has run the same stack in production, pricing the decision against your own projected usage rather than a general claim about cost, and writing down the decision, the alternatives you rejected and the conditions that would make you reverse it.
The last one earns its twenty minutes on its own. Three months later the question is rarely what you decided. It is what you believed at the time, and whether that belief has since turned out to be wrong.
Try it on a decision you have already made
A model that agrees with you is not giving you a second opinion. It is giving you your own opinion with better formatting. Getting something more useful out of it is mostly a matter of writing prompts that make agreement structurally unavailable.
Take a decision you made this month and run the comparison prompt on it twice. The first time, name your preferred option. The second time, describe only the problem and the constraints and say nothing about what you have chosen. If the recommendation changes between the two, you have learned something about the decision and something about the tool.
For further reading, the Nielsen Norman Group and Science have both published research on sycophancy in generative AI chatbots and language models.
If you want a second pair of eyes on a real technology decision, or help putting AI into a process that is still manual, get in touch.