A pull request can pass its checks and receive approval while still missing part of the original requirement. This can happen with AI-generated or human-written code. Reviewers see a diff, a summary, and limited context; the intent may live in a ticket, design discussion, or chat that is not connected to the change. Each check can succeed while the links between them remain incomplete.
Why review does not prove requirement fit
Code review checks a proposed change for issues a reviewer can identify from the available context. Automated tests check the cases they were written to exercise. Neither signal necessarily proves every acceptance criterion was understood or implemented. A test may cover the happy path but omit an authorization boundary. A reviewer may approve a focused diff without seeing a late requirement change.
Consider an export issue that asks a team member to download records from one workspace. The interface may display the right rows and a test may confirm the download starts, while the data query forgets to scope by workspace membership. A reviewer focused on the visible change may not notice that the original issue included an isolation requirement. Put the scope rule in acceptance criteria and include a request from another workspace in the check.
Connect requirements to the change
- Write testable acceptance criteria. Describe the observable outcome and relevant failure cases before implementation.
- Link the work item to the change. Keep the issue, decision, commit, pull request, and checks easy to trace.
- Review against the criteria. Consider each criterion, not only the diff summary.
- Record exceptions. Make changed requirements or skipped checks visible and assign follow-up work.
Distinguish claims from observations
A status change or agent summary is a claim. A connector that reads a commit or check result can record an observed artifact. A verification signal requires an independent check against a defined expectation. A test result supports the cases it covers; it does not automatically verify the whole feature or the original intent.
Reduce the chance of requirement drift
Start with one high-value workflow. Identify where intent is recorded, what artifacts show implementation, which checks provide independent evidence, and who resolves a mismatch. Close gaps in that chain before adding more status fields or paperwork. The aim is a reviewable connection between request and result, with uncertainty visible when evidence is incomplete.