Ten Conversations to have with Claude before Vibe Coding

Different people will "code" with AI differently. I get that. And I'm not suggesting there's one specific right way to do it. But the more conversations I have with people, the more I notice two camps.

The first camp is the "software from one prompt" folks. They write their wish for what a product could do (goal), how they want to work with it (experience), all in a single prompt. Then they let the AI make every other decision.

The second camp is the "product engineer" folks. They work with AI in conversations to discuss a concept (idea), dig into it (research), figure out flows (use cases), land on a concept (vision), build out the requirements (spec), ask for the backend features (server), work on the experience (UI/UX), build out an entire test suite (QA), and maybe even run sample data through the whole thing (simulations).

Of course, anytime someone tells you there are two kinds of people in the world, I think of that Bill Murray line from What About Bob? ("There are two types of people in this world: those who like Neil Diamond, and those who don't.")

The truth is that those two camps are dots on a long continuous line, with people scattered across it. But I'm in the second camp. And if you're in the first camp, thinking the only way to do this is to hire someone, today I want to walk you through how you can do it yourself.

You can do this in Codex with GPT 5.5, Claude Code, or, more slowly, in ChatGPT and Claude.ai.

Think of this as the Ten Conversations you'll have with AI. Each one refines what you're looking for. And the very nature of having ten conversations instead of writing one little prompt will have an incredible impact on what comes out the other side.

Imagine creating a project in Claude.ai, named for your product. You'll have ten conversations inside it. The first nine each end with an artifact, markdown or HTML, that you save to the project. The tenth is different. That's where Claude reads everything you've produced, looks for fissures in the articulation, interviews you to close them, and writes the reconciliation as its own artifact.

When you're done, you'll have ten documents that don't fight each other. Pass them to any AI and you'll get software that's so much better than anything a single prompt could have produced.

Conversation One: The Big Idea

You're not pitching. You're thinking out loud. You tell Claude what you've been chewing on. The problem you keep running into, the workflow that frustrates you, the gap you've spotted. You're testing whether the idea has legs at all.

Claude plays back what it heard, asks what's actually broken about the current state, and probes whether this is a vitamin or a painkiller. You leave with a one-paragraph statement: who it's for, what it does, why it matters.

Conversation Two: The Differentiating Context

Now you stress-test the idea against the world. What else exists? Why hasn't this been built? If it has, why does yours need to exist? This is where you find your wedge. The angle nobody else is taking, the audience nobody else is serving, the constraint nobody else is honoring.

You ask Claude to research the space, find adjacent products, and surface the assumptions everyone in the category shares. Then you decide which ones you're going to break.

Conversation Three: User Paths Through the Story

You stop thinking about the product and start thinking about people. Who shows up? What were they doing five minutes before they opened your tool? What are they trying to get done? You walk through three or four real user journeys, narrated as little stories.

This is the demand-side layer. Not features. Not screens. Just: "Maria gets a Slack ping at 4pm. She needs to finish something before her 5pm. She opens this and..."

Conversation Four: Pulling It Into a Single Vision

Here you converge. You hand Claude the first three artifacts and ask it to synthesize a vision document, the kind of thing you'd hand to a co-founder. What's the product, who's it for, what does it do, what does it explicitly not do, what does success look like 12 months in?

You're looking for tension. If Conversation Two said "for enterprise" and Conversation Three only showed solo users, you catch it here.

Conversation Five: Breaking Apart the Requirements

Now you go granular. Functional requirements. Non-functional requirements. Must-haves and nice-to-haves. What does the MVP look like and what's explicitly deferred? You're translating vision into a buildable list.

Claude helps you spot requirements you're assuming but haven't stated. The ones you'd otherwise discover three weeks into a build, when fixing them is expensive.

Conversation Six: The Architecture Discussion

This isn't a deep tech conversation. Think of it as higher-level shape plus a dash of preferences.

Is this a SaaS where users log in? Does it need to support a lot of different companies, each with their own data? (You don't have to know the term multi-tenant. Just describe what you want.)

How much data does the first version need to support? Are you thinking 10 customers with 3 logins each? Or seeding it with 1,000 customers from day one? What about your catalog? 3 products or 300? These answers shape architecture decisions you don't have to make yourself, but you do have to inform.

And do you have preferences? You want this on Cloudflare? You need it in Azure because that's where your company lives? You want a mobile experience with a tablet-friendly web view alongside it?

You're not picking frameworks. You're telling Claude the shape, the scale, and the surface, so the architectural decisions get made against your reality instead of a generic default.

Conversation Seven: Iterating on the User Experience

Back to the human side. Given the requirements and the architecture, what does the experience feel like? You walk through key screens and flows in words. Where does the user start? What's the first thing they see? What's the moment of value?

You're not designing pixels. You're describing the choreography. What happens on their first visit? Their hundredth?

Conversation Eight: Looking for Cracks

This is where you list every place something could go wrong, and decide what the app should do when it does.

You walk through it together. What if someone types the wrong thing in a form? What if a payment doesn't go through? What if the internet drops mid-save? What if a user uploads a giant file? What if they click the same button twice?

For each one, you decide. Stop everything and back out? Try again quietly in the background? Show the user a clear message and tell them what to do next? Or just write it to a log so you can look at it later?

Better to decide now, in a conversation, than at 11pm on a Tuesday when it's already broken.

Conversation Nine: Simulating Users

You don't trust yourself to find the seams. One human, clicking through once or twice, will miss things. So you spec a second system whose entire job is to stress-test the first one.

You describe what the simulation platform needs to do. Generate synthetic users with different profiles. The cautious one, the impatient one, the one who fat-fingers every form, the one who opens fourteen tabs. Define the flows it needs to exercise. The happy paths, the side paths, the recovery paths, the abandonment paths. Decide how many runs gets you to confidence. Fifty? Four hundred? Four thousand?

You think through what gets measured. Pass/fail on each scenario. Where users got stuck. Which failure modes from Conversation Eight actually fired, and whether the failure policies behaved the way you said they should. Performance under concurrent load. Data integrity after thousands of writes.

You're not building the simulator yet. You're describing it well enough that it can be built alongside the product, or after, and run against the real thing. This is the conversation where you admit your own QA pass isn't enough, and you design the system that will be.

Conversation Ten: Interview to Fix the Gaps

You load the first nine artifacts. You ask Claude to read everything, find the fissures in the articulation, surface the places where Conversation Four says one thing and Conversation Seven implies another, where the requirements in Five don't match the architecture in Six, where the simulation spec in Nine tests for things the product spec never promised.

Then Claude interviews you. One question at a time, until everything reconciles. You answer. It writes the reconciliation. That document becomes the tenth artifact, the one that confirms the other nine agree with each other.

What you walk away with

When you're done with these ten conversations, you'll have a folder of artifacts. You can hand it to Claude Code. You can hand it to Codex. You can hand it to any harness you trust. You can also just ask Claude.ai or ChatGPT to build the first bits, file by file, and save them to a folder as you go. (If you don't know how to structure the folder, ask. You'll get specifics.)

But my point today isn't how to generate code. It's how to have the conversations that need to happen before any code gets generated.

The one-prompt camp will get something. The ten-conversation camp will get something better. Not because they typed more, but because they thought more, out loud, in conversation, with something that pushes back.