How to review AI-written code without slowing your team down

Reviewing code from a coding agent is not the same as reviewing code from a colleague. A person's mistakes usually look like mistakes: messy structure, a rushed function, an obvious gap. An LLM's mistakes tend to arrive neatly formatted, well named and confidently explained, so the usual signals of quality stop telling you much.

Here is what I look for. None of it is complicated, but it does require reading with a different kind of suspicion.

Start with the problem, not the diff

Before reading any code, restate what the change was meant to do. Agents are very good at solving a nearby problem. If the task was to fix a failing checkout for one customer type, did it fix the cause, or add a special case that makes this one failure go away?

A useful test for any bug fix is to ask where else the same mistake could happen. If the fix sits in one caller while the fault is in a function used by five, it is treating a symptom.

Do not trust the tests until you have read them

This is the most important habit on this list. An agent told to make the tests pass may do exactly that, in ways you did not want. Watch for tests that were weakened or deleted, assertions so loose they can never fail, and mocks that replace the very code being tested.

A simple check is to break the code on purpose and run the test again. If it still passes, it was not testing anything. Passing CI tells you much less than it used to, unless you also know that the tests mean something.

Check that things actually exist

LLMs can call functions, options and API endpoints that sound right and do not exist, or that belonged to an older version of a library. Compilers and type checkers catch many of these. They do not catch all of them, especially in dynamic languages or in configuration files.

New dependencies deserve particular care. Check that any added package is the real one, is maintained and is actually needed. A package name that merely looks plausible is also a supply chain risk.

Read the error paths

Generated code tends to be strongest on the happy path. So read what happens when things go wrong. Is an error caught and silently ignored? Does a failed payment leave the order half complete? Is there a retry with no limit, or a fallback that hides a real outage?

An empty catch block in generated code should always get a second look. It often means the code was made to run, not made to work.

Look for the security gaps a demo will not show

Authorization is the classic one. The code checks that a user is logged in but not that the record belongs to them, and every test passes because each test uses only one user. Check that input is validated at the boundary, that queries are parameterized, that secrets stay out of the code, and that logs do not capture personal data.

Watch the size and scope

Agents like to add things: a helper nobody asked for, a configuration option for a case that will never arise, a rewrite of a nearby file. Each one is more code to maintain, and it hides the real change inside a bigger diff. It is reasonable to send it back and ask for only what the task required. Also check whether the code duplicates something the codebase already has, because agents do not always look first.

Keeping changes small is the best way to keep review fast. A team that accepts a two-thousand-line diff because it looks tidy is not really reviewing.

Make the machines do the boring part

Human attention is the scarce resource, so spend it on logic and intent. Let formatters, linters, type checkers, dependency scanners and CI handle everything they can, and let those checks fail before a person ever looks at the change.

Finally, keep one rule that no tool changes: whoever approves the code owns it. "The AI wrote it" is not an explanation anyone can accept when something breaks in production. If your team needs help building that safety net, our QA and testing service covers test strategy and automation, and this post on how LLMs are changing development explains why it now matters so much.