How to Review Code That Nobody on the Team Wrote

Think about what actually happened the last time you reviewed a colleague's pull request and something looked off. You left a comment. They replied — maybe they explained a constraint you had missed, maybe they conceded and changed it. Either way, the review worked because there was someone on the other end who had held the problem in their head and could account for their choices.

That conversation is the mechanism. The diff was never the point; the diff was the agenda for a discussion between two people who had both engaged with the problem. Review caught defects as a side effect of that discussion.

Now the author is a model. The pull request is well formatted and the tests pass, but there is nobody on the other end who held the problem in their head. You can still leave a comment. Nothing will answer it in the sense that matters. The ritual is intact and the thing it was for is gone.

What Review Silently Becomes

When there is no author to interrogate, the reviewer has two options, and only one of them is honest about the cost.

The first is to reconstruct the reasoning alone — read the change closely enough to explain why it does what it does, what it touches, and how it fails. This is real work, often as much work as writing it would have been, and under Sprint pressure it is the first thing to be quietly skipped.

The second is to scan for anything obviously wrong, find nothing, and approve. This feels like review. It produces the same green tick, the same merge, the same throughput number. But the claim it makes has changed. “I have verified this change” has become “I found no reason to object to this change,” and those are not the same statement. The first is a positive act of understanding. The second is the absence of a red flag — and a well-formed piece of generated code is specifically good at not raising red flags.

Practice 1: The Comprehension Flag

Recover the discarded information. Alongside the approval, the reviewer records one of three states:

• Understood — I can explain what this does, why it does it that way, and what happens when it fails.
• Partially understood — I follow the intent and the shape, but not all of the implementation.
• Approved on trust — I found no reason to object. I could not reproduce this reasoning or defend it.

The mechanism is trivial — a label, a checkbox, a line in the merge template. The mechanism is never what fails. What fails is the third option being safe to choose.

If a developer believes that selecting “approved on trust” marks them as less capable than a colleague who selected “understood,” they will select it once, watch what happens, and never select it again. From then on the flag reports near-total comprehension across a codebase nobody understands. That is strictly worse than having no flag, because now the team has a number that says the problem does not exist.

This is where the practice stops being an engineering tweak and becomes Scrum Master work. The flag only produces honest data inside a team where admitting “I approved this but could not defend it” costs nothing socially. Building that safety is not a side task; it is the task. And it almost always requires the most senior person in the room to select “approved on trust” first, out loud, with no apology attached — because the juniors are watching what happens to the person who admits it before they decide whether to.

Practice 2: The Blast-Radius Declaration

A generated change tends to be locally coherent and globally blind. The model saw the file, perhaps the repository, and stopped at the edge of its context. What the change touches beyond that edge — a shared schema, a config value three services rely on, an API contract a downstream team depends on, an implicit ordering assumption — is exactly what the model could not see and therefore did not consider.

So the reviewer supplies it, before approving, in one or two lines:

Half the value is the declaration itself. The other half is what happens when the reviewer tries to write it and cannot — because not being able to state the blast radius is precisely the signal that this change is not understood well enough to approve, no matter how clean the diff looks. The declaration is a comprehension test disguised as documentation.

Practice 3: Right-Size the Review to the Blast Radius

Not every change earns the same scrutiny, and pretending otherwise just guarantees the budget runs out before the dangerous changes arrive. Once the blast radius is declared, it tells you how hard to look.

This is the practice that keeps the other two affordable. If every change demanded full comprehension, teams would abandon the effort within a Sprint and go back to rubber-stamping everything equally. Concentrating the expensive review where a failure is unrecoverable, and allowing trust-approval where it genuinely is not, is what makes the discipline survivable — and it mirrors the split you already draw when you separate the critical portion of a golden set from the rest.

Where Accountability Sits

None of this moves any accountability off the Developers. They are accountable for an Increment that meets the Definition of Done, and that did not change when the typing got automated. Agents are capacity, not members of the Scrum Team — and capacity cannot hold accountability, however much of the work it does.

That is worth saying plainly to a team, because the emotional pull runs the other way. When a model wrote the code, it feels as though the model is somehow answerable for it. It is not. The developer who approved the merge is answerable for it, exactly as they would be for a change they typed themselves. The comprehension flag does not add a burden so much as make an existing one legible: it was always the reviewer's name on that approval.

What to Do Next Sprint

1. Add the three-state comprehension flag to your merge template. Frame it as an experiment with an end date, not a policy.
2. Have the most senior developer select “approved on trust” first, visibly, on a real change.
3. Require a one-line blast-radius declaration on anything touching shared state.
4. Agree the three review tiers as a working agreement, so “approved on trust” is legitimate for contained changes and forbidden for critical ones.