Who reviews the AI suggestion the reviewer accepted mid-review

An engineering manager at a devtools company noticed a small hole in their process that turned out to matter. Their review tooling had gained the ability to suggest changes inline, and reviewers had started accepting those suggestions directly, committing them to the branch as part of the review. The author saw the suggestion land and assumed the reviewer had judged it. The reviewer saw the tool propose it and assumed the tool had judged it. The suggestion became code that no human had actually evaluated with the attention a change deserves. It was reviewed by a process where each party thought the other was doing the checking.

A change entered the code that skipped review

Code review exists to put a second set of eyes on a change before it ships. The author writes, someone else checks, and the friction between them catches mistakes. That model depends on there being two distinct roles, the person who proposes and the person who scrutinizes.

Inline AI suggestions collapse those roles in a way that is easy to miss. When the reviewer accepts a tool-suggested fix directly into the branch, that fix has an author, the tool, and it has an approver, also effectively the tool, since the reviewer often accepts it on trust in the same motion. The author of the original change did not review it, because it appeared during their review. The reviewer did not review it the way they review the author’s code, because they were the one adding it. The change slips through the exact gap the two-person model was built to prevent, and it does so wearing the reviewer’s name, which makes everyone downstream trust it more.

The individual suggestions are usually small, which is why this feels harmless. But small unreviewed changes are how subtle bugs enter, and the pattern scales quietly. Over a quarter, a real amount of code enters the branch through the reviewer’s accept button, checked by no one in the way the team believes everything is checked.

Route the reviewer’s changes through review too

The lesson is that a change is a change, no matter who or what proposed it or at what stage, and every change deserves the review the team promises. A fix the reviewer accepts inline should not get a lighter pass than a line the author wrote.

What teams do to close the review-of-the-review gap.

Treat reviewer-accepted suggestions as new changes that the author, or a second reviewer, still looks at, rather than as free additions.
Keep the author in the loop when the reviewer changes their code, so the person who owns it understands what happened to it.
Make inline-accepted changes visible in the history as their own thing, not folded silently into the review.
Hold the same standard for a suggested one-liner as for an authored one, since the size does not tell you it is safe.
Decide who is accountable for a reviewer-added change, so it has an owner like every other line.

The tool suggesting fixes during review is genuinely useful. The gap is not the suggestion, it is that accepting it can bypass the very check the review was supposed to be.

How we think about it at Density Labs

The review-of-the-review gap is one of those problems that does not show up in any single incident and shows up in aggregate. No one change that entered through an accepted suggestion was the disaster. The disaster, when it comes, is a bug in a line that everyone assumed had been reviewed and no one actually had, because the roles that review depends on had quietly merged into one.

When we help teams design an AI-assisted review process, we make sure the roles stay distinct. Whoever proposes a change, human or tool, someone else scrutinizes it. That is the whole point of review, and it is worth protecting when the tools start blurring who is proposing and who is checking.

Every change needs a reviewer who is not also its author. That does not stop being true because the change came from an accept button.