Here's a problem that sounds minor but adds up fast: you open a pull request, run an AI code reviewer, and get 40 findings. Twelve of them are in files you touched. The other 28 are in code that was there before you arrived.
Now you have a decision to make about 28 issues that aren't your fault,
weren't introduced by your change, and probably can't be fixed in this PR
without scope creep. You either ignore them (and train yourself to ignore
the reviewer), fix them (and bloat the PR), or spend time triaging which are real and which aren't.
This is the blame-aware scoping problem. Here's why it matters more for
AI-assisted development versus traditional development — and how to think about solving it.
Why this is worse with AI-generated code
In traditional development, a code reviewer skimming a 200-line diff can
mentally filter pre-existing issues. "That function was already there, not
my problem right now." The human reviewer applies an implicit blame context.
AI reviewers don't do this by default. They scan whatever they're given and report everything. If you ask an AI to "review this file," it reviews the whole file — including the 300 lines your change didn't touch.
AI-assisted development makes this worse in a second way: you're often
making changes to existing files. You add a function, refactor a hook, fix
a bug in a route handler. The AI that helped you write the change didn't
introduce the issues in the surrounding code, but a naive reviewer will flag them anyway.
The result: reviewer fatigue, noisy reports, and a tendency to stop taking findings seriously.
What blame-aware scoping actually means
The concept comes from git blame — the ability to attribute every line of code to the commit that last modified it.
Blame-aware code review means:
- Scope to the diff — only look at lines that changed in this PR or commit
- Apply blame context — for each changed line, know who introduced it and when
- Extend to dependency chains — if you changed a function, flag issues in functions it calls that your change might affect, but not unrelated code
Step 3 is the nuanced part. Purely diff-scoped review misses cases where
your change interacts with pre-existing problems. If you call an existing
function that has a security issue, and your new code passes untrusted data to it, that's your problem, even though you didn't write the vulnerable function.
A good blame-aware reviewer distinguishes between:
- Issues in lines you wrote (always flag)
- Issues in lines your change depends on (flag with context)
- Issues in lines your change didn't touch and doesn't interact with (skip)
The incremental review case
There's a related problem: reviewing work that spans multiple commits.
Say you've been working on a feature for three days across eight commits.
You want a review of the whole feature before merging — but not a review of the entire codebase.
git diff main...HEAD gives you the cumulative diff. A blame-aware reviewer
can scope to that diff and treat it as a coherent unit, flagging issues
introduced anywhere in the feature branch without surfacing pre-existing
issues from main.
This is the --since flag pattern: review everything since a specific commit or branch point, not the entire repo, and not just the last commit.
Why this matters specifically for AI slop detection
AI code review has a specific job that general code review doesn't: catching the patterns that AI code generators introduce. Hallucinated imports, fake error handling, missing auth checks, hardcoded ARIA states.
These patterns are meaningfully more likely to appear in recently written
code than in code that's been in production for six months. A diff-scoped reviewer that focuses on new code will find AI slop at a much higher
signal-to-noise ratio than a full-repo scan.
If you're doing full-repo scans looking for AI slop, you're spending most
of your time on code that wasn't AI-generated in the first place.
Practical implementation
Whether you're building this into an automated reviewer or doing manual review, the workflow looks like:
# Get the diff you actually want to review
git diff HEAD~1 # last commit only
git diff main...HEAD # entire feature branch
git diff abc123..HEAD # since a specific commit
# For each changed file, get blame context
git blame -L <start>,<end> <file> # blame specific line range
The key discipline: start with the diff, not the file. If your reviewer takes a file as input, it will review the whole file. If it takes a diff as input, it's forced to scope correctly.
For automated review, you want the reviewer to:
- Parse the diff to get changed line ranges per file
- Review only those ranges (plus direct dependencies)
- Explicitly ignore unchanged lines in changed files
Step 3 is where most implementations fall short. Changed files still contain a lot of unchanged code, and reviewers who scan the full file content will surface issues from the unchanged portions.
The severity calibration problem
Even with correct blame scoping, there's a secondary issue: severity
calibration changes based on context.
A hardcoded credential in a utility function that was last touched two years ago is a serious issue, regardless of blame — but it's not your PR's
responsibility to fix right now. A hardcoded credential in a line you just
wrote is a blocker.
Good blame-aware review separates findings into:
- Your responsibility — in lines you wrote or that you directly depend on
- Inherited issues — pre-existing, should be tracked but not blocking your PR
- Incidental findings — unrelated, out of scope entirely
Surfacing all three without distinguishing them trains reviewers to ignore
everything.
What I built around this
I implemented blame-aware scoping in a Claude Code plugin
(rad-code-review) after getting frustrated with full-repo reviews that were too noisy to act on.
The default mode is diff-scoped with dependency chain detection. You can
override to full-scan when you actually want that (--full-scan), run
incremental reviews with --since <commit>, and set strictness level for
pre-release audits.
The signal-to-noise improvement from scoping correctly is significant. A
full-repo scan of a mature codebase produces dozens of findings. The same
reviewer scoped to a three-file diff produces three or four — all of which
are things you actually introduced and can actually fix right now.
The underlying principle: a reviewer who produces too much noise gets
ignored. Blame-aware scoping isn't a nice-to-have — it's what separates a
reviewer you use from one you turn off.
Top comments (0)