Qodo's AI code review now checks pull requests against linked specs

Reviewing code against the spec, not just the diff

Qodo describes a familiar problem: a pull request can look correct and still miss a critical requirement. The code compiles, the tests pass and the implementation matches the ticket's acceptance criteria. But the ticket may link to a specification, for example in Confluence, that holds a requirement the implementation never addressed.

To catch that gap, a human reviewer has to follow the link, read the specification and connect the requirement to the code. According to Qodo, its tool can now do this. When a pull request links to a ticket, Qodo reads the linked specification in that ticket and reviews the code against it.

The company summarizes the difference this way: "Diff review catches broken code. Spec review catches code that runs fine and still does the wrong thing."

An example: the missing authorization check

Qodo walks through a typical workflow. A developer opens a pull request that adds a bulk operation for updating customer records and links the Jira ticket in the description. The ticket links to a Confluence page containing the API spec. That spec says every request must verify that the authenticated user belongs to the account that owns the records before updating them.

Qodo follows the link from the ticket to the spec and compares the code changes with its requirements. It then flags the missing account-level authorization check as a security issue. Without the check, a user could modify another customer's data. In this example the requirement was in the spec, but not in the ticket or the code.

Supported spec sources include Asana, Confluence, Notion, ServiceNow and JSM Assets.

Why specs matter more with coding agents

Qodo ties the feature to the return of spec-driven development, which it says AI coding agents brought back. In this approach, teams write the spec first, and tools such as Kiro turn it into a plan, tasks and code. The spec becomes the contract between what the team intended and what the agent builds.

That contract only holds if someone checks the code against it, the company argues. Agents can drift: they may skip an edge case, simplify a constraint, or build from the ticket summary instead of the full requirement. For teams that build from specs in Kiro, Qodo points to its Qodo Kiro Power, which brings Qodo review into that workflow.

What it means for teams

Qodo notes that teams rarely keep every requirement in one place. A ticket describes the work, a linked document explains the architecture, and another page defines constraints across the system. A developer may link the right ticket without copying every supporting document into the pull request description, leaving the reviewer to reconstruct the context manually.

By following the links, Qodo says it can surface an omitted constraint, a missing behavior, or a decision that conflicts with the documented design. Reviewers still assess each finding and decide what to do. The company adds that teams do not have to duplicate requirements: detailed specs stay in the documentation tool, and tickets simply reference them.

The aim, according to Qodo, is to catch requirement gaps in the pull request, where teams can act on them.