Reviewing AI-written code: what to look for that humans never do
A junior engineer's pull request looks uncertain. Naming wobbles, a helper is half-finished, there is a comment that says // not sure about this. You know where to look because the code tells you where the author was uncomfortable.
An agent's pull request looks finished. Consistent naming, tidy structure, docstrings on everything, tests that pass. The uncertainty is invisible, and it is in specific places. Reviewing it like human code — scanning for style, reading for sloppiness — checks for the failure mode it does not have.
Six places to look first
In rough order of how often they turn out to matter:
- <strong>Tests that assert the implementation.</strong> The test calls the function, the function returns what it returns, the assertion agrees. It will pass forever and catch nothing. Ask of every test: what change to the source would make this fail?
- <strong>Errors swallowed on the way past.</strong> A caught exception, a logged warning, a default returned. The symptom is gone and the failure is now invisible. This is the single most common defect in agent-written code, because “the error went away” is the reward signal.
- <strong>A second way to do something you already do.</strong> A new date helper, a new fetch wrapper, a new validation pattern, parallel to the three you have. Each one is locally reasonable and collectively how a codebase becomes unmaintainable.
- <strong>Confident handling of an edge case that is wrong.</strong> Empty list, single item, timezone boundary, concurrent write. Agents rarely leave these unhandled; they handle them plausibly, which is harder to spot.
- <strong>Invented interfaces.</strong> A config key that does not exist, a library method with the right name and wrong signature, an env var nobody sets. Usually caught by types or a test — unless it is in a branch only production reaches.
- <strong>Work outside the request.</strong> A refactor you did not ask for, ridden along with the fix. Sometimes an improvement, always an unreviewed change, and it is why a two-line fix arrives as three hundred lines.
Read for decisions, not for defects
Human review is partly a defect hunt because humans make sloppy mistakes. Agent review is closer to an architecture review: the code almost certainly runs, so the question is not “is this correct” but “is this the approach we want to live with.”
- 01Start with the acceptance criteria.
If they were not written, the review has no baseline and you are reverse-engineering intent from a diff. Write them now, then review against them — and notice how often the criteria you write are not what the diff does.
- 02Read the tests, then the diff.
The tests tell you what the author thought the requirements were. Disagreements between the tests and your criteria are the actual findings.
- 03Grep for what already existed.
Before accepting a new helper, search for the three that do almost the same thing. Duplication is the defect that compounds; a bug is local, a fourth date utility is forever.
- 04Hunt every catch, default and fallback.
For each one: is this failure genuinely expected and safe, or is this a real error being converted into a plausible-looking success?
- 05Check the size against the request.
A one-line fix in a four-hundred-line diff means unreviewed work landed. Ask for the split, or accept that you have reviewed the fix and not the rest.
Make the machine catch the mechanical half
Most of the above is judgement, but a meaningful slice is mechanical and should never reach a human:
- Types and a strict linter, running in CI, non-negotiable. Invented interfaces mostly die here.
- Coverage on the diff, not the repo — which tells you whether the <em>new</em> code is tested, the only number that matters in a review.
- A rule against new dependencies without a note in the PR. Agents add packages freely.
- Formatting and import ordering fully automated, so no human minute is ever spent on them.
The goal is to spend your attention where only a person can help: on whether this is the right approach, whether it duplicates something, and whether the failure cases are handled honestly. Everything else is a machine's job.
You are not checking whether the code works. You are checking whether the code is a decision you would have made.
None of this argues for less AI-written code. It argues that the review has to match the failure mode of the author. Agents do not produce sloppy code; they produce confident code, and confidence is precisely what review exists to test.
A week of senior engineering: your bottleneck shipped, your conventions written down, and your existing code reviewed by someone who has been doing this for twenty years.
See how the free week works →