How to Review AI-Generated Code Before You Merge It

The code compiles. The tests pass. The assistant says the task is complete.

You still need to know what changed.

A working demonstration can hide a permission problem. A passing test can check the wrong requirement. A small interface request can arrive with an unnecessary dependency and changes to unrelated files.

To review AI-generated code, start with the requested behavior, inspect the implementation in context, and verify the evidence behind the completion claim.

The workflow below is an editorial recommendation. It applies established review practices to AI-assisted development. It does not assume that AI-generated code is always defective or that human-written code deserves less scrutiny.

Define what completion means

Before reading the diff, write a short description of the expected behavior.

Consider a hypothetical request:

Allow a workspace administrator to rename their workspace.

That sentence leaves several decisions open:

• Which users count as administrators?
• Can an administrator rename another workspace?
• What happens when the name is empty?
• Does the change survive a reload?
• What appears when saving fails?

Turn those decisions into observable requirements.

This gives the review a reference point outside the implementation.

Without that reference, it is easy to approve code because it behaves consistently with itself.

Read the change boundary first

Before reviewing individual functions, inspect the file list.

For the workspace example, changes to a settings component, an API handler, a service and relevant tests may be expected.

Changes to authentication middleware, dependency versions, deployment configuration or unrelated screens need an explanation.

A useful first pass is:

git diff --stat BASE...HEAD
git diff --name-status BASE...HEAD
git diff BASE...HEAD

Replace BASE and HEAD with the actual comparison refs. Confirm that they represent the intended starting point and proposed change.

Classify unexpected files before proceeding. Some may be necessary. Others may be formatting noise, abandoned attempts or unrelated cleanup.

My recommendation is to separate unrelated refactoring from a behavior change when practical. A focused diff makes it easier to establish cause and effect and to revert the change if necessary.

Google's review guidance similarly advises keeping major style changes separate from functional changes because combining them complicates review, merges and rollbacks.

Follow one action through the system

A diff shows edited lines. A feature runs through a system.

Trace the primary action from the interface to the stored result:

1. The user enters a name.
2. The interface submits a request.
3. The server identifies the user.
4. The server checks permission for the target workspace.
5. The server validates the input.
6. The update is persisted.
7. The response updates the interface.

Inspect the relevant surrounding code, including functions that were not changed.

For example, a new handler may call an existing helper named updateWorkspace. That name does not establish whether the helper checks workspace membership, starts a transaction or simply updates a row by ID.

The review needs the helper's actual behavior.

Also inspect the return path. A successful HTTP response is not enough if the interface continues showing stale data or claims success before persistence finishes.

Check permissions at the server boundary

Hiding a button is useful interface behavior. It does not establish who can perform the action.

In the workspace example, an ordinary member should not gain access by sending the same request directly. An administrator should not gain access to another workspace by changing an ID.

OWASP recommends denying access by default and validating permissions on every request. Its authorization guidance also includes tests for authorization logic.

For this hypothetical feature, the review should establish:

• Where the authenticated identity comes from
• How the target workspace is selected
• Where the permission decision occurs
• Whether the decision applies to that specific workspace
• What happens when access is denied

A role check can be incomplete.

“Is this user an administrator?” and “Can this user administer this workspace?” are different questions.

Use the project's established authorization mechanism. Adding a second permission system for one feature creates another place where rules can diverge.

Inspect dependencies as part of the implementation

A small feature can introduce a large maintenance decision.

If the change adds a package, identify the exact problem it solves. Check whether the project already has an equivalent utility or component.

For a workspace rename form, a new form framework, validation library or state-management layer might be unnecessary. For a broader feature, one of those additions might be justified.

The review should explain the choice.

Inspect both the package manifest and lockfile. Confirm that dependency changes are intentional, that the API used matches the installed version, and that the package fits the deployment environment.

A plausible import statement is not evidence that the dependency exists or behaves as expected.

For uncertain APIs, use the dependency's official documentation and the version installed in the repository.

Review the tests against the requirement

Generated tests are part of the proposed change. They need review too.

A test might verify that clicking Save calls a mocked function. That can be useful, but it does not establish that the server enforces workspace permissions or that the value survives a reload.

For the example feature, different checks answer different questions:

Choose checks according to the change. A label correction does not need the same verification as an authorization change.

Read the assertions closely. A test titled “rejects unauthorized users” may only assert that a mocked rejection is displayed.

Google's engineering guidance explicitly asks reviewers to check whether tests are useful and whether they would fail when the code is broken.

For a critical rule, one useful technique is to temporarily break that rule locally and confirm that the relevant test fails. Restore the implementation afterwards. This is a targeted check of the test's value, not a requirement to mutate every line.

Use AI review as another source of findings

An AI reviewer can help inspect a diff, identify missing cases and suggest where to look next.

Its output still needs verification.

GitHub's responsible-use guidance describes Copilot code review as a supplement to human review and states that users remain responsible for validating generated responses.

A useful review request gives the reviewer a concrete job:

Review this change against these acceptance criteria:

1. Only administrators of the target workspace can rename it.
2. Empty names are rejected by the server.
3. A failed save preserves the entered name.
4. A successful change survives a reload.

Inspect the diff and the relevant surrounding implementation.

For each finding:
- identify the file and relevant code;
- explain the failing scenario;
- distinguish a confirmed defect from an unresolved question;
- propose a focused verification step.

Do not modify files.
State which checks you actually ran and which you only recommend.

This prompt is a practical starting point, not a guarantee of review quality.

Follow up on findings by inspecting the referenced code and reproducing the scenario where possible. An authoritative explanation can still be wrong.

A second model or a fresh session may provide another perspective. It does not create proof of correctness.

Separate reported checks from observed checks

“Tests pass” is incomplete.

Which tests? Against which revision? In which environment? Did the command finish successfully, or did it stop before collecting tests?

A useful handover records:

Change:
Workspace administrators can rename their workspace.

Verified:
- Relevant API integration tests passed.
- Cross-workspace update was rejected.
- Saved name remained after a browser reload.

Not verified:
- Production deployment.
- Browser behavior outside the tested environment.

Review note:
No dependency or schema changes.

Only include statements supported by the work performed.

If the environment cannot run a check, record the limitation precisely. Do not convert “unable to run” into “probably fine.”

For client work, this distinction helps the person accepting delivery understand what the implementation actually demonstrates.

Inspect the final revision

Review feedback often produces another patch.

That patch can fix the original problem while introducing a new one. It can also change the code after the last successful test run.

Review the final diff and rerun checks affected by the fix.

For the workspace example, moving authorization into a service might require checking every caller of that service. Changing only an error label would require a smaller verification step.

Match the follow-up work to the actual change.

Before merging, establish four things:

1. The final implementation satisfies the agreed behavior.
2. Relevant failure and permission cases have been checked.
3. The final diff contains only understood changes.
4. Someone is responsible for the merge and release decision.

AI can produce an implementation, explain it and help review it. Acceptance still depends on evidence about the code that will actually ship.