Read it out loud to Claude

Why should the AI push back on my plan?

Ask an AI assistant whether your idea is good and it will usually say yes. That feels helpful. It isn't. If your AI only agrees with you, you're not designing. You're decorating.

The point of step 2 is to find the gaps while they cost a pen stroke to fix. A missing step found now is a line on paper. The same gap found after the build is a migration, a rewrite or a confused user.

How do I get Claude to criticise my app idea instead of agreeing with it?

Set the session up so that agreement is not the easy answer.

1. Load a rule before the first prompt. In my builds I use a Claude skill called honest-advisor: no flattery, no bias toward my framing, no invented facts, and it flags what I didn't ask about. You can download it free. A plain instruction also works: "Argue with this before you write anything."
2. Read the whole page first, with no questions. Give Claude the full picture before it starts answering. A photo of the page plus reading it out loud works well.
3. Then ask the five questions, in order.

The five questions:

1. What's missing from the flow?
2. Which of these ideas is bad, and why?
3. Where does it break at ten times the users, or the day the model is down?
4. What happens when the AI is wrong here, and who notices?
5. What's the simplest architecture that survives those answers?

What does a good answer look like?

A good answer is specific. For question 1, it names a box and who it's for. Generic praise is a bad answer, so push until it names a box. For question 2, it names one idea, one reason and one thing to cut. Ask it to be unkind. For question 3, it names a component and a failure you can picture.

Answer question 4 step by step, because it sets how much the AI is trusted. If nobody is hurt when it's wrong, the step can run on its own. If the worst case is a bad draft, a person checks it. If money or reputation is at stake, a human decides. For question 5, a good answer has fewer boxes than you started with.

The answer you wantA specific box. One bad idea, one reason. A named failure you can picture. Fewer boxes than you started with.

Why out loud, and not typed?

Reading the page out loud makes you say every step in order, so you hear the step you skipped. It also keeps the session a conversation rather than a document review. You answer follow-up questions in your own words, which is where the vague parts show. If you can't use voice, the same five questions typed still work. Keep the order.

How long should the pushback session take?

20 to 40 minutes. Stop when every question has a real answer and every real gap Claude found is now on the page. Don't stop because the page looks finished. End the call when the page is honest, not when it's pretty.

What are the common mistakes?

• Asking "is this good?" It invites a yes. Ask what's missing and what's bad.
• Letting it jump to code. Tell it to stop at the flow. Code comes in step 6.
• Defending the page. You asked for pushback. Write the objection down before you answer it.
• Accepting a vague critique. "Consider scalability" is not an answer. Ask where, and what breaks.
• Ending early because it's late. An honest page saves more time than it costs.

Which template should I use?

The five questions is the script for this session, with what a good and a bad answer look like for each question. Pair it with the honest-advisor skill. Both are free.

What did the pushback look like in the real JobFuture build?

I gave Claude the photo of the page, a short prompt and the honest-advisor skill. Then one instruction: stop at the flow. Claude laid out a seven-step user flow, with what we would store at each step, and listed the problems, most important first.

Claude · from the sessionThe flow is sound, and the confirm-and-edit step is the strongest part. It fixes the biggest weakness of this kind of tool, which is that a job title says little about what someone actually does.

Then I asked the question it never asked: which AI tools does this person already use? One line, and the flow got a new step.

the flow, before any code

All the planning with Claude took about 45 minutes, before any code. Watch episode 1 on the build page.