Skip to main content
·8 min read

How I Get AI to Tell Me I'm Wrong

I pitched a product idea to a model last year and it told me the idea was strong, the timing was good, and the positioning was clear. I felt great for about ten minutes. Then, out of curiosity, I opened a new chat and pitched the *opposite* idea — same market, inverted premise. It told me that one was strong too.

That was the moment I stopped treating AI as a second opinion and started treating it as a mirror with good manners.

The default behavior of every model I use is to find the merit in whatever you put in front of it. Ask "is this a good idea?" and you're not asking a question, you're requesting a compliment. And the worst part is it doesn't feel like flattery — it comes back with reasons, structure, three supporting bullet points. It sounds like analysis. It's just agreement wearing a suit.

If you want a model to be genuinely useful on decisions, you have to build the disagreement into the prompt. It will not volunteer it.

Why "be honest with me" doesn't work

The first thing everyone tries is asking for honesty. "Be brutally honest." "Don't just tell me what I want to hear." "Give me real criticism."

I used these for months. They produce a specific and very recognizable output: the model says something mildly critical about a minor point, then spends the rest of the response explaining why the thing is good anyway. "One thing to consider is pricing complexity — but your core value proposition is compelling enough that..." That's not criticism. That's a compliment with a speed bump in it.

The reason it fails is that "be honest" isn't an instruction the model can act on. It's a vibe. It doesn't change *what job the model thinks it's doing*. It still thinks its job is to evaluate your idea, and its evaluation instinct is calibrated toward the charitable read. You've asked for a different tone, not a different task.

What actually works is changing the task. Don't ask for an honest evaluation — ask for something where the only way to succeed is to find problems.

Move #1: assign the failure, don't ask about it

The single highest-leverage change I made was to stop asking "will this work?" and start telling the model that it *didn't* work.

This project launched 12 months ago and it failed. It's dead — we shut it down. You're writing the post-mortem. Your job is to explain exactly why it failed: the specific assumption that turned out to be false, the moment it became unrecoverable, and what the early warning signs were that we ignored. Don't hedge, don't say "it might have." It failed. Tell me how.

The difference is night and day, and the mechanism is simple: I removed the question the model wanted to answer generously. There's no "is this good?" left to be charitable about. The outcome is fixed, and the only task remaining is causal explanation. Now the model's helpfulness works *for* me instead of against me — it's trying hard to give me a good post-mortem, and a good post-mortem is a list of the real weak points.

I do this before every significant commitment now. The failure modes it surfaces aren't always right, but they're always specific, and specific is something I can check.

Move #2: make it argue against itself

When I already have a plan and I want it stress-tested, one critic isn't enough — because a single critic will still soften. So I make the model take both sides and then force a verdict.

Take my plan below and build the strongest possible case FOR it — the version a smart advocate would make. Then build the strongest possible case AGAINST it — the version a smart skeptic who wants to kill this would make. Make both arguments genuinely strong; if the case against is weak, you're not doing your job. Then, in a final section, tell me which case is more convincing on the evidence and why. You must pick one. "It depends" is not an answer.

The forced verdict at the end is the part that matters. Without it you get two balanced paragraphs and a diplomatic shrug, which is where models love to land. Making it commit means it has to actually weigh the arguments rather than just list them.

The other thing this catches: when the case *against* comes back weak and generic, that's information too. Sometimes it means my plan is solid. More often it means I didn't give it enough real detail to attack, which tells me my own thinking is still vague.

Move #3: give the critic a name and a reason to care

Generic criticism is generic because "a critic" isn't a person with anything at stake. When I want feedback that bites, I give the model a specific role with a specific incentive — someone who loses something if they're wrong about me.

You're the engineer who will have to maintain this codebase for the next three years after I leave the company. You get paged at 3am when it breaks. You do not care about my deadline and you have no reason to be polite. Read this design and tell me what's going to make your life hell. Be specific about which part, and what the 3am failure looks like.

Compare that to "review this architecture and give me feedback," which reliably produces a list of best practices that could apply to any codebase ever written. The incentive is doing the work here. A maintainer who gets paged has a reason to find the thing that breaks at 3am, and the model can reason about what that person would actually notice.

I swap the role depending on what I'm testing. The competitor who wants to eat my lunch. The customer who cancelled after two weeks and is telling a friend why. The journalist writing the unflattering version of the story. Each one finds different problems, because each one is looking for something different.

What I do with the criticism

Getting the criticism is only half of it. The other half is not overreacting to it, which took me embarrassingly long to learn.

A model that's been instructed to attack will attack, and some of those attacks are noise. It will invent plausible-sounding failure modes for things that are actually fine, because you told it to find failures and it's obedient. So I don't treat critical output as truth any more than I treated the flattery as truth. The output isn't a verdict, it's a list of things to go check.

My filter is simple: for each criticism, can I name a real, specific reason it's wrong? Not a feeling — a reason. If I can, it's noise and I drop it. If I find myself getting defensive and vague, or writing a rebuttal that sounds like marketing copy, that's the one that's real. The criticisms that make me uncomfortable in a way I can't immediately articulate are the ones worth a day of thought.

The other habit: I run the critique *before* I've built anything, not after. Criticism of a plan is cheap to act on. Criticism of a finished thing mostly just makes you sad, because by then you're not evaluating the argument, you're defending a month of work. The post-mortem prompt costs me ten minutes at the start and has killed two projects that would have cost me two months each.

The pattern underneath

Every one of these moves is the same trick: don't ask the model to be critical, put it in a position where being useful requires being critical. Tone instructions bounce off. Task structure doesn't.

The model isn't being dishonest when it flatters you. It's doing exactly what it was built to do — be maximally helpful given the framing you handed it. If your framing is "here's my idea, thoughts?", the helpful move is encouragement. If your framing is "this is dead, write the autopsy," the helpful move is a scalpel. You get to choose which one you asked for, and most people don't realize they're choosing.

These three prompts are permanent residents of my library, and they're the ones I reach for most often — not because they're clever, but because I would never write them in the moment. When you're excited about an idea, "tell me why this failed" is the last sentence you want to type. That's exactly why it has to be saved and ready, so it takes one click instead of an act of will. That's most of what Super Prompts is for me: the things I know I should do but won't reinvent when I'm feeling optimistic.

So next time you catch yourself asking a model whether your idea is any good, notice what you're really asking for. Then close that chat and tell it the idea already died. The answer you get back will be worth a hundred of the ones you were fishing for.

If you want the prompts that push back instead of cheering you on, keep them somewhere you'll actually find them — Super Prompts is free to start.

Save these prompts in one place

Super Prompts lets you organize, search, and reuse AI prompts across 25+ tools. Free to start.

Try Super Prompts Free