How do you gather requirements before you write a single prompt?

You gather requirements by turning the idea in your head into a list of specific, testable things the software must do, written as one-line user stories, split into must-have and later, and checked against real people who would actually use it. Write that list in a plain file before you open your AI coding tool. An AI agent cannot build a feeling and you cannot check whether a feeling is finished, so the idea in your head has to become something concrete enough that you can point at it and say yes, that works, or no, it does not.

I am Mahmoud Zalt, an independent senior AI systems architect. I have shipped production software since 2010, that is 16 years, and I founded Sista AI (sistava.com), where I run a workforce of autonomous AI agents in production, not demos. This is the first real step in The Vibecoder's Handbook, the book I wrote for people building with AI, because almost every abandoned vibe-coded project I have looked at traces back to skipping this exact step and prompting straight from a vague idea instead.

A requirement is testable, a wish is not

Most people start a vibe-coded project with a wish, not a requirement. A wish sounds like "users can log in" or "it should feel modern" or "people can manage their stuff." It feels specific enough while it is still in your head. It is not. Nobody, including you, can look at the finished app and say with certainty whether a wish like that is done, because it was never precise enough to fail a test.

A requirement is one thing your software must do, written plainly enough that anyone, including an AI agent, can tell whether it works yet. The fix is almost always the same: replace the vague verb with the actual behavior and the actual edge case.

This matters more with AI coding tools than it ever did with human developers, not less. A human teammate will stop and ask you what you meant by "manage their stuff." An AI agent will not stop. It will confidently build something, and it will be a reasonable guess, and it will still be the wrong thing, because a wish gives it nothing solid to aim at. Every requirement you leave vague becomes a decision the AI makes for you, silently, and you find out what it decided after the fact.

Turn each requirement into a one-line user story

Professional product teams do not write requirements as loose bullet points either, and there is a reason for that beyond habit. They write them as user stories, one line each, in a fixed shape: As a [type of user], I want to [do something], so that [reason].

Example: As a shopper, I want to save items to a cart, so that I can pay for them all at once.

The format looks almost too simple to matter, but it forces three things you will otherwise skip when you are excited about an idea. It forces you to name who the feature is for, which is harder than it sounds once you have more than one type of user. It forces you to name the actual action, not a vague capability. And it forces you to name why it exists, which is the part that quietly kills the features nobody actually needs. If you cannot finish the "so that" clause with a real reason, that is usually a sign the feature is something you wanted to build, not something anyone needs.

Write every requirement you have in your head this way before you touch your AI tool. You will find some ideas collapse the moment you try to write the "so that" part, and that is the format doing its job.

Separate must-have from later, and be harsh about it

Once you have a list of user stories, go through every one of them and mark it must-have or later. This is the step most people either skip or fake, marking almost everything must-have because it all feels important while you are excited about the idea.

Be harsh here. A must-have is something the product is completely useless without, not something that would be nice to have, not something a competitor has, not something you might want eventually. Ask, honestly, could a real user get real value from this thing without that story. If the answer is yes, it is later, not must-have.

• Must-have: a user can sign up, log in, and do the one core action the product exists for.
• Later: social login, dark mode, notifications, export to PDF, admin analytics dashboards.
• Later, even if it hurts to admit it: the second and third core features you imagined, before you have proof the first one earns its keep.

The must-haves are all you build first. Everything else waits its turn until the first version is real, in front of real users, and you actually know whether it needs those extras. This is also what keeps a vibe-coded prompt session from sprawling into a dozen half-finished features, because you are only ever prompting toward a short, ruthless list instead of an entire product at once.

Get requirements from real users, not your own head

Requirements come from the people who will actually use the thing, not from your imagination, no matter how confident that imagination feels at 11pm with an idea you love. Talk to three to five real potential users before you build anything, and write down what they ask for in their own words, not your paraphrase of it.

This step feels like the one you can skip, because talking to strangers is slower and more uncomfortable than opening your AI tool and starting to prompt. It is also the step that decides whether the rest of the work matters at all.

Watch out: if you cannot find one person who wants this, that is the cheapest moment you will ever get to learn it, long before you have built anything. Check before you build. If you build anyway, at least know you skipped it, and know that is the risk you are carrying.

You do not need a formal research process. A short conversation with someone who has the exact problem you are trying to solve is enough to tell you whether your must-have list matches what they actually need, or whether it matches what you assumed they need. Those are not always the same list.

Common mistakes when gathering requirements for a vibe-coded project

These are the patterns I see most often, and they are the fastest way to end up with a wandering, unfinishable build.

• Prompting straight from the idea in your head. Skipping requirements entirely and typing the first prompt with nothing written down. The AI will happily fill in every gap you leave, and it will not fill them the way you would have.
• Writing wishes instead of requirements. "Make it feel premium" is not something you or an AI agent can test. Rewrite every wish until it is a specific, checkable behavior.
• Marking everything must-have. A list where nothing is deprioritized is not a priority list, it is just the original wish list wearing a label.
• Designing for an imagined user instead of a real one. Building for "someone like me" instead of the three to five actual people you could have talked to first.
• Never writing it down. Keeping the plan in your head means it drifts every time you open a new prompt session, and you lose the ability to check your own work against what you originally meant.

Every one of these mistakes shares the same root cause: treating requirements gathering as a formality to get through instead of the actual design work. It is the design work. The prompting that comes after is comparatively fast once you know exactly what you are building.

Do this now: turn your idea into a spec

Open a new file, call it something like requirements.md, and put it in a specs folder next to wherever your project will live. Then work through these steps in order.

• Write down every capability your idea needs, as a plain wish first, exactly as it sits in your head.
• Rewrite each wish as a testable requirement: the specific action, the specific person, the specific edge case.
• Convert each requirement into a one-line user story: as a [user], I want to [action], so that [reason].
• Mark every story must-have or later, and be harsh. Anything you are unsure about is later.
• Talk to three to five real potential users, and adjust the list based on what they actually say, not what you hoped they would say.

That file is the raw material for every step that comes after: the prompts you write, the pages you build first, and the features you deliberately leave out. Fifteen minutes here saves hours of prompting toward the wrong thing later.

Frequently Asked Questions

Do I really need to write requirements before vibe coding, or can I just start prompting?

You can start prompting, and many people do, but you are trading fifteen minutes of writing now for hours of confused back-and-forth later. Without a written list, an AI agent fills every gap in your idea with its own guess, and those guesses rarely match what you actually meant. A short requirements file is the cheapest insurance in the entire process.

What is the difference between a wish and a requirement?

A wish is vague enough that nobody can say for certain whether it is done, like "users can log in." A requirement is specific enough to test, like "a person signs in with an email and password, and resets a forgotten one through an email link." If you cannot point at your finished app and get a clear yes or no, it is still a wish.

How many user stories should a first version have?

As few as make the product genuinely useful, not as many as you can imagine. Most first versions need somewhere between five and fifteen must-have stories. If your must-have list is much longer than that, go back through it and be harsher about what actually belongs in later.

What if I cannot find real users to talk to before building?

Try harder before you skip it, because this is the cheapest moment you will ever get to learn whether the idea has a real audience. If you truly cannot reach anyone, build the smallest possible version and treat your first real users, whenever they show up, as the requirements interview you skipped. Just be honest with yourself that you are carrying that risk.

Does this process only apply to apps and startups, or also to smaller tools?

It applies to anything you are about to vibe code, including a small internal tool or a weekend script. The size of the write-up scales with the size of the project, but even a five-line requirements list for a small tool will save you from building the wrong thing first.

Start with the list, not the prompt

Every vibe-coded project that wanders, stalls, or gets rebuilt three times shares the same starting point: no written requirements, just a good idea and an open prompt window. The fix costs you fifteen minutes and a short conversation with real people, and it pays for itself the first time your AI agent builds exactly what you meant instead of a reasonable guess at it.

This article covers the short version. The full chapter in The Vibecoder's Handbook walks through gathering requirements for your own idea, step by step, with the exact templates I use.

Read the free chapter ->