AI code review and AI-assisted testing answer different questions. Review asks whether a proposed change looks correct, secure and appropriate in context. Testing executes behavior and produces evidence about what the code actually does. Engineering teams need both—and neither should be allowed to approve its own work without independent checks.

The distinction matters most when a coding agent creates the pull request. The AI Testing & Evaluation hub places review and testing within a broader quality system; the Coding Agents hub covers scope, permissions and human ownership.

What AI code review can do

An AI reviewer reads the diff and selected repository context. It can help identify:

• changes outside the requested scope;
• missing error handling and unsafe defaults;
• suspicious data flow or authorization logic;
• inconsistent patterns and maintainability problems;
• likely dependency or API misuse;
• missing tests for newly introduced behavior;
• comments and documentation that contradict the code.

These are hypotheses until verified. A reviewer can misunderstand product intent, miss runtime state or confidently flag a deliberate pattern as a defect.

What testing must prove

Execution-based checks can establish that:

• code compiles, types and passes static checks;
• units handle specified inputs and boundary cases;
• components integrate through real contracts;
• migrations and configuration work in a representative environment;
• permissions and tenant boundaries are enforced;
• user workflows remain functional;
• failures, retries and rollback paths behave safely;
• performance stays within an agreed budget.

Tests are only as strong as their fixtures and assertions. Agent-generated tests can repeat the same mistaken assumption as agent-generated implementation code. A green suite is not evidence if the test never exercises the requirement.

Side-by-side responsibilities

Question	Review	Testing
Is the requested scope respected?	Strong signal from diff and task	File-scope checks can enforce part of it
Does the design fit the architecture?	Human and AI review	Architecture tests cover explicit boundaries only
Does the code run?	Can infer, cannot prove	Build and execution prove it
Are edge cases handled?	Can propose cases	Must execute representative cases
Is authorization correct?	Can inspect policy and call sites	Negative tests must prove denial and isolation
Will behavior regress later?	Reviews one change	Persistent tests provide ongoing protection
Is the change acceptable to own?	Human decision	Tests provide evidence, not ownership

Do not frame this as a contest over which catches more bugs. They observe different evidence.

A pull-request workflow for coding agents

1. Bound the agent before it writes

Provide the objective, allowed files, prohibited actions and validation commands. Use a branch or isolated worktree, not direct production access. Separate repository permissions from deployment credentials.

2. Inspect the diff before running it with privilege

Check:

• intended files only;
• no generated artifacts or secrets;
• dependency and workflow changes called out explicitly;
• no disabled tests or weakened security controls;
• migrations and destructive operations identified.

Untrusted pull-request code can modify build scripts and test commands. Do not execute it in a privileged workflow with production secrets.

3. Run deterministic quality gates

Use the project’s real build, type checker, linter, unit tests, integration tests and security scanning. Add focused tests for the requested behavior rather than relying only on the existing suite.

4. Review the implementation and tests separately

A reviewer should confirm that tests fail when the new behavior is broken, cover important failure paths and do not merely mirror implementation details. Where risk warrants it, use a different human or agent context for review than generation.

5. Require human approval

The reviewer owns the merge decision. Repository rules can require passing status checks, approving reviews and code-owner approval before a protected branch changes. AI comments should inform that decision, not impersonate accountability.

The GitHub Actions foundation covers protected checks, artifacts and credential boundaries.

Security checks for AI-generated changes

At minimum, evaluate:

• hardcoded secrets and sensitive logging;
• injection and unsafe deserialization;
• missing authorization at resource and argument level;
• dependency changes and supply-chain risk;
• privileged workflow modifications;
• network and filesystem access added by the change;
• error messages that expose internal state;
• insecure fallback behavior.

Static analysis can find patterns; integration and negative tests prove important controls. Human reviewers must decide whether the permission model itself is appropriate.

Testing generated tests

Before accepting a generated test:

1. map every assertion to a requirement;
2. deliberately break the implementation and confirm the test fails;
3. inspect fixtures for unrealistic shortcuts;
4. verify external systems and side effects are isolated;
5. remove arbitrary sleeps and broad selectors;
6. ensure the test does not require production credentials;
7. check that retries do not hide flakiness.

For browser workflows, use Playwright testing for AI applications and retain traces for failures. For the complete release workflow, see testing AI-generated code before shipping.

Quality gates should be risk-based

A documentation edit and an authentication change should not require identical evidence. Define stronger gates for code that touches:

• identities, permissions or secrets;
• payments and destructive actions;
• migrations and persistent state;
• deployment workflows;
• public APIs and compatibility;
• autonomous agent tools.

Use required checks to prevent accidental merges, but do not confuse automation with judgment. A technically green change can still be unnecessary, overbroad or operationally unsafe.

The practical division of labor

Use AI review to widen attention: explain the diff, surface risks and propose missing cases. Use tests to execute behavior and preserve regression protection. Use humans to validate intent, resolve ambiguity, approve risk and own the release.

That three-part system is stronger than either “AI reviewed it” or “the tests passed.”