How to Use AI Requirements (and Caveats)

AI requirements are a “first-pass” — something you firm up with the developer before ordering. What AI produces is a draft before ordering, not a complete spec ready to commission as-is. It helps as a starting point for putting an idea into words, but feasibility (whether it can be built technically) and cost are confirmed with the developer, not AI.

I’m Naohiro Hayashi, creator of Soreda!. I built a system requirements AI myself and have run it, practicing the flow of “idea → AI first-pass → firm up with the developer → order.” From that experience, I’ll lay out the right way to use AI requirements and the caveats.

AI requirements are a “first-pass,” firmed up with the developer before ordering

Requirements made with AI are a “first-pass.” Rather than a finished piece ready to commission as-is, they become orderable only once firmed up with the developer.

It isn’t a complete spec ready to order

What AI produces is a draft that organizes what you want. The final spec is firmed up by the developer from a technical standpoint. Hold the premise that “AI organized it” doesn’t equal “an orderable spec is done.”

A foundation (draft) for “putting an idea into words”

The value of AI requirements is being able to put the idea in your head into words and organize it before ordering. Rather than writing a requirements document from a blank page, you answer questions and give it shape. Position it as “a foundation that helps you articulate.”

The right way to use AI requirements

The right way to use AI requirements is to articulate the idea and to use it for aligning understanding with the developer. Let’s go in order.

Put the idea in your head into words before ordering

Put the image in your head of “I want a system like this” into words and organize it before ordering. Just having this makes what you want to build clear even to yourself, and your preparation for the conversation is in order.

Use it as a “draft” to bring to the developer

The organized requirements work as a “draft” to bring to the developer. With a concrete proposal, it’s easier to align on “let’s go this way,” and the conversation moves faster than explaining from zero.

Organize and use system requirements with AI on Soreda! →

Caveats when using them

When using AI requirements, holding a few premises keeps you safe. Separate the role of AI from the role of the developer.

Feasibility and cost are confirmed with the developer

This is the most important caveat. Whether it can be built technically (feasibility) and how much it costs (cost) are confirmed with the developer, not AI. What AI organizes is “the WHAT,” and it does not judge “whether it’s buildable or how much.” Don’t take AI-organized requirements as “technically verified” — getting this wrong leads to a big mismatch later.

A human checks the requirements (do they match what you want)

Whether the requirements AI organized truly match what you want to do is checked by a human. AI organizes plausibly, but it can drift from your intent, and it can state facts incorrectly. Confirming with your own eyes that “this is right” is essential.

The right flow: “idea → AI first-pass → firm up with the developer → order”

The right flow for putting AI requirements to use is “idea → AI first-pass → firm up with the developer → order.” Run it in this order to make AI a realistic ally.

Make a requirements draft with AI

First, make a requirements draft with AI. How to make it is covered in How to Define System Requirements with AI. Articulate what you want, and prepare the material to firm up with the developer.

Next is screen/UI design

Once the requirements are organized, the next stage is screen/UI design. How to do screen/UI design with AI is covered in How to Design System UI with AI. Organizing the requirements (what to build) before moving to screens (how to show it) makes the consideration smoother.

FAQ

Q. Can AI requirements be used to order as-is? A. No. What AI produces is a first-pass draft before ordering. Ordering means firming up the details with the developer.

Q. Do I need a developer or engineer? A. Yes. Detailed speccing and feasibility judgment are done by the developer/engineer. AI helps with the requirements organizing before that.

Q. Can I tell whether the requirements are technically buildable? A. AI doesn’t judge technical feasibility. Confirm feasibility and cost with the developer. AI-organized doesn’t mean feasible.

Q. How much does it cost? A. System requirements is ticket-based, counted per run. See the official site for current details.

AI requirements are a “first-pass” — something you firm up with the developer before ordering. They help with articulating an idea and aligning understanding, but feasibility and cost are confirmed with the developer. With the flow “idea → AI first-pass → firm up with the developer → order,” use it without mistaking AI’s role. That’s the right way to make AI an ally for ordering a system.

Organize and use system requirements with AI on Soreda! →