How to ask AI to build your app: A brief with acceptance checks

“Build me a CRM” gives an agent a category. A useful brief gives it decisions it can implement and checks it can run.

You do not need a long requirements document to start. You need enough detail to separate a correct result from an attractive approximation. An equipment-request workflow makes a good example because the records, people, and state changes are easy to name.

Write the workflow in ordinary language

State who submits a request, what information they provide, who reviews it, and what happens after approval. Name the records that must persist. If an action needs human authorization, say where that authorization happens.

Then supply one synthetic example. An employee requests a monitor, gives a reason, and selects a delivery location. Their manager approves the request. The employee can see the decision. A different employee cannot read the request.

Avoid asking the agent to infer policy from a screenshot. The screen can show an Approve button without explaining who may use it.

A build brief you can adapt

Build an internal equipment-request application. Employees submit an item, reason, and delivery location. Each request begins as pending. A manager assigned to the employee's team may approve or decline it, with a decision note. Employees see only their own requests; managers see requests for their assigned teams. An employee must not approve their own request. Use synthetic sample data. Do not send emails or purchase equipment. Before making changes, identify the target application and explain the proposed records and access rules. After implementation, show the saved request, the decision history, and the results of the access checks.

This brief makes the first release reviewable. It also identifies actions outside the scope. The agent should not connect a purchasing service merely because purchasing would be a plausible next step.

Make the expected outcomes explicit

Add a short set of examples under the brief. These are proposed business rules for the equipment app; change them to match your process.

Also name open questions. For example: “We have not decided what happens when a requester changes teams. Pause implementation of that rule and propose the choices.” An unresolved rule is easier to review when it is visible than when the agent invents a reasonable answer.

Attach interface references only for the aspects they demonstrate. A screenshot can show the order of fields or an example status label. Put permissions and state transitions in text where both the agent and the reviewer can inspect them.

Add failure cases before adding features

Ask for the behavior when a required field is missing, a manager approves an already-decided request, or someone calls the underlying endpoint without using the interface. Specify what the user sees and whether anything should be saved.

For an approval transition, a useful requirement is that a repeated request does not create a second decision. The implementation needs an explicit mechanism to satisfy that requirement; repeating the sentence in the prompt is not an enforcement mechanism.

Keep the first dataset small enough to inspect. Once the basic workflow is correct, add realistic volume, integration errors, and operational requirements.

Close the loop with evidence

Ask the agent to report what it changed, what it exercised, and what remains unverified. Require evidence from the actual application destination. A local mock or a screenshot of sample data may be useful during design, but it should be labeled accordingly.

On OBTO, the application graph and artifact reads let the agent inspect the target before editing. The getting-started guide provides the connection steps. Save the brief with the project so later changes can be checked against the same rules.