Reading time: 10 min

A couple of days ago, I asked AI (Claude) again a simple question about requirements. What came back was not an answer, but a page of prose. It was careful, well-structured, confidently written prose, but still not what I needed. I read it twice, looking for the actual answer, and realized I now had more to process than before I asked.

If that sounds familiar, you are not the only one struggling with it. We have all read the posts about better prompts, clearer context, the right skills. Underneath most of that advice sits one real hope: that AI will simply write the requirements for us. I wanted to test that hope honestly, and this is what I found.

The overflow problem

Ask AI one simple question, and you rarely get a short, concise answer. You get hundreds of words to read instead. That is not always a bad thing on its own. But when you are trying to work efficiently, a wall of text is not a shortcut. It is homework. Instead of less to process, you end up with more.

And another observation: the longer you work with AI on a specific topic, the more you start to notice its patterns. How it phrases things, what it defaults to, where it exaggerates. Once you see the pattern, it is hard to unsee, and harder still to break. You start writing prompts around the tool’s habits instead of around your actual problem.

Note: Picture is AI generated.

Teaching AI is still your job

So back to the real question: can AI write your requirements for you. Try a prompt like “write me ten requirements for TV interconnectivity,” and you will get ten requirements. What you will not get is anything usable. Garbage in, Garbage out.

The only way around this is to teach AI what makes a requirement good in the first place. That means writing down your own rules, collating them, and giving AI something solid to work from. An experienced requirements engineer or business analyst already carries these rules from experience. A junior does not, and for them it takes real time to put those rules into words, simply because they have not internalized them yet. Compiling a first version can easily take a day. I will come back to that junior versus senior gap properly in a future post, because it deserves its own space.

That day of work is not wasted, though, and the payoff is not really about the AI. It is about you. Writing down what makes a requirement good forces you to make explicit something you have mostly been carrying as tacit knowledge. You find out what you actually know once you have to spell it out. That clarity is worth having whether or not AI ever reads a word of it.

The analysis is still yours

Here is the part that matters most. To instruct AI on what to write, you need to know what you want it to write. That means your mental model has to be ready before you type the prompt. You must have done your analysis first. AI will not do that thinking for you, and even when it produces something that looks complete, you still have to check it against your own reference model. Evaluating good output requires the same analysis as producing it yourself. There is no way to skip that step, only ways to hide from it.

Some tools promise to remove this step or make it easier for you. ChatPRD is one of them, marketed as a way to have AI handle your product requirements from start to finish. So far I have not been impressed with what it produces once you look at the result in the context of real requirements work. It writes fluently. It does not think for you.

What actually works

Use AI to transcribe your notes if that saves you time. But do your thinking yourself. Define your needs, then check them with AI to make sure they hold up against the characteristics of a well developed requirement. Use the tool to test your work, not to replace it. Stay in charge of the outcome.

This matters even more once you move from needs to design input requirements. At that stage, requirements get negotiated. Stakeholders push back, ask questions, and eventually agree to what they are signing up for. AI can propose things in that conversation, but it is not a party to the contract. Stakeholders are. They are the ones who must agree, approve, and genuinely understand what they are committing to, not the tool that helped draft the wording.

I am not against AI. I use it, and I will keep using it. But I think we need to use its strengths and stop handing it jobs it was never built to finish. It is a tool in the end, not a colleague who has done the analysis for you. AI can help you write requirements, but it can’t do the thinking that makes them good.

Next time, I want to show you how it actually looks like in practice: a concrete example of instructions that turn a lazy prompt into a usable requirement.