Getting real critique from AI

Day 14: Ask 'What would make this wrong?' instead of 'Any concerns?'

Ask an AI 'Any concerns?' about your plan and you'll get a reply you could staple onto a wedding seating chart. Review is the step where AI can actually save you weeks, and that question nearly guarantees a soft answer. The plan goes ahead untested, and you meet the problem later, in production.

The reply you've seen a hundred times

You paste in your plan, type 'Any concerns?', and get this back:

This is a solid plan! A few things to consider:

1. Scalability – make sure the system can handle growth in users and data.
2. Security – ensure proper authentication and data protection.
3. Error handling – plan for edge cases and failures.
4. Monitoring – add logging and alerting so you can catch issues early.
5. Stakeholder alignment – keep the team and users informed.

Overall, you're in great shape. Let me know if you'd like help with implementation!

Read it again and look for one sentence that's only true of your plan. You won't find one. Attach the same reply to a payments migration, a hiring process or that seating chart and it still sounds sensible. Nothing in it can be wrong, which is exactly why none of it helps.

You asked for a critic. You got a cheerleader with a checklist.

The reframe: the model mirrors the stake you seem to have

Part of the politeness is baked in: these models are trained in a way that leans them toward agreeing with you. But a lot of it comes from how you asked. Early in this series we saw that context shapes output. This is that same effect, aimed at critique. 'My design' says you own it. 'Any concerns?' says you'd like reassurance with a couple of caveats. And asking in the same chat where it helped you write the plan makes things worse, because now it's being asked to pick apart its own work along with yours. Every one of those signals pushes toward a gentle answer, and the model usually goes where it's pushed.

So telling it to 'be brutal' isn't the fix. Take away its reasons to be gentle, then ask a question that a generic list can't answer.

Two questions that look alike and aren't

'What are the risks?' and 'What would make this wrong?' sound like near neighbours. They get you very different answers.

| Question asked               | Kind of answer you get                         | What you do with it                         |
|------------------------------|------------------------------------------------|---------------------------------------------|
| "Any concerns?"              | Reassurance plus generic caveats               | Feel good, change nothing                   |
| "What are the risks?"        | A risk register: a list of things that might    | Note them, nod, move on                     |
|                              | go wrong, each one weighted the same           |                                             |
| "What would make this wrong?"| A falsification test: one specific assumption, | Go and check it before you build            |
|                              | plus what you'd observe if it were false       |                                             |

A risk register lists things that could happen to the plan. A falsification test names the thing the plan rests on. You read the first one. You act on the second, and the action is usually small: a query, a phone call, ten minutes in a dashboard.

What it looked like at PhoenixDX

We had a design for a feature that summarised recent activity for users, with an LLM agent writing part of each summary. I asked the usual 'any risks with this design?' and got the usual list: latency, cost, prompt injection, monitoring. Every point was fair, and we already knew all of them.

So I opened a fresh session and presented the design as another team's proposal that I had to approve or reject. Then I asked which single assumption it depended on most. This time the answer was specific. The design assumed the data it read was close to current. If that was false, users would get summaries of a state that had already changed, and because the summaries were well written, they'd look authoritative.

We checked that afternoon. The source we planned to read from refreshed on a slower schedule than any of us had assumed. Nobody had lied about it. We just hadn't asked. The fix meant changing where the feature read its data from, and that's a design change, not a bug fix.

I don't want to oversell this. The model knew nothing about our data pipeline. It pointed at the spot where the plan was load-bearing, and we did the checking. The win was modest but real: one afternoon spent, where otherwise we'd have found out a sprint into the build.

The prompt, in four parts

• ▹1. A fresh chat. No history of you writing the plan, and no earlier back-and-forth where the model helped shape it. It should have nothing to defend.
• ▹2. Remove ownership. Present the plan as someone else's proposal that you're deciding on. That moves the model out of the collaborator seat and closer to the reviewer's chair.
• ▹3. Ask for the load-bearing assumption. You want one assumption, what you'd observe if it were false, and how cheaply you could check it.
• ▹4. Give it an off-ramp. Say outright that 'nothing serious' is an acceptable answer. Without that permission it will often invent something to fill the space.

A team has proposed the plan below. I'm deciding whether to approve it.
I did not write it and I have no stake in it going ahead.

<paste the plan>

Answer three questions:
1. What single assumption does this plan depend on most?
   Rank by: how much rework would be needed if this assumption is wrong.
2. If that assumption were false, what would I actually observe?
   (A specific number, behaviour, or event, not "issues may arise".)
3. How cheaply can I check it before we build? Name the check.

If you don't see anything serious, say so plainly. Don't pad.
Don't give me a list of general risks.

Why one objection beats ten

Asking for '10 weaknesses of this plan' is tempting, because ten feels thorough. It isn't. Give the model a number and it will hit the number. If the plan has two real problems, you get eight fillers on top. The real one lands at number 7, written in the same tone and at the same length as 'consider documentation', and you skim straight past it.

Ask for one assumption, ranked by how much rework you'd face if it's wrong, and the model has to commit. It picks its strongest point and stands behind it. That's easier for you to judge, too, because a single claim is either checkable or it isn't. With agents the stakes go up. If an agent is about to write a few thousand lines of code from your plan, a wrong assumption gets more expensive with every file it touches. You want the riskiest one named before it starts.

What to do with the answer

Don't argue with the model, and don't ask it to fix the plan in the same breath. Take the assumption it named and check it in the real world before you write code or send the doc. Usually that's one query, one question to whoever owns the system, or a quick look at real data.

If the assumption holds, keep it. Turn it into a tripwire, so the plan carries its own kill-switch after launch. A metric, an alert or a calendar reminder will do. One line is enough:

Tripwire: alert if the source data's last-updated timestamp is older than our freshness threshold when the summary job runs.

An assumption that's true today won't stay true forever. Someone edits a cron schedule, a vendor changes an API, usage shifts. With a tripwire in place, a monitor tells you, not a confused user.

Where this goes wrong

• ▹It can invent a confident objection. Sometimes the assumption it names sounds sharp and turns out not to matter. Sometimes it states 'facts' about your systems that it has no way of knowing. Treat every answer as a hypothesis to check, never a verdict.
• ▹Pushing back in the same chat backfires. Ask 'are you sure?' and it will often fold and agree with you, which is the mirroring problem all over again. If you doubt the answer, open another fresh chat.
• ▹'Nothing serious' counts as an answer. If two separate fresh runs both come back with nothing serious, take the signal and ship. You're looking for the load-bearing assumption, not a reason to keep doubting forever.
• ▹Most work doesn't need it. Skip it for a Slack reply or a small refactor. Use it on decisions that are expensive to undo: architecture, hiring criteria, pricing, and anything an agent will build a lot of code on top of.
• ▹Ownership leaks back in. If the doc you paste says 'I propose' or has your name on it, the model may still pick that up. Strip those out before you paste.

Today's exercise

Pick something you decided this week: a plan, an important email, a hiring rubric, a roadmap item. Open a fresh chat, paste in the four-part prompt, and write down the assumption it names in one sentence. Decide whether it's worth checking, and if it is, check it. If the model said 'nothing serious', run the prompt again in another fresh chat and see whether you get the same answer.

On Day 15 we pick up from there. You have the assumption. How do you get AI to help you check it without letting it mark its own homework?

Extend your knowledge

• ▹Read Gary Klein on the 'pre-mortem' (Harvard Business Review, 'Performing a Project Premortem', 2007). It's the human version of today's habit: imagine the plan has already failed, then explain why.
• ▹Look up Karl Popper's idea of falsifiability. The short version: a claim is only useful if you can say what would prove it wrong. Your plan works the same way.
• ▹Anthropic's prompt engineering docs cover giving Claude a role (system prompts) and reducing hallucinations by letting Claude say 'I don't know'. Those are the closest official cousins of today's ownership and off-ramp ideas.
• ▹Make it a team ritual. Before anyone approves a design doc, one person runs the fresh-chat prompt and pastes the named assumption into the doc's header, along with the check that was done.