What is a simple acceptance criteria example?

When a person submits a valid booking request, the app saves it once and shows a confirmation. If a required field is blank, the app does not save the request and shows which field needs attention.

Are acceptance criteria the same as tests?

No. Acceptance criteria describe the result the feature must produce. A test checks one part of that result. You may need automated tests and a manual check to cover the full feature.

Should I write acceptance criteria before asking AI to code?

Yes. Write them after you understand the user path and before the build starts. This gives the agent a clear result to work toward and gives you a consistent way to review the feature.

Acceptance Criteria Examples for AI Coding

What acceptance criteria mean when you build with AI

Acceptance criteria are the results a feature must produce before it is done. They explain what a person needs to be able to do, what should happen after each action and what should happen when something goes wrong.

I started taking them more seriously after features that looked done would break when I updated them or added something new.

For example, I might build a CSV upload feature. The upload works and the app processes the data correctly. Later, I add a new way to process that data. The new processing works, but the change breaks the CSV upload that was already working.

Acceptance criteria give me a list of results that must keep working after every change.

A person can upload a valid CSV file.
The app explains the problem when the file is not valid.
The uploaded data is saved and processed correctly.
A new data-processing feature does not break the original upload.
The automated tests for the upload still pass after later changes.

Example: an AI has been asked to build a booking form

Imagine you ask an AI coding agent to add a booking form to your app. You tell it to collect a name, email address, date and short message.

The agent can build a form that looks right. That does not mean the whole feature works. A real person will do things your first prompt did not explain.

What happens when the person submits a blank form?
What happens when the email address is not valid?
Can the person choose a date that has already passed?
What happens after the request is saved?
Where does the person go next?
What does the person see if the save fails?
Can the same request be sent twice by accident?

Step 1: map the path the person takes

I like to start with the path through the feature. For the booking form, the person opens the page, fills in the form, submits it and sees a result.

Write that path in plain English. Do not start with database tables or code. You are working out what the person needs the app to do.

The person opens the booking page.
The person can see which fields are required.
The person enters their details and chooses a date.
The person submits the request.
The app saves the request once.
The person sees a confirmation and knows what happens next.

Step 2: turn the missing decisions into checks

Go back through the path and look for places where the AI would have to guess. Turn each one into a sentence you can check in the finished app.

A useful check names the situation, the action and the result. You do not need special product language to write one.

If a required field is blank, the form shows which field needs attention and does not save the request.
If the email address is not valid, the form asks for a valid address and keeps the other answers.
If the person chooses a past date, the form asks them to choose a future date.
When a valid request is submitted, it is saved once and a confirmation appears.
If the save fails, the person sees an error and can try again without filling in the whole form again.

Step 3: turn the checks into tests

Acceptance criteria tell you what to prove. Tests are one way to prove it. Ask the coding agent to add automated tests for rules the code can check, such as rejecting a blank email or preventing a past date.

You should also use the feature yourself. An automated test may prove that the request was saved, but it will not always prove that the error message is easy to understand or that the next step feels clear.

Run an automated test for each business rule that can be checked in code.
Open the feature and complete the normal path yourself.
Try the important blank, invalid and failed states.
Check that the result on screen matches the acceptance criteria.
Keep the feature open if any required check still fails.

Step 4: give the AI one feature and one finish line

Keep the first version small. A booking request form is one feature. Calendar syncing, payments, reminders and rescheduling are separate features with their own criteria.

Give the agent the user path, the acceptance criteria and the tests for this feature. When the work comes back, compare the result with the same list. If one required check fails, the feature is not done yet.

How I keep the criteria beside the build

I map the user path in CodeSpring, add the rules to the feature notes and turn the feature into a PRD. The criteria then stay attached to the task instead of disappearing inside an old chat.

The task can move across the Kanban board as it is built and checked. This gives the AI a clear finish line and gives me a list I can use when I review the result.

If you are planning a whole app, the related guide below shows the full sequence from map to tested build.