Review an AI Code Change Against the Request You Actually Made

Review an AI-generated change by matching three things: the requested behavior, the code that changed and the checks that support it. A clear completion message is a useful starting point; the patch and its relevant results tell you what you can accept.

You do not need to review every change in the same way. A copy adjustment and a data migration deserve different checks. The worksheet below helps you choose the checks that belong to the actual task rather than accepting a generic “tests pass” summary.

Turn the request into a small review table

Before reading the patch, identify the change you asked for and the behavior it should preserve:

Requested result:
[What should work differently?]

Change boundary:
[Which files, behavior or components belong to this task?]

Keep unchanged:
[What existing behavior matters?]

Checks needed:
[Examples, tests or inspections that would support the result.]

Actual evidence:
[Record what you really inspected or ran, with its reference.]

Review decision:
[Accept this scope / request a correction / need another check.]

Keep the “checks needed” and “actual evidence” fields separate. A list of test names describes a plan until those tests have a recorded outcome.

Work through a small patch

The following original, fictional Python example shows the method with a small function.

Imagine a task list with a status filter. The request is:

“Make the all filter return every task in its existing order. Preserve filtering by a specific status. An empty input should still produce an empty result. Keep the change inside visible_tasks.”

The initial function is:

def visible_tasks(tasks, selected_status):
    return [task for task in tasks if task["status"] == selected_status]

It compares every task's status with the selected value. The proposed change gives all its own branch:

 def visible_tasks(tasks, selected_status):
+    if selected_status == "all":
+        return list(tasks)
     return [task for task in tasks if task["status"] == selected_status]

For this example, the input is a list of task dictionaries with a status value, and all is reserved for the filter option. Those assumptions matter: the patch does not define how to handle malformed records or an unrelated task status also named all.

Match each part of the request to evidence

The last row is easy to miss. A snippet can show an appropriate fix while the full change contains an unrelated settings adjustment or generated file. Read the complete change surface before deciding that the scope is correct.

Use concrete example checks

For the fictional function, these checks express the requested behavior:

tasks = [
    {"id": "b", "status": "waiting"},
    {"id": "a", "status": "done"},
    {"id": "c", "status": "waiting"},
]

assert [t["id"] for t in visible_tasks(tasks, "all")] == ["b", "a", "c"]
assert [t["id"] for t in visible_tasks(tasks, "waiting")] == ["b", "c"]
assert visible_tasks(tasks, "missing") == []
assert visible_tasks([], "all") == []
assert visible_tasks([], "waiting") == []

These are example checks for the tiny function. In a real application, you might also need an integration check that the UI sends the expected filter value and renders the returned tasks. Passing a function-level check would not establish that the whole page is correct.

Use your project's normal verification tools. If you run a check, record its actual result and the version of the change it covered. If you only read the code, write “inspected” rather than describing a successful test run.

Write a review that says what happens next

Here is a filled review for the fictional patch, based on reading the excerpt rather than claiming a test run:

Requested result:
The all filter returns all tasks in input order.
Specific-status filtering and empty input keep their behavior.

Inspected:
The two-line branch in visible_tasks.
The specific-status list comprehension is unchanged.

Still to check:
The complete repository diff.
The example assertions against the actual implementation.
The caller's filter value and the rendered task order.

Review decision:
The proposed branch fits the requested function-level behavior.
Complete the checks above before accepting the application change.

This review is useful because it identifies the next checks. It does not need to sound more certain than the work it describes.

Handle an unexpected extra change

Suppose the same patch also renames status labels across the interface. Ask what requirement made that necessary. It may be a real dependency, or it may be separate work.

A focused follow-up is:

“The new all branch matches the requested behavior. The label rename was outside the original task. Explain whether the filter fix depends on it; if not, separate it from this change. Then report the checks against the remaining patch.”

This preserves useful work while bringing the review back to the request. It also gives the coding tool a concrete correction rather than a vague instruction to “be more careful.”

For a finished review, record the accepted behavior, the relevant evidence and any remaining scope separately. A sent instruction, a proposed patch, a checked change and a deployed result are distinct points in the workflow. CueSpec's Docs explain delivery receipts and task completion if you are reading those states in its task view.