Vibe coding
Write acceptance criteria an AI app builder can be judged against
Describe observable outcomes for one business rule, including the case that should be refused.
Zocri · 2 min read · Sources checked
Start with the rule people care about
Cucumber's Gherkin reference structures examples around an initial context, an action and an expected observable outcome. You can borrow that structure without adopting a testing framework. For a workshop with limited places, the business rule might be that a confirmed reservation consumes one place and a pending inquiry does not. Write that decision before listing screens.
Describe the starting situation precisely: one place remains, the customer is signed in and the workshop accepts reservations. Then name the action and the visible outcome. The customer should see a confirmation, and the owner should see that customer's reservation against the correct workshop.
Add the refusal case
Now change one important condition. When the workshop is full, a new customer should receive a clear unavailable message and no confirmed reservation should appear. Avoid vague criteria such as 'handle errors gracefully'; write the words or state that would demonstrate the intended handling.
Add a repeated-action case. If the same person presses the reservation button twice, decide whether the app returns the existing reservation or offers another place. Either may fit a business, but the behavior must be chosen explicitly. The test should not make that policy decision for you.
Separate user evidence from internal checks
Ask for customer-visible evidence first: the displayed status, the owner's list and the result after refreshing. Technical checks can support this evidence, but a function returning success is not the same as the full journey producing the promised result for the intended person.
Mark setup assumptions beside each example. A payment-dependent reservation may require a test payment service, while a message-dependent result needs a safe recipient. If a dependency is unavailable, record that part as untested. Do not silently replace it with a success message and call the criterion passed.
Keep the examples with the change
Use a short list of named examples rather than a wall of instructions. Include the ordinary path, the main refusal and one recovery path. Ask the builder to report each as passed, failed or untested, with the observed result and the environment used.
When the business rule changes, update the examples before judging the new implementation. Keep the previous behavior clear for old records if they require different treatment. Acceptance criteria become useful when they settle what a change means and provide a repeatable way to inspect its outcome.