A code review checklist for AI-generated changes

Start with the requested behavior and read the diff against it. A patch can fix the reported bug and still introduce an unrelated change. In our episode, the example is an agent asked to fix padding that touches login. The useful review question is: what did the agent change that the task never authorized?

1. Set the boundary before reviewing the diff

Write down the behavior that should change and the parts that should stay stable. For a spacing fix, the expected result may be a button lining up at two viewport widths. Review the component and style changes first. If the patch also changes authentication, account lookup or a dependency, ask why that change is necessary. Separate it if it needs its own review.

2. Check behavior, including the original failure

• Reproduce the original problem or use an existing regression that captures it.
• Run the smallest useful check against the exact revision under review, then run the repository’s normal gates.
• Read the test changes as part of the patch. Look for removed assertions, broader mocks or expectations that were changed to match a broken result.
• Exercise an adjacent behavior when the diff can affect it. For a layout change, check keyboard focus and narrow screens. For an authentication change, exercise both allowed and denied access.

A green suite answers the cases that were exercised. It does not explain why an unrelated file changed.

3. Give a person ownership of the merge

The reviewer should be able to explain what changed, why each material change belongs, what evidence supports it and what still needs checking. If the diff crosses an ownership boundary such as billing or authentication, bring in the person who understands that boundary before merging. If the patch is too large to explain, ask for a smaller change you can validate.

For more examples of what to inspect in an agent-generated patch, see the OWASP secure coding with AI guidance.