AI-written code looks confident even when it is wrong. A practical checklist for reviewing it: what to check first, common traps, and how to keep reviews fast.

AI assistants write code that looks clean, runs on the first try, and comes with tidy comments. That is exactly why it needs a careful look. The code looks equally confident whether it is correct or quietly wrong.

You do not need to review it any slower than human code. You need to review it a little differently, and know where it tends to slip.

A review order that saves time

Reading line by line from the top is the slowest way to find problems. Go from big questions to small ones, and stop as soon as you find a reason to send it back.

If an early check fails, there is no point polishing the later ones.

Check 1: Does it solve the actual problem?

AI answers the question it was given, which is not always the question you meant. Read the original request, then read the change. Look for code that is missing a requirement, or extra code nobody asked for. Over-engineering is common: new helper classes, extra options and abstractions for a task that needed ten lines.

Check 2: Are the dependencies real?

Models sometimes call functions that do not exist, use options a library never had, or import a package with a convincing but made up name. Make a habit of checking:

  • Every new import or package. Does it exist, and is it the one you intended?
  • Every unfamiliar function or option. Open the official docs.
  • Version fit. Code may use an old API that your version has changed or removed.

Check 3: Behavior on awkward input

The happy path usually works. Bugs hide at the edges. For each function, ask what happens with an empty list, a missing value, a very large value, a negative number, or text in an unexpected format.

Then look at the tests. AI-generated tests often pass because they mostly repeat the implementation. A useful test fails when the code is wrong.

weak_test.py
# This test only restates the code, so it can never catch a bug.
def test_total():
    items = [10, 20]
    assert total(items) == sum(items)

# Better: use a known answer and an edge case.
def test_total_known_values():
    assert total([10, 20]) == 30
    assert total([]) == 0

Check 4: Safety

This is the check you must not skip. Assistants often copy patterns that are common, not patterns that are safe. A classic example is building a database query by gluing strings together:

Never place user input directly inside a query string.

Also look for secrets written into code, missing permission checks, overly broad error messages that leak details, and user input that is printed back into a web page without escaping.

Check 5: Does it fit our codebase?

The last pass is about consistency. Does it follow your naming, error handling and folder structure? Does it reuse an existing helper instead of writing a second version? A small amount of cleanup here keeps the project readable.

Keeping reviews fast

  • Keep changes small. A 40 line change gets a real review. A 900 line one gets a skim.
  • Ask the author to explain it. If the person who prompted the AI cannot explain the code, it should not be merged.
  • Automate the boring parts. Linters, type checks and tests catch many problems before a human looks.
  • Run it. Ten minutes of actually using the change beats an hour of staring at it.