How to review AI-generated code before merging it

Write the behavior before requesting code

Give the assistant the repository instructions and the relevant files, then describe the smallest change. State what should happen for invalid input as well as normal input. This makes it easier to detect a polished implementation of the wrong requirement.

For this synthetic JavaScript exercise, convert a non-negative integer number of minutes into hours and remaining minutes. Negative values, fractions, and non-numbers must be rejected. We deliberately keep the exercise independent of a changing framework API.

Use a small, inspectable implementation

This example is practice code, not a production library. Run the accompanying checks and add cases appropriate to your own application.

export function splitMinutes(value) {
  if (!Number.isSafeInteger(value) || value < 0) {
    throw new TypeError("Expected a non-negative safe integer");
  }
  return { hours: Math.floor(value / 60), minutes: value % 60 };
}

Test the contract and the boundaries

For 0, expect { hours: 0, minutes: 0 }. For 59, expect { hours: 0, minutes: 59 }. For 60, expect { hours: 1, minutes: 0 }. For 125, expect { hours: 2, minutes: 5 }. Inputs -1, 1.5, "60", NaN and Infinity must throw.

Notice that accepting the string "60" by coercion would fail our contract even if the result looked reasonable. Tests should follow the agreed behavior, not copy assumptions made by the generated implementation.

Review more than the happy path

Inspect every changed file, including lockfiles and configuration. Look for unrelated edits, hidden network requests, logs containing sensitive values, new permissions and unnecessary dependencies. In a real app, also review authorization and failure behavior relevant to the change.

Use the repository’s required checks. Summarize the behavior changed, tests run and remaining limitations in the pull request. A second AI review can help find issues but is not proof of correctness.