Teams sometimes invent a softer review for generated code, because the diff is large and because nobody wants to admit they do not understand a change they requested. The softer review is how the generated code becomes the architecture. The standard does not depend on who typed the line.
A review has the same three questions as always. What does this change do for a caller? What can it break, including the cases the tests do not name? What does it add that the task did not require? If the answer to the third question is a new dependency, a new service, or a new pattern, that is a separate decision and it needs a reason outside the chat.
Do not ask the same assistant to approve its own patch and then treat that approval as the review. It will agree with itself in fluent paragraphs. A second person is best. If you are working alone, review on a second pass the next morning, from the diff, with the chat closed. Distance is doing the work a colleague would have done.
Leave a short note on why the change was accepted. “Handles the empty cart by returning no results; does not alter checkout.” That note is for the next reader. It is also a check that you could say what you merged.