Reviewing code the author never wrote and the model never understood

A tech lead at a logistics company told me about a review that bothered him for weeks. An engineer on his team opened a pull request that touched routing logic, and it was clean. Tests passed. The description was thorough. During the walkthrough the engineer paused on one function and said he was not entirely sure why it was written that way, the agent had produced it and it worked. The reviewer nodded, because he was not sure either. They shipped it. Nothing broke that week. What bothered the tech lead was that approval had happened without anyone in the room able to explain what they approved.

Approval used to imply understanding

For a long time, a review approval carried a quiet promise. Someone had read the change, followed the logic, and could answer for it later. The author understood it because they wrote it line by line. The reviewer understood it well enough to sign off. That chain is what made a green check mean something.

Agent-written code weakens both links at once. The author did not compose the change, they prompted it and accepted it, so their understanding can be thinner than the diff suggests. The reviewer, seeing a competent author and a passing suite, extends the usual trust. Now you have two people signing a change that neither of them can fully trace, and the paperwork looks identical to a review that was done properly. The signal that used to tell you “a human vouches for this” still shows green. It just means less than it did.

This does not mean the code is wrong. Most of the time it runs. The risk shows up later, when the routing logic needs to change and the person who owns it opens the file and meets a stranger. They cannot modify what they never understood, so they rewrite it, or they page the one engineer who has a vague memory of the prompt. The cost was not paid at review time. It was deferred to the first person who has to touch the code under pressure.

Make the review about understanding, not throughput

The fix is not to ban agent-written code. It is to restore the thing approval was supposed to mean. A reviewer approves a change when they can explain it, not when the tests are green and the author seems confident. That standard is slower on the day of the review and much cheaper every day after.

What teams that keep review honest tend to require.

The author can explain every part of the change in their own words, including the parts an agent wrote, before it goes up for review.
The reviewer reads for intent and follows the logic, and blocks anything they cannot personally trace, agent-written or not.
Sections nobody can explain get rewritten until someone can, rather than shipped on the strength of a passing suite.
The description says what the change is meant to do and why, so the reviewer is checking against a stated intent instead of guessing it.
Ownership of the changed code is named, so there is a person who will have to understand it when it breaks.

None of this slows a team that was reviewing properly. It only slows the reviews that were already skipping the part that mattered.

How we think about it at Density Labs

Most of the review problems we see with AI-assisted code are not about the model writing bad code. The model writes plausible code, and plausible code passes the checks that were designed to catch obvious mistakes. What it does not pass is a person who has to maintain it a quarter later and cannot find anyone who understands it.

When we help a team set up an AI-assisted workflow, we treat the review standard as part of the design, not an afterthought. The question we keep asking is simple. When this change breaks, who can open the file and explain it. If the answer is nobody, the review did not happen, whatever the green check says.

An agent can write the code. It cannot answer for it. Somebody still has to.