AI Code Review: Test the Legacy Rules Before You Merge

Start with the rule the business depends on

An AI coding agent can propose an implementation and tests in the same session. That is useful for drafting, but the two outputs may share the same mistaken assumption. A passing test proves little about the business requirement if its expected result was copied from the proposed code.

GitHub's responsible-use guidance says Copilot code review can miss problems, flag nonexistent issues and suggest incorrect or insecure changes. It recommends human review and testing. The practical response is to give the reviewer evidence beyond the agent's explanation: the original requirement, existing behavior and an explicit list of intended changes.

A regression testing example: the forgotten exception

Illustrative example: an existing service-request router sends urgent requests to a specialist queue, including requests that have no location yet. A requested change introduces a regional queue for ordinary requests. The agent adds a location check first, accidentally blocking urgent requests without a location.

Before changing the router, capture representative inputs and the resulting queue or error. Include ordinary, urgent, missing-location and combined cases. The business owner must confirm that the urgent exception is intentional. Observing an old behavior does not automatically make it correct; a known defect needs a separately agreed correction.

For the new regional rule, write the expected result from the approved requirement. Keep that distinct from the baseline cases whose behavior should remain unchanged. This makes a changed result a question to investigate rather than something to accept by regenerating every expected output.

Make the old behavior testable without touching live work

Use isolated test data and a boundary where the relevant output can be observed. If a test would otherwise contact a live routing service, substitute a controlled response in the test environment. Fowler describes legacy seams as places that let teams vary behavior and isolate dependencies for testing.

A simulated dependency does not establish that the real integration still works. Add an appropriate integration check in a controlled environment for the boundary affected by the change. Record what was simulated and what actually ran, so reviewers can see the limits of the evidence.

An AI code review prompt should ask for evidence

Give the reviewer the requirement, the diff and the baseline cases. Ask: which branch changes behavior for an urgent request with no location, which existing test covers it, and what would reproduce a failure? Require concrete file locations and a proposed check, not a general assurance that the code looks good.

Keep review findings separate from proof. Reproduce a suspected failure where possible and inspect the business result. If a generated fix changes an expected test result, ask why the requirement changed. Do not accept a rewritten assertion solely because it makes the build pass.

Merge a bounded change, then keep its evidence

For the reviewed revision, record the tests run, important gaps and the behavior intentionally changed. Recheck relevant evidence after further edits. Agree on rollout observation and recovery before release; reverting code alone may not undo records or messages already produced.

Measure delivery by accepted changes that preserve the agreed workflows, not by the number of generated patches. A small experienced team can use AI to move faster while retaining ownership of exceptions, integrations and operations.

UVISION provides dedicated developers and managed projects with at least one full-time developer per project. In critical legacy systems, that continuity helps turn undocumented rules into maintained checks while the team keeps developing new capabilities and integrating AI.