Who Reviews the Code the Agent Wrote?

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

The change arrives complete. Tests pass, the diff is tidy, the commit message is better than most humans write. You read it, it looks right, you merge.

That is not a review. That is agreeing with something articulate.

Reviewing generated code is a different job from reviewing a colleague's, and pretending otherwise is how teams end up with a codebase everyone approved and nobody understands. The difference is that a colleague brings intent you can interrogate; a diff brings only the result.

Read for what is missing, not for what is wrong

A model writes fluent, conventional code. It is unusually good at the things review normally catches — naming, structure, obvious edge cases — and unusually bad at knowing what it was not told.

So the defects cluster differently. Not "this loop is wrong" but "this silently drops the case where the list is empty, because nobody said that happens". Not a bad abstraction but a plausible one built on a constraint that does not hold here.

Read for absence. Which failure mode has no branch? Which assumption about the data was never checked? What did it do instead of asking? Those are the questions a tidy diff will not answer for you.

Make it explain before you make it fix

The most useful review move is not "change this". It is "why this?"

An agent asked to justify a choice will either produce the constraint it was working from — which you can check — or produce a rationalisation, which is itself the finding. Fluent nonsense is easy to spot when it has to be specific: which requirement, which case, which measurement.

This works better when the project's rules are recorded rather than remembered. An agent working from a repeatable procedure argues from your constraints; one working from a blank page argues from the average of everything it has read, and cannot tell you which.

Volume is the real risk

One agent-written change gets read carefully. Twenty in a week do not — and twenty a week is the point of using one.

Review capacity, not writing capacity, is now the bottleneck. Teams that ignore this end up rubber-stamping, which is worse than not reviewing, because it produces a record saying somebody looked.

Two things help more than trying harder:

• Make the machine-checkable checks machine-checked. Types, tests, linters, a security scan. Human attention is too scarce to spend on what a tool can answer, and it is exactly what humans skim. An agent that also deploys needs to be told which of those checks it may never loosen to get a green build.
• Review the decision, not the diff. For a change with a real design choice in it, agree the approach before the code exists. Reviewing an implementation you would not have chosen is the most expensive way to discover you disagree.

What remains for a person is judgement: is this the right thing to build, does it fit what we already have, what happens when it fails. That does not scale with more reading — it scales with the reasoning being recorded as it happens.

FAQ

Should an AI review AI-written code? As a first pass, yes — it catches mechanical problems cheaply. It cannot catch a wrong assumption it shares, which is the failure that matters most.

Is it faster to rewrite than to review? Sometimes, for small changes. That is a signal about the task, not about the model: the change was under-specified, so review is doing the specifying.

What if I do not understand the code well enough to review it? Then the review is not the problem to solve first. Ask the agent to walk the change against the behaviour it affects, and check the claims against what actually runs.

How do I keep this from becoming a rubber stamp? Cap what merges unreviewed and be honest about capacity. On aidrop.it a build that fails reports why, so review starts from a named failure rather than from everything at once.

Do commit messages from an agent count as documentation? They describe the change, not the reason. The reason is the part worth writing down, and it is the part the model does not have.

Cover: https://unsplash.com/photos/afW1hht0NSs by Markus Winkler on Unsplash. Alt text: A magnifying glass resting on a plain white surface.