How Qodo Uses Linked Specs to Catch Missing Requirements

A pull request can look correct and still miss a critical requirement.

The code compiles. The tests pass. The implementation matches the ticket’s acceptance criteria. But the ticket links to a specification in Confluence, and that specification contains a security requirement the implementation never addressed.

For a reviewer to catch the gap, they need to follow the link, read the specification, and connect the requirement to the code.

Qodo can now follow that path. When a pull request links to a ticket, Qodo reads the linked specification in that ticket and reviews the code against it. That brings more of the context behind a change into the review itself.

The spec is the source of truth again

AI coding agents brought spec-driven development back. Teams write the spec first, and tools like 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. Agents drift. They skip an edge case, simplify a constraint, or build from the ticket summary instead of the full requirement. In a spec-driven workflow, review has to read the spec too.

If your team builds from specs in Kiro, the Qodo Kiro Power brings Qodo review into that same workflow.

Requirements live across tools

Teams rarely keep every requirement in one place. A ticket describes the work. A linked document explains the architecture. Another page defines the constraints that apply across the system.

Tools such as Jira, Confluence, Notion, and Asana help teams organize that information. But the context can become fragmented when it is time to review an implementation.

A developer might link the right ticket in a pull request without copying every supporting document into the description. A reviewer then has to reconstruct the context manually and know which links are worth following.

Qodo’s new capability helps close that gap.

How it works

Consider a common workflow:

1. A developer opens a pull request that adds a bulk operation for updating customer records, and links the Jira ticket in the description.
2. The Jira ticket links to a Confluence page with the API spec. The spec says every request must verify that the authenticated user belongs to the account that owns the records before updating them.
3. Qodo follows the link from the ticket to the spec and compares the code changes against its requirements.
4. Qodo flags the missing account-level authorization check as a security issue. Without it, a user could modify another customer’s data. The requirement was in the spec, but not in the ticket or the code.

Diff review catches broken code. Spec review catches code that runs fine and still does the wrong thing.

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

Connecting intent to implementation

Following a spec link gives Qodo a concrete source of requirements to compare against the implementation. That surfaces 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 spec gives them one more way to catch gaps before a change merges.

It also means teams don’t have to duplicate requirements. Detailed specs stay in the documentation tool, and tickets reference them.

Code review asks whether a change is well implemented. It also has to ask whether the change delivers what was intended. Answering that usually takes context beyond the code and the ticket.

By following links from tickets to specs, Qodo brings that intent into the review, so teams catch requirement gaps where they can act on them: in the pull request.