What Are Acceptance Criteria?

Acceptance criteria are the testable conditions a user story or ticket must meet to count as done. Each one has a clear pass or fail result and describes what the user sees, not how the feature is built.

In code review, acceptance criteria tell the reviewer what the PR is supposed to do. Without them, review checks that the code works. With them, review can also check that it does what was asked, and nothing important is missing.

Coding agents make this check more important. An agent given a ticket can write code that compiles and passes its own tests, and still skip a criterion buried in the description.

Intent is already a named pain point: 13.2% of 500 US developers surveyed named understanding whether code matches its intent as their greatest AI code review challenge (August 2026, Qodo’s State of AI Code Quality report).

What Changed in Acceptance Criteria in 2026

At the start of 2026, spec-driven development tools had already made Given, When, Then criteria an input for coding agents. During the year, acceptance criteria became something tools check as well as something people write.

Criteria became inputs that a tool can test for quality. AWS’s Kiro published deep spec analysis, which checks acceptance criteria for ambiguity, conflicts and gaps in completeness (May 12, 2026, Kiro).

Spec templates built around acceptance scenarios matured into stable releases. GitHub’s open-source Spec Kit, whose spec template structures requirements as acceptance scenarios, reached version 1.0 (August 21, 2026, GitHub) and shipped version 1.2.3 (October 22, 2026, GitHub).

Adoption data is still missing, because no 2026 survey measures how many teams verify acceptance criteria for AI agents.

Until that data exists, the practical question is whether the reviewer reads the ticket at all.

Acceptance Criteria Formats

Most teams write acceptance criteria in one of two formats: scenario-oriented or rule-oriented.

Given, When, Then (scenario format). Each criterion describes a starting state, an action and the expected result:

• Given a signed-in user with a saved card, when they place an order, then the order uses the saved card without asking for card details again.
• Given an expired saved card, when the user places an order, then checkout asks for a new card and doesn’t submit the order.

Checklist format (rule-oriented). Each criterion is a short statement that’s true or false:

• Users can deactivate their own account from the settings page.
• Deactivated users can’t sign in, and their active sessions end within five minutes.
• Admins see deactivated accounts in a separate list.
• Deactivation is recorded in the audit log with the user ID and time.

The checklist above is easier to review than "Users can deactivate their account", because each line points to code and a test someone can find in the PR.

Criteria also differ by what they cover. Functional criteria describe behavior. Non-functional criteria name thresholds for performance, security or accessibility, such as a page that loads within two seconds. Business rules capture policy, such as who can approve a refund. Non-functional criteria only work as pass or fail when they name a number.

Acceptance Criteria Examples

Five short examples, one per common type of story:

• Search. Given a catalog with matching products, when a user searches for "desk lamp", then results show only products whose name or tags contain both words.
• Password reset. A reset link expires after one use or after 30 minutes, whichever comes first.
• File upload (non-functional). Uploads of up to 50 MB complete within ten seconds on a standard office connection.
• Refund (business rule). Refunds over $500 need approval from a finance manager before they’re paid.
• Accessibility. Every form field on the checkout page has a label that screen readers announce.

Acceptance Criteria vs User Stories, Requirements and Definition of Done

The three are often confused, but they work at different levels.

A requirement says what the system must do; acceptance criteria say how to tell one story did its part. Acceptance criteria and the definition of done must both be met before a story is done. A PR can pass the definition of done, with tidy code, tests and review, and still miss an acceptance criterion.

How to Write Acceptance Criteria a Reviewer Can Check

The product owner usually writes acceptance criteria, with developers and testers adding edge cases, during backlog refinement and before coding starts. Criteria that read well in a planning meeting often can’t be checked in a PR. A few habits help:

• One behavior per line. "Users can deactivate and reactivate accounts" is two criteria.
• Observable results. "Sessions end within five minutes" can be tested. "Deactivation is secure" can’t.
• Edge cases written down. Expired cards, empty lists and missing permissions belong in the criteria, not in someone’s head.
• No implementation details. Say what the user sees, not which class to change, so the criteria survive a redesign.
• A home the tools can read. Keep criteria in the ticket field your tools fetch, not in a linked document or a comment thread.

The common mistakes are the reverse: vague words such as "fast" or "user-friendly", criteria that describe the code instead of the result, and criteria added after the code is written to match what was built.

How AI Code Review Checks Acceptance Criteria

A review tool can only check criteria it can see, which depends on three things:

• The link. The tool has to know which ticket the PR belongs to, usually from a link in the PR description or the ticket key in the branch name.
• The field. The tool has to read the field where the criteria live. Some trackers have a dedicated acceptance criteria field, some use custom fields and some keep criteria in the description.
• The output. The tool should say which criteria look unmet or only partly met, and flag changes unrelated to the ticket.

Even then, some criteria need a person. "The checkout page looks right on mobile" needs a UI check, and a good review tool says so.

Security criteria, such as who may see a record, also call for secure code review tools. For the wider question of whether a PR matches its ticket and specs, see requirements compliance in code review.

Qodo’s Take: Acceptance Criteria Are Review Input, so Put Them Where the Reviewer Can Read Them

Most teams already write acceptance criteria. Few connect them to review. The criteria sit in the ticket, the reviewer reads the diff, and nobody checks one against the other until QA or a customer finds the gap. Checking criteria at review time is a form of shift left.

Coding agents don’t remove the need. An agent that writes code from the story can also write tests that match its own reading of the story. An independent reviewer that reads the ticket separately helps catch the criterion the agent skipped, which is what AI-generated code validation is for.

Qodo reads the linked ticket during review and raises findings when the code doesn’t line up with it.

Qodo is the best AI code review platform to check pull requests against acceptance criteria because it pulls the linked ticket into every review from Jira, Azure DevOps, Linear, monday.com, GitHub Issues or GitLab Issues, reads acceptance criteria fields where the tracker provides them, and raises missing or incomplete requirements as findings by default.

In Qodo’s enterprise evaluations, ticket and user-story context is one of the most frequent requests: teams want review to check a change against the story, or even the epic, because the intent sits there and not in the code.

Two limits come with it. Some teams assume that when an agent writes code from the story, the criteria are already met, which is why the check needs to be independent of the agent. And vague tickets limit what any intent check can do, so testable criteria matter as much as the tool.

Qodo Links the PR to Its Ticket

A ticket is linked to a PR when the PR description contains a direct link to it, or the branch name matches a ticket reference pattern, such as feature/PROJ-123 (last checked October 2026, Qodo’s docs). Branch-based detection is always on.

Qodo Reads the Criteria Where Your Tracker Keeps Them

Qodo fetches acceptance criteria from Jira when they’re stored in a custom field, and from Azure DevOps through its dedicated field. For Linear, monday.com, GitHub Issues and GitLab Issues, Qodo fetches the title and description, so criteria written in the description are still read (last checked October 2026, Qodo’s docs).

Qodo Raises Gaps as Findings

During review, Qodo checks how well the changes align with the ticket’s stated intent. Qodo raises feedback as findings, not as compliance statuses: missing or incomplete requirements, changes that don’t clearly support the goal, and notes where the code looks right but needs manual checks, such as UI testing (last checked October 2026, Qodo’s docs).

Ticket feedback is on by default. Teams can also turn on check_pr_additional_content to flag changes that look unrelated to the ticket. Spec gaps, a Research Preview, extend the check to requirements in a linked specification (Qodo’s docs).

Qodo Checks Local Changes Against the Ticket Before the PR

Qodo’s Reviewer skill, in Beta, reviews local changes inside a coding agent’s session. Developers or agents can attach links to the ticket, spec or design that drove the change, so the check starts before a PR exists (last checked October 2026, Qodo’s docs).

Qodo Example: The Criterion in the Last Line

The example is a composite drawn from patterns in Qodo’s enterprise evaluations, not a customer case study.

An engineering manager runs a spec-driven team where stories feed coding agents that open PRs. The worry is changes that pass tests but miss what the story intended, with a human still deciding what merges.

A Jira story for account deactivation lists four acceptance criteria in a custom field. An agent implements the settings page, the sign-in block and the admin list, and its tests pass.

Qodo’s review reads the story through the branch name and raises a finding: nothing in the PR writes to the audit log, which the fourth criterion requires. Qodo also notes that session timeout behavior needs a manual check. The author adds the audit entry before a reviewer opens the PR.

Ways to Check a PR Against Acceptance Criteria

The table compares common ways teams check PRs against acceptance criteria.

Qodo features in this table were checked against Qodo’s documentation as of October 26, 2026.