1. Start from business rules, not syntax
A generated change may compile and still violate architecture boundaries, leak data, ignore edge cases or break an undocumented business rule. The agent does not know what it was not told, which is dangerous in legacy systems with accumulated rules.
The question is not whether AI wrote the code. The question is whether the team can own the whole change after deploy.
- Compare the change against screens, endpoints, real data and support history.
- Check whether the code follows existing project patterns.
- Review data access, validation and error behavior.
- Confirm that secrets or credentials were not introduced.
- Make sure future maintainers can understand the change.
2. Distrust the tests the agent wrote, and read the whole diff
Generated tests often pass because they describe the implementation, not the expected behavior. In a bug fix, require at least one test that would fail without the change. High, empty coverage exercises lines without asserting behavior.
The agent summary describes intent, not necessarily what changed. Read every file, including ones touched in passing: new dependencies, config, Dockerfile, migrations, or removed code that supported an old case.
- Require a test that fails without the fix and passes with it.
- Check failure paths: null input, timeout, missing permission, rejected constraint.
- Review new dependencies for necessity, maintenance and compatibility.
- Inspect config, environment and permission changes in the diff.
- Verify logs and metrics for important failures.
3. Security and agent agency
When an agent reads issues, comments, pages or logs, it can find hidden instructions trying to redirect its behavior: the prompt injection described in the OWASP Top 10 for LLM Applications 2025. An agent allowed to run commands has real agency and can delete data, publish something or leak secrets without limits.
A visible, lightweight review routine keeps velocity from becoming operational debt, and keeps ownership clear.
- Do not treat content the agent read as trusted instructions.
- Limit the tools and access the agent has in environments with real data.
- Review queries, permissions and data exposure.
- Run tests and build locally, not only trusting the agent report.
- Test the critical route in staging and plan rollback for sensitive flows.
How to use this article
Treat this page as a decision aid. Use it with the related hub, checklist or service route when the topic affects production, customer experience, deployment, security or business continuity.