Duplication review

Duplication Review

Reviewing a diff for correctness can be done from the diff alone. Reviewing it for duplication cannot, because the thing it might duplicate is outside the diff. You have to go look.

Scope

Review only what this change adds. Pre-existing duplication is out of scope here; that belongs to duplication-sweep. The question is narrow:

Does this change add another copy of something the repo already has?

Procedure

1. List what the diff adds

Pull out every new function, class, constant, type, and file. Ignore modifications to existing bodies for now. You want the things that did not exist before this change.

2. Search for a prior equivalent of each

Use the same discipline as reuse-first: search by behavior and by distinctive constants, not by name. For each new symbol, record either the existing equivalent with file:line, or "no equivalent found."

Prioritize. A new three-line private helper matters far less than a new exported module. Spend the search budget on things that are exported, generic, or long.

3. Check the diff against itself

Two near-identical blocks inside the same PR is the most common case and the most frequently missed, because reviewers read a diff top to bottom and never compare its halves. Look for blocks that differ only in a literal, a type, or a field name.

4. Check connectivity

Count how many existing internal functions the new code actually calls.

A large diff that calls almost nothing that already existed is a strong signal that the author, human or agent, rebuilt instead of reused. It is not proof on its own, but it is the cheapest tell available, and it is worth stating explicitly in the review even when you found no specific duplicate.

5. Check for reimplemented builtins and existing dependencies

Anything the standard library or an already-installed dependency provides. This is the highest-confidence category of finding, so lead the report with it.

What to report

For each finding:

• file:line in the diff
• The existing equivalent, with its own file:line
• How close it is: exact, near-duplicate, or overlapping
• A concrete recommendation: call the existing one, extend it, or extract a shared one

Rank by payoff. Exact duplicates of exported functions first. Trivial private helpers last, or not at all.

What not to flag

A noisy duplication check gets muted, and then it catches nothing. Hold fire on:

• Test fixtures and setup. Duplication in tests is often correct, because it keeps each test readable in isolation.
• Generated code, migrations, vendored code, lockfiles.
• Deliberate duplication across service or module boundaries, where coupling two bounded contexts would be worse than repeating ten lines.
• Structural similarity with different meaning. Two functions with the same shape that encode different domain rules are not duplicates. Merging them produces a worse abstraction than leaving them alone.

If you cannot tell whether duplication is deliberate, say so and ask. Do not file it as a defect.

Output shape

Open with a one-line verdict: clean, minor, or needs consolidation before merge.

Then the ranked findings.

Then state what you checked and found clean, so the reviewer can see your coverage rather than guessing at it.

Making it stick

A review that only a human runs is a review that gets skipped under deadline. For the mechanical part of this check, wire it into CI so it fails the build instead of relying on discipline. See references/ci-guardrails.md for per-language tooling and thresholds.