How we review code an AI wrote

AI-assisted delivery

Bad code used to look bad. Now it doesn’t — and that changes what a code review has to catch.

An AI agent will hand you two hundred lines of plausible code in nine seconds. It will be indented properly. It will have sensible variable names. It will look, at a glance, exactly like code written by someone competent.

That is the problem. Bad code used to look bad. Now it doesn’t.

So the review skill has changed. Reviewing agent output is not the same job as reviewing a junior developer’s pull request, and teams that treat it as the same job ship bugs they never would have shipped before. Here is what we actually look for.

1. The code that solves the wrong problem, beautifully

The most common agent failure is not a syntax error. It is a confident, elegant, well-structured solution to a subtly different problem than the one you have.

You ask for retry logic on a payment webhook. You get textbook exponential backoff — clean, tested, correct. Except payment webhooks must be idempotent, and the agent didn’t ask whether yours was, because agents don’t ask. So now you retry a charge three times and bill someone thrice.

So the first review question is never is this correct? It is what did this assume? Read the code for its assumptions before you read it for its logic.

2. Error handling that swallows the thing you needed to know

Agents hate leaving a code path unhandled — it looks incomplete, and they are trained to produce complete-looking work. So they wrap things in try/except and carry on. The result is software that never crashes and never works.

• A caught exception that logs and returns None, and now a null flows three layers up into something that assumed it never could.
• A bare catch-all that hides the database connection error you desperately needed to see in production.
• A fallback default that is perfectly reasonable in isolation and catastrophic in context — a zero where the price should have been.

We grep agent output for swallowed errors before anything else. It is the single highest-yield review pass we run, and it takes about ninety seconds.

3. The confident wrong API

Ask an agent for code against a library and it will produce a method that should exist. Often it does. Sometimes the method was deprecated two versions ago, or exists on a different class, or is from a competing library with a similar name.

This one is mercifully cheap to catch — it fails immediately — but it is a reliable signal of something more worrying: when a model is uncertain, it does not get vaguer. It gets more specific. Hallucinated APIs come with confident inline comments explaining exactly why they work.

4. Security assumptions inherited from a training set

Agents reproduce the patterns they saw most often, and a great deal of public code was written by people who were not thinking about security. So you get string-interpolated SQL because a million tutorials did it. You get an authorisation check on the route but not on the underlying service, because that’s what most codebases do.

Every place an agent touches auth, input handling, file paths or a database query gets read by a human. Not skimmed. Read.

5. Tests that assert the code does what the code does

Agent-written tests have a specific pathology: they are written from the implementation rather than from the requirement. So they pass, they raise your coverage number, and they verify nothing at all — because if the implementation is wrong, the test is wrong in exactly the same direction.

A test that would still pass if the feature were broken is worse than no test, because it buys you confidence you have not earned.

Our rule: the agent may write the test body, but a human writes the assertion — the sentence that says what the system is supposed to do. That sentence has to come from the requirement, not from the code.

What this adds up to

None of this is an argument against AI-assisted development. We build this way every day, and it is genuinely faster — dramatically so.

But the speed comes from the agent doing the volume: the scaffolding, the boilerplate, the first draft of the tests, the documentation nobody wants to write. The judgment has to stay human, because judgment is exactly the thing the model is simulating rather than exercising.

That is the whole method. It is not complicated. It is just not optional.