AI Code Review Tools That Check PRs Against Acceptance Criteria

Several AI review tools can read the ticket linked to a pull request and check the diff against its acceptance criteria. Kodus, cubic and Qodo post the result on the pull request. Korekt's Jira app shows the per-criterion result on the Jira issue; its Jira docs don't say whether the result also appears on the pull request. They differ in how they find the ticket, which fields they read, and what they do when the criteria are vague or missing. That last case is where Warpway's Product Semantics lens works differently: it asks the product owner a specific question.

What an acceptance-criteria check has to do

Each tool in this guide does the same four things. They differ in how they do each one:

1. Find the ticket. The tool links the pull request to an issue, usually by spotting a key like PROJ-123 in the branch name, title or description. If it misses the link, nothing else runs.
2. Read the criteria. Some tools read the whole description and some read only a specific field. The tool can't see criteria stored anywhere else.
3. Compare and report. The tool decides whether the diff implements each criterion and posts the result as a PR comment, a review table or a panel on the ticket.
4. Handle the gaps. If the criteria are vague, visual or absent, the tool needs a fallback: skip the check, mark items for manual review, or ask someone.

If you want the check to hold up a merge, also ask whether it reports a status check or only leaves a comment.

Side-by-side

This table summarizes each vendor's documentation as of November 2026. "Not described" means the cited page doesn't say. It does not mean the feature is missing.

Kodus

Kodus calls this business logic validation. Its agent, Kody, looks for a task reference in the PR title, then the branch name, then the description. It accepts keys such as PROJ-123, #123, owner/repo#123 and AB#123, plus links to tracker items. A reference counts only if the connected tracker returns a task with that exact id. Kody also reads the parent task, sub-tasks and attached documents. It checks up to three tasks per PR and skips a PR that references more.

The wording in your PR description sets the scope. "Closes" checks the whole task, and "Part of" checks only a slice of it. You can also run the check by hand with @kody -v business-logic, followed by a task key or by pasted requirement text. Pasted text works without any tracker connected.

The result is one PR comment, edited in place each time the check reruns, with one row per requirement. The five states are MET, PARTIAL, MISSING, CHECK MANUALLY (for visual or flow requirements and uncertain cases) and NOT IN TASK (for changes the task didn't ask for). Each row cites a file and line. Someone with write access can reply to mark a row ACCEPTED, but the PR author can't accept rows on their own PR. The docs say Kody "doesn't write a check or a status, so it never blocks a merge by itself."

cubic

cubic's issue analysis supports Linear, Jira, Asana and GitHub Issues. For the first three, it looks for an issue ID like ABC-123 in the PR title or branch name. For GitHub Issues, it uses the issue the PR closes, for example with Fixes #123. It pulls requirements from the issue description, compares them against the changed files only, and adds a table to its review that shows which requirements are done and which are missing.

The docs say what makes requirements usable: bullet or numbered lists, or a section labeled "Acceptance Criteria" or "Requirements", with action items that start with "Should", "Must" or "Can". If the issue has no description or no requirements, the analysis doesn't run. The docs give "Make the form work better" as an example of a requirement that won't work.

Qodo

Qodo links a ticket in two ways: the PR description contains a direct link to it, or the branch name matches a fixed pattern. Branch detection is always on and can't be configured. The ticket ID must appear at the start of the branch name or right after a /. For Jira, both feature/PROJ-123-add-new-feature and fix-PROJ-123-bug match. For Linear, feature/PLT-2837 matches but fix-PLT-2837 doesn't.

Which fields Qodo reads depends on the tracker. For Jira, it reads acceptance criteria only when they are stored in a custom field. Qodo's docs list acceptance criteria as not read for Linear, so it works from the title, description, sub-issues, labels and attachments (up to three images, plus embedded files). Azure DevOps has a dedicated acceptance-criteria field, and Qodo reads it.

Qodo reports the result as review findings rather than a compliance status. A finding can be a missing or incomplete requirement, a change that doesn't clearly serve the stated goal, or a note that something needs manual validation, such as UI testing. Requirement-aware feedback is on by default. Flagging changes that look unrelated to the stated intent is off by default; turn it on with check_pr_additional_content = true in [pr_reviewer].

Korekt

Korekt's Jira app shows the per-criterion result on the Jira issue. Its Jira docs don't say whether the result also appears on the pull request. The app links reviews through an issue key in the branch name or commit messages, such as feature/PROJ-123-add-login or Fixes PROJ-123. According to the Marketplace listing, its panel on the issue shows a compliance score, severity badges and each criterion marked MET, PARTIAL or NOT MET, with evidence that links to files and lines.

The Jira app doesn't review code itself. Reviews come from a connected source: Bitbucket through Korekt's Bitbucket app, GitHub and Azure DevOps through the Korekt dashboard, or the Korekt CLI. The Jira docs don't say which Jira field the criteria come from, and they don't describe merge blocking. As of November 2026, the listing calls the Jira app free and points to paid plans starting at $24 per developer per month.

Where Warpway fits: asking when intent isn't written down

The four tools above work best when someone has written clear criteria into a ticket the tool can read. Warpway's Product Semantics lens checks "whether behavior matches the ticket or specification, and whether a business decision is missing." When the intended behavior isn't written anywhere Warpway can read, the lens asks the product owner instead of guessing.

What it reads. Each review works from a snapshot of the PR: title, description, comments, reviews, commit messages and the GitHub issues the PR links to. Lenses have a get_linked_issues tool that returns those issues with their requirements. Warpway's docs do not list Jira or Linear as sources. If your criteria live only in Jira or Linear, copy them into the PR description or a linked GitHub issue. Warpway is a GitHub App, so it reviews GitHub repositories only.

When it runs. By default, Product Semantics is required when a change touches business logic, billing, payments, UI, feature flags, API contracts or personal data. The docs don't describe a per-criterion table like the ones Kodus and cubic post. Instead, the lens ends in one of four lens states: Cleared, Issue found, Human decision required or Incomplete.

What a question looks like. When the lens can't settle something, it creates a human task. The task must state the question, why it matters, what Warpway looked for and didn't find, the evidence and code involved, and what each answer will mean. This example from the docs is shortened:

Question: Must revoking an administrator role invalidate active sessions immediately?

Unknown: No code, tests, issue or security document specifies the intended revocation timing.

Choose: Immediate revocation / Up to 15 minutes is acceptable / Needs discussion.

Who gets asked. Routing chooses from several sources of candidates, including configured owners, CODEOWNERS, people who reviewed or changed the code, the assignee or author of a linked issue, and people who answered similar questions. For questions that aren't about engineering, CODEOWNERS and code history rank below configured contacts, the linked issue and topic expertise, because owning the code says little about product intent. On the Team plan with Slack connected, a non-engineer with a linked Slack identity gets the question in plain language as a Slack direct message, with answer buttons when the question has fixed choices. They don't need a Warpway account.

What counts as an answer. A reply like "Sounds fine" doesn't resolve the task; Warpway asks one follow-up question. A clear answer is recorded as evidence along with who gave it, and the affected lens is re-evaluated. An Admin can save the answer as an organization rule, so later reviews cite it instead of asking again. If someone edits the PR's title or description, Warpway withdraws its earlier verdict and reviews the new intent.

Whether it blocks. On the Team plan at trust level 2 (Gate), you can make Warpway / Review a required check. A required lens that is waiting on a human decision then keeps the check from passing. See merge gating.

On the Team plan, you can point the lens at your criteria and choose who answers:

version: 1
rules:
  - id: checkout-acceptance-criteria
    lens: product_semantics
    applies_to:
      paths:
        - src/checkout/**
    instructions: >
      Treat the "Acceptance criteria" section of the PR description and of
      any linked GitHub issue as the specification. Report each criterion
      the change does not meet, quoting it.
    owner: "slack:U0123ABCD"   # the checkout product owner
    severity: high
routing:
  product_semantics:
    slack_user_group: "@product-leads"
    prefer_slack: true

When a rule matches, its lens runs even if it otherwise wouldn't apply, and the rule's owner is asked before anyone else.

Writing criteria any of these tools can check

The vendors' docs agree on most of what makes criteria checkable:

• Put the ticket key in both the branch name and the PR title, for example feature/PROJ-123-short-name and PROJ-123: Short name. Kodus and cubic read either one, Qodo matches an ID that follows a /, and Korekt reads the branch. If you use Qodo with Linear, avoid branch names like fix-PLT-2837.
• Use a labeled list. A section headed "Acceptance criteria" with one "Must" or "Should" bullet per criterion is the format cubic asks for, and it gives every tool separate items to mark.
• Check where Jira stores your criteria. Qodo reads Jira acceptance criteria only from a custom field.
• Write values, not adjectives. "Session cache expires after 5 minutes" can be checked against code. "Make the form work better" can't.
• Keep tests in the loop. The vendor docs cited here describe comparing the diff with written requirements, not running tests. Mapping each criterion to a named test gives a reviewer something concrete to check for each criterion. The linked article also warns that a passing build means little unless those tests assert what the criterion requires.

How to choose

• Your team works in Jira and keeps criteria there: Korekt shows the per-criterion result on the issue itself.
• You want a per-requirement checklist on the PR: Kodus and cubic both post one. Kodus adds CHECK MANUALLY and NOT IN TASK states and lets reviewers accept individual rows.
• Your criteria are in Azure Boards or a Jira custom field: Qodo reads both fields and reports gaps as review findings.
• Your criteria are often missing and the person who knows isn't an engineer: Warpway's Product Semantics lens asks that person a specific question, records the answer, and can hold the merge until the answer arrives. This assumes your code is on GitHub and any written intent is in the PR or a linked GitHub issue.

You can use more than one. A checker that compares written criteria and a lens that asks about unwritten intent catch different problems.