01
Review starts before code is generated
A reviewer cannot assess success against an undefined requirement. Start with the behaviour that should change, the behaviour that must stay the same, acceptance criteria and relevant constraints. Name the person or team that will resolve uncertainty.
For the site’s illustrative category-filter ticket, this means agreeing that Slots and Live Casino results stay separate and that switching categories behaves correctly. A syntactically valid filter is only part of that requirement.
02
Ask for evidence that can be inspected
A useful review package includes the proposed code change, relevant repository context, test changes, actual test output and remaining questions. Distinguish tests that were proposed from tests that ran. If an environment could not be exercised, record that limitation rather than presenting a pass.
AI-generated explanations can help a reviewer navigate a change, but the explanation is not proof. Check it against the implementation, the calling code and the intended behaviour.
03
Review beyond the changed lines
Consider the paths affected by the change: callers, data boundaries, permissions, error handling and compatibility with existing behaviour. Assess whether the work follows the codebase’s conventions and whether a smaller change would meet the same requirement more clearly.
Use automated checks where appropriate, including existing tests and configured security analysis. They provide evidence for review; passing checks do not establish that the requirement is correct or that all risks have been examined.
04
Make rework an explicit outcome
Approval is only one possible review result. A reviewer may request a narrower implementation, additional tests, an explanation of an unexpected change or clarification of the requirement. Feedback should identify the unresolved issue and the evidence needed to close it.
A second AI review can help surface questions, but it should not be treated as an independent guarantee of correctness. GitHub’s own guidance says AI review can miss issues or raise false positives, and generated code should be reviewed and tested. Read GitHub’s responsible-use guidance.
05
Separate code review from release authority
A change can be technically acceptable while still needing release scheduling, operational checks or business approval. Agree who may approve a change, who may merge it and who may deploy it. Keep production permissions aligned with those responsibilities.
In Fusion Autonomous, JadeX engineers review changes and request rework or approve them for your agreed release process. Your team sets priorities and retains release control. Production access and release permissions are agreed before delivery begins.
06
Know who owns review in your service
With Fusion Standard, your team runs the platform and controls approvals; JadeX engineering services are arranged separately. Autonomous includes JadeX engineering review, oversight and escalation within the agreed service scope. Confirm the boundary for your engagement.
- Who is the named reviewer for each type of change?
- Which checks are required, and where is their output recorded?
- What happens if a reviewer cannot validate the result?
- Who resolves disagreements about acceptance criteria?
- Who has the final release decision?
For access and ownership questions, see the Fusion FAQ.