Argue The Other Side

The most expensive thing an AI assistant does for you is agree.

Not hallucinate. Not get a number wrong. Those are visible and you catch them. The expensive one is when you describe a plan you've already half committed to, and the machine says that's a solid approach, and then helpfully organizes your existing thinking into a tidy five point structure that makes the plan feel more considered than it actually is.

You didn't get analysis. You got a better looking version of the thing you walked in with. And because it came back organized, you trust it more than when it was a mess in your head, which is precisely backwards. The mess at least felt uncertain.

I've watched people hire, fire, sign leases, and drop product lines off the back of a conversation where the model never once told them no. Not because the model is a suck up, though it leans that way. Because they never asked it to be anything else.

Today's prompt fixes that. It's the one I run before any decision I can't cheaply reverse, and it's genuinely unpleasant to read the output, which is the entire point.

Most people already try some version of this. They ask for the downsides. They ask what could go wrong. They ask for a devil's advocate take.

What comes back is a list of generic risks. Market conditions could change. Execution might be harder than expected. You may face cash flow pressure. Competitors could respond.

All true. All useless. None of it is about your plan specifically, none of it is ranked, and none of it tells you what to actually do differently on Monday. You read it, you nod, you feel like you did your due diligence, and you proceed exactly as you were going to.

The failure is structural. You asked an assistant that is optimized to be helpful to generate objections while it still knows you want the plan to work. It will produce objections shaped like a formality, because that's what you signaled you wanted.

The fix is to change the assignment. Don't ask for risks. Assign a role with a stake, give it a specific target, and demand the output in a shape that forces ranking and specificity.

Copy this whole thing. The structure is doing the work, so resist trimming it down on the first few runs.

You are a skeptical operator who has run a business the size of mine for fifteen years and has personally lost money on a decision like the one I'm about to describe. You are not my advisor and you are not trying to be encouraging. Your job is to build the strongest possible case that this plan is a mistake.

Here is the plan: [describe it in plain language, including the money, the timeline, and what you're giving up to do it]

Here is what I already know is risky: [list what you've already thought of]

Do not repeat anything on that list. Do not give me generic business risks that would apply to any plan. Every objection must be specific to what I described.

Give me exactly six objections. For each one, give me these five things in this order:

1. The objection in one sentence.
2. The specific thing in my plan that creates it.
3. What it costs me in dollars or months if it happens, with your estimate and your reasoning for that estimate.
4. How likely you think it is, as a percentage, and what you based that on.
5. The cheapest test I could run in the next two weeks that would tell me whether this objection is real, before I commit the money.

Then rank all six by expected cost, which is your dollar estimate multiplied by your probability. Show the arithmetic.

Then answer one final question in no more than four sentences: if you had to pick the single assumption in my plan that, if wrong, breaks everything else, which is it and why?

Where you are guessing, say you are guessing. Do not soften anything. Do not end with encouragement.

The role matters and it's not decoration. "You are a skeptical operator who has lost money on a decision like this" gives the model a position with consequences attached. A generic devil's advocate has no skin in it and produces debate club output. Someone who got burned produces the specific thing that burned them.

"Here is what I already know is risky" is the most important line in the prompt and the one people skip. Without it you get your own concerns handed back to you in nicer language, and you mistake the echo for confirmation. Listing your known risks forces the model past them into territory you haven't covered. This is where the useful stuff lives.

Six objections, not five and not ten. Under five and you get only the obvious ones. Past six or seven the quality collapses into padding, because it's filling a quota rather than reasoning.

The dollar and probability columns are what separate this from every risk list you've ever read. The moment a model has to attach a number to an objection, vague concerns either sharpen into something real or fall apart. Some of the numbers will be wrong. That's fine. You are not outsourcing the estimate, you are forcing the objection to take a testable shape.

The two week test in item five is the part that actually changes your Monday. An objection you can't check is anxiety. An objection with a cheap test attached is a task. This is what turns the output from something you read into something you do.

The ranking with visible arithmetic stops you from fixating on the scariest sounding objection instead of the most expensive one. Those are rarely the same. The scary one is usually low probability and vivid. The expensive one is usually boring and likely.

And the load bearing assumption question at the end is the single highest value line in the whole thing. Most plans don't fail from a risk you listed. They fail because one quiet assumption underneath all of it was wrong, and everything you built on top came down together.

Run this after you've read the first output and picked the two objections you think matter most.

Take objection number [X]. I think my answer to it is [your rebuttal]. Tell me where my rebuttal is weak. Be specific about which part of it depends on something I haven't verified. Then tell me what I would need to see, concretely, to be justified in believing my rebuttal.

This is where it gets useful, because your rebuttals are where your real blind spots are. You've thought about the risks. You haven't stress tested the reasons you dismissed them.

The first is that you run it, read six brutal objections, and quietly conclude the plan is bad. That is not what the output means. You explicitly asked for the strongest case against, so a strong case against is not evidence, it's compliance with your instructions. The same prompt run against a genuinely excellent plan will also produce six objections that sound serious. What you're looking for is not whether the objections exist. It's whether the top ranked one has a cheap test and whether that test comes back clean.

The second is running it too late. If you've already told your team, already told your spouse, already mentally spent the outcome, you'll read the output looking for reasons to dismiss it and you'll find them. Run this before you announce anything. The value is in the window where you can still change your mind for free.

A guy I know runs a nine person agency and was about to bring media buying in house. Hire two people, roughly 190 thousand a year loaded, kill the contractor relationship he'd used for four years. His logic was margin. He was paying out about 24 thousand a month and keeping a thin slice.

He ran this prompt. Five of the six objections he'd already thought about in some form.

The sixth one he had not. It pointed out that his contractor's platform access was under the contractor's business manager, not his, on roughly two thirds of his client accounts. Cutting the relationship meant either renegotiating access with fourteen clients at once, which turns an internal operations change into fourteen uncomfortable conversations about why things are changing, or rebuilding history from scratch and losing the optimization data. Estimated cost, forty to seventy thousand in churn and performance dip. Probability, 55 percent.

The two week test was one line. Log into each client account and check who owns the business manager.

He did it in an afternoon. It was worse than the model guessed. Eleven of fourteen.

He still brought it in house. He just did it over five months instead of five weeks, moving access account by account while the contractor was still cooperative and still getting paid. The plan survived. The sequence changed, and the sequence was the whole thing.

That's the realistic return here. Not talking you out of things. Finding the one operational detail sitting underneath your plan that nobody on your side of the table was incentivized to look for.

Small thing that turns this from an occasional exercise into an actual asset. Save every run in one place, with the date, the decision, and what you ended up doing.

Six months later, go back and read them. You'll find that the model's probability estimates were systematically off in a consistent direction, and more usefully, you'll find that your own dismissals were wrong in a consistent direction too. Most people over dismiss operational objections and under dismiss market ones, or the reverse, and you cannot see your own pattern from inside a single decision.

That log is worth more than any individual run. It's the only way I know to actually calibrate your own judgment rather than just feeling calibrated.

That's the real instruction. This prompt is worthless on decisions you're genuinely torn about, because you're already looking for problems there and you'll find them without help.

Run it on the one you've stopped questioning. The hire you're certain about. The tool migration everybody agrees on. The client you're about to fire. The price increase you've already decided is fine.

Certainty is the tell. It's not usually a sign you've thought it through. It's usually a sign you stopped.

See you tomorrow.

Jordan Hale
The AI Newsroom