Talk through the project before AI builds it
How I use a conversation, a second reader, and a few screenshots to turn an idea into something an AI coding agent can build.
Published 2026-08-24
Loading content...
How I use a conversation, a second reader, and a few screenshots to turn an idea into something an AI coding agent can build.
I usually start a project by talking to an AI in voice mode, with no code being written. Before I leave the conversation, I get the product requirements, the subtle feature requests, and an independent reading of what we discussed into files another agent can use.
I usually start building something by having a long conversation with an AI. Often in voice mode, talking out loud the way I would with a friend while trying to understand a problem. I explain what I want, it asks questions back, and we go back and forth until I have a better idea of what I actually need.
At this stage, I don't want code. I don't really want an architecture yet, either. A perfectly reasonable answer might be an existing open source project I can use without building anything myself.
I look for those early. Even when an existing product doesn't quite fit, access to its source gives the coding agent something concrete to inspect. It can see how a similar problem was handled instead of generating the whole solution from a description. Reusing code still means checking its license; using a project as a reference and copying parts of it are different decisions.
I'll usually start with something along these lines. This is an example prompt, not a transcript:
Help me understand this project before we build it. Interview me about
who it's for, what problem it solves, and what would make it useful.
Ask follow-up questions when my answers are vague. Don't write code yet.
Look for existing open source solutions we could use or learn from.
Keep track of decisions, possible features, and unanswered questions
separately so we can turn this conversation into documents later.
I can talk about the main feature, remember something small, change my mind, and come back to the original idea. Voice is good for this because I don't have to turn every thought into a well-formed prompt before saying it.
The conversation becomes a problem when it's the only place any of those decisions exist.
I've written about context poisoning before. Here I mean the practical version where an early wrong assumption keeps influencing the work. If the entire product lives in one chat, starting over also means recovering all the useful details mixed in with the failed attempts. High risk, low reward. The reward is mostly avoiding pesky documentation.
Once the conversation has enough detail, I ask for a product requirements document, or PRD. It describes who the product is for, what it should do, and the constraints we've agreed on. I move it into a separate project folder and start working from there.
The PRD is a starting point. I expect it to change as we learn more.
Before leaving the original chat, I also ask for a feature list. Small requests can disappear during the compression into a tidy product document, especially if I mentioned them once and then spent the next half hour discussing something else. I want those captured even if they aren't important enough to lead the PRD.
When I can export the transcript, I pass it to another AI with no prior context from the conversation. I ask for its understanding as an observer, keeping explicit decisions separate from inferences and unanswered questions. This gives me another reading of the source, including details the original summary might have missed. It isn't automatically more accurate, so I check its inferences before adding them to the requirements.
Then I might open a third chat and ask it to compare the PRD, the feature list, and the observer notes. Where do they disagree? Which feature has no home in the PRD? Was an idea we rejected accidentally included as something we're building?
If there are gaps, an agent can write a focused document for each one and link it from the PRD. I don't need three documents repeating the same paragraph. I need the PRD to provide a map to the details.
My general approach is to have AI write documentation for itself. I'll read the important decisions, but I rarely need every implementation detail written as a tutorial for me.
I want humans reviewing sight, sound, and feel. Can I find the button? Does the animation feel sluggish? Is this how I expected the product to behave? Those reviews need working software or a visual checkpoint, and they need to happen throughout the build.
The documents should make those checkpoints explicit. "Show me the first usable screen" gives me something to evaluate. "Complete the UI architecture" usually doesn't.
There are plenty of good ways to reach this point. Matt Pocock's engineering skills are worth looking at if you want help structuring the planning work. I've written about how I use his skills, but the specific tool isn't a requirement for this process.
Most of my projects have a UI. Screenshots of products I like are useful here, along with a few notes explaining what I like. Maybe it's the density of a settings screen or how little explanation a particular interaction needs. A screenshot without that distinction leaves a lot to interpretation.
I find a small collection of colors, design elements, and app references helpful for personal projects. A vision board is fine. So is a folder. I don't need to invent an entire design system before I can build the first screen.
With the product documents and visual references together, I can open a new coding session and give it the project folder. I still need to choose the first piece to build, but I no longer need to reconstruct the whole conversation before work can start.