Skip to main content
Every Merge assessment is designed as a conversation between the candidate and the code. After a candidate submits their review, Merge’s AI responds not with a score, but with a revised pull request — continuing the loop in the same way a real author would push a new commit after reading feedback. This page explains how that process works and why it matters to the signal you collect.

​
What the AI does

After a candidate submits their review comments, Merge’s AI reads each comment and generates a revised pull request. The revision is not a simple “fix everything” pass — it responds to comments with the nuance of a real author: fixing clear bugs, partially addressing style concerns, and sometimes introducing new trade-offs. This means a candidate who leaves vague feedback gets a vague resolution. A candidate who writes precise, actionable comments — specifying what the problem is and what a correct fix looks like — gets a revision that reflects that precision. The AI is calibrated to behave like a developer who understands the intent of the feedback, not a linter that applies rules mechanically.

​
Why revisions matter

The initial review round tells you whether a candidate can read unfamiliar code and identify issues. That’s a necessary signal, but it’s not sufficient for senior roles or teams where iteration quality matters as much as first-pass accuracy. The revision stage is where the most differentiated signal emerges. Candidates who only write good initial comments show one skill; candidates who also catch regressions in the revision, notice newly introduced issues, and update their judgment show the iterative reasoning that senior engineers rely on daily. Real code review doesn’t end when the author pushes a fix. Engineers who can close the loop — who read the revision critically, notice when a fix is incomplete, and know when to approve — are the ones who keep pull request queues moving without letting bad code slip through. The revision loop measures exactly that skill.

​
How revisions are generated

1

Comments are collected

The AI reads all inline comments the candidate submitted in the current review round, including any tags (bug, refactor, security, style) and the specific lines each comment references.
2

A revised diff is generated

The AI generates a new version of the pull request that addresses the feedback in a realistic way. The revision may resolve some comments fully, partially address others, or leave certain concerns open — just as a real author might.
3

The revision appears in the interface

The updated diff loads in the candidate’s interface within seconds. The candidate sees the new changes inline and can begin reviewing immediately.
4

The loop continues

Multiple revision rounds are possible within a single session. The loop runs until the candidate approves the PR or the session timer expires.

​
What revisions are not

Revisions are not graded pass/fail. The quality of the revision is an input to the session, not an output. Merge scores the candidate’s response to the revision — not the revision itself. A weak revision gives candidates an opportunity to demonstrate that they can catch what slipped through; a strong revision gives candidates an opportunity to demonstrate appropriate confidence when the code is genuinely ready to ship.
Candidates should review each revision as critically as the first. Re-approving code without reading the diff is itself a signal — one that experienced reviewers on your team will recognize when they see the session replay.