Our review checklist for AI-generated pull requests
Twelve questions every change answers before it’s merged, whoever or whatever wrote it.
AI coding tools changed how fast code gets written. They didn’t change who is responsible for it. At Sampan Labs, a human engineer reviews every pull request, and their name goes on the merge. This is the checklist they use.
Understanding
- Can the reviewer explain what this change does, line by line?
- Does it follow the patterns already in the codebase, or invent new ones?
- Is there anything clever that should be boring?
Correctness
- Are there tests, and do they test behaviour rather than implementation?
- Have edge cases been considered: empty lists, time zones, currency rounding, duplicate submissions?
- Does it handle failure: network errors, timeouts, partial writes?
Security & data
- Is all user input validated on the server?
- Are permissions checked for every new endpoint?
- Is personal data kept out of logs, URLs and error messages?
- Are any new dependencies maintained, licensed suitably and actually needed?
Maintainability
- Would a new team member understand this in six months?
- Is anything here that we would be embarrassed to hand over to a client?
What we noticedAI-generated code tends to be confidently verbose. It adds defensive checks that hide real bugs, and it invents helper functions that already exist elsewhere in the codebase. The second question under Understanding catches more issues than any other.
Is this slower than accepting whatever the tool suggests? A little. It’s much faster than debugging code nobody understands in production.
