I rebuilt versions of my first app four times.
At the time, I thought the problem was the tool. Maybe I needed a better AI tool. Maybe a new chat would understand it better. Maybe one more prompt would finally give me what I had in mind.
Many times, it only created another loop.
I would ask AI to build something, get an output that was close but incomplete, explain it again, fix one part, then find another part had moved away from what I wanted. I spent more time prompting and correcting than building.
I do not think that was AI’s fault.
The bigger mistake was mine: I assumed AI could see the product in my head.
It cannot.
AI can work with the context, data, decisions, and details I give it. It cannot work properly with the things I have not said.
The brief in my head was not a brief
In the early days, I treated AI a little like a wishing well. I would describe an idea, ask it to create the product, and expect it to understand the rest.
But an idea in my head has many missing parts. What is the real goal? Who is this for? What has already been decided? What is not allowed to change? Which sources can it use? What does “done” look like?
When those answers are missing, AI still tries to be helpful. It fills gaps. It makes assumptions. It gives a reasonable-looking first version.
That is where the trouble started for me. The output was not always obviously wrong. It was just built on details I had never agreed to. Then I had to untangle the result, start a fresh chat, try another tool, or keep prompting in the hope that the next version would fix the last one.
I have written before about how a quick AI output can create more work later. Why AI Can Make You Feel Busier, Even When It Saves Time was one version of that lesson. This time, I realized that the missing context was often the reason the loop began.
The document I create before I build
Now, before I start a product, project, or any specific task, I discuss it with AI first.
I ask AI to question me from different angles. I want it to bring out not only the details I have not explained, but also perspectives I have not thought about yet. That helps me think more clearly about what I want to build or complete. Once that discussion has enough detail, I ask it to create one document that becomes the source for the work.
I review that document before moving forward.
It does not need to be a big document. For a product, mine usually needs to answer something like this:
PROJECT CONTEXT
Goal: What are we trying to build, and for whom?
Decisions already made: What has been agreed and should not be changed?
Constraints: What must this work not do? Include platform, budget, data, security, scope, or design limits.
Sources: Which documents, templates, or data can AI use? What must it not use, including internal information that should not go to the internet?
Next stage: What is the one task to complete now, and what needs review before the next stage?This is not a magic prompt. It is a shared reference.
The goal stops AI from solving a different problem. The decisions already made stop a suggestion from quietly becoming a new direction. The constraints give it boundaries. The source list tells it what information is safe and relevant. The next stage stops one broad request from becoming a large, unclear build.
One source does not mean one huge instruction
After the main document is ready, I do not ask AI to build everything at once.
For a product, the next document may be the architecture: how the product should be put together based on the source we already reviewed. Then I split the work into stages. At each stage, I say what the task is, which rules it must follow, and what needs confirmation, testing, or review before we continue.
That makes it easier to see what changed and why.
It also makes hand-over easier. If someone else needs to continue the project, they should not have to depend on a long chat history or guess what I meant. They should be able to read the source document, the architecture, the current stage, and the records of what has been reviewed.
For a repeatable task, the source can be much smaller. If I am creating a weekly, monthly, or quarterly PowerPoint, I give AI the approved template, the materials it should use, and the rules for handling the data. The point is the same: do not expect the tool to guess the format, source, or boundary.
NIST AI guidance puts this more formally: define the purpose, context, requirements, and human oversight instead of leaving them assumed. In my own work, I keep it simpler: tell AI what this work is for, what it can use, what it must not change, and what I want it to do next.
What I still keep with me
Good context does not mean I leave the rest to AI.
I still review the main document to make sure it says what I actually meant. I still check the architecture before it becomes the next source. I still test the output, check that the code and documentation are enough, and approve the move to the next stage myself.
AI can ask useful questions, organize the information, and help create the documents. It can also suggest things I may want to use later.
But it should not decide the direction just because I did not explain it yet.
A small change before your next chat
Before you ask AI to build, analyze, write, or prepare something important, do not start with the task alone.
Start with a short context note. Write down the goal, the decisions already made, the constraints, the safe sources, and the one next task.
Then ask AI to tell you what is missing or unclear before it begins.
You do not need to explain your whole project again and again. You need one source that is clear enough for both of you to work from.
