AI wrote the code. Who owns the deploy?

A pull request can arrive with an implementation, tests, and a convincing explanation in minutes. The reviewer gets a less convenient problem. They need to find out whether those changes meet the product's requirements, including when something fails.

The amount of code waiting for review can grow without a matching increase in the team's ability to understand it. Approving everything because the tests pass is tempting. It also hands the decision to tests that may repeat the implementation's mistaken assumptions.

GitHub documents that Copilot review can miss problems and suggest unnecessary changes. Human review remains part of the process. We recommend organizing that review around the behavior that must survive deployment.

Start with the rule that cannot break

Imagine an integration that receives a registration confirmation and creates a ticket. The provider can resend the same event. The product rule is that one registration produces one ticket, even when delivery repeats.

An implementation might look up the event, check that it does not exist, and save the ticket. Each line looks reasonable. Two simultaneous requests, however, can both perform the lookup before either writes anything.

The review needs to ask where the system enforces uniqueness. A database constraint can protect the write. If the flow also sends an email, the local transaction does not make that external send atomic. The design needs a way to record pending work and retry notification without creating another ticket.

This is a hypothetical example. The point is to look for decisions that depend on the whole system's behavior. A readable function does not solve concurrency on its own.

Follow the complete path

Trace the data from its entry point to its final effect. For the ticket example, read how the event's origin is verified, how the registration is identified, and how the write happens. Then inspect the notification.

Read the existing files that the new code calls. A function named createTicket might send email internally. An error handler might turn a failure into a success response. These details change what happens when the provider retries.

Ask for a short explanation of each new dependency. If a library only replaces a function already available in the project, remove it. Every added dependency will still need attention after the pull request closes.

Make tests challenge the implementation

Write expected outcomes without copying the code's structure. A review of this integration could require:

Situation	Expected outcome
The same event arrives twice	One ticket
Two deliveries arrive together	The uniqueness rule still holds
The ticket is saved but notification fails	Notification can resume without duplicating the ticket
The event has an invalid origin	No ticket created

A concurrency test needs to exercise the protection used for the write. A mock database that always returns the expected response can hide the very defect you are trying to catch.

When fixing a bug, confirm that the test fails without the fix. That step prevents celebrating a test that never observed the problem.

Shrink the change until you can explain it

A behavior change bundled with a folder reorganization and a dependency update costs more to review. Ask for separate changes when the work is independent.

Before approval, the person responsible should be able to describe the user-visible effect, the most likely failure, and how to notice that failure after release. They do not need to memorize every line. They need to know where to look when the first report arrives.

Record the limits of rollback, too. Reverting code does not automatically undo a destructive migration or recall a sent email. Those consequences belong in the release decision.

AI can help investigate the diff and suggest missing cases. Use that help. Approval still requires a change someone can explain and support when the happy path ends.