WordPress 
AI-generated code can look polished while missing an essential rule. A function may have sensible names and helpful comments yet allow the wrong user to change a record. Review needs to establish what the code actually does, how it fits the application, and what evidence supports its behavior.
Imagine a new endpoint that lets customers download invoices. The visible button works for the account used during development. A meaningful review also asks whether another account can change the invoice identifier and retrieve someone else’s document.
Start with the requirement and the diff
Read the original request and acceptance criteria before examining the implementation. Identify the entry points: a route, command, event handler, background job, or administrative action. Follow the data from input through validation, permissions, storage, and output.
Review all changed files. A small interface feature may also alter dependency versions, database structure, or an application-wide helper. Ask why each change belongs to the task. Unrelated edits deserve separate consideration because they can introduce risks that the feature’s tests never exercise.
Verify assumptions about APIs and data
Check unfamiliar functions and library options against official documentation for the version in use. Confirm that parameter order, return values, asynchronous behavior, and error cases match the implementation. A plausible API name is not evidence that the API exists.
Inspect data assumptions too. Can a value be missing, empty, repeated, out of order, or larger than expected? Does the database enforce an important uniqueness rule? If money or time is involved, check rounding, units, and timezone boundaries explicitly.
Review trust boundaries
Treat every external input as something the server must evaluate. A disabled button or hidden field does not establish permission. For the invoice endpoint, confirm both that a user is authenticated and that the requested invoice belongs to an account they may access.
The OWASP Authorization Cheat Sheet recommends denying access by default and validating permissions on every request. Apply that guidance to the download itself, including any file-storage path, rather than relying on the page that links to it.
Look for future maintenance costs
Check whether the change duplicates business rules or creates a second path for the same action. A permission rule implemented separately in three places is easy to update inconsistently. Favor existing application services and clear responsibilities.
Review new dependencies for purpose, version constraints, and maintenance requirements. A library can be a good choice, but the reviewer should understand why the feature needs it. Remove dead code and comments that merely repeat what a line does.
Ask for evidence you can reproduce
- Run relevant automated checks against the actual changed code.
- Exercise a successful action and representative failures.
- Test with a different user or role where permissions matter.
- Inspect output, logs, and persistent state after failures.
- Record unresolved concerns before approving a release.
Review becomes more manageable when changes stay small. Pair this checklist with the testing guide for AI-built software so that a convincing implementation also has convincing behavioral evidence.