Forem: Ryan DesJardins

Blame-aware code review — why your AI reviewer should only flag what you changed

Ryan DesJardins — Sat, 11 Apr 2026 19:24:58 +0000

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.

14 patterns AI code generators get wrong — and how to catch them

Ryan DesJardins — Mon, 06 Apr 2026 19:34:27 +0000

AI coding tools ship code fast. That's the point. But fast means they also
introduce a specific class of bugs that are easy to miss in review — not
because they're hidden, but because they look correct at a glance.

After building an automated reviewer specifically for AI-generated code, I've cataloged 14 recurring patterns. Here's what they look like and how to spot them. Although an automated review agent can be helpful, manually spotting these 14 things can also benefit your work when using coding agents.

The core problem

AI code generators optimize for producing code that looks complete and
compiles. They're not optimizing for runtime correctness, security, or the
subtle behavioral contracts your codebase depends on. The patterns below
all share the same root: plausible-looking code that silently fails, skips
important work, or creates vulnerabilities that generic linters don't catch.

1. Fake error handling

The most common one. The try/catch exists, the error variable is named, and absolutely nothing useful happens with it.

// Looks handled. Isn't.
try {
  await processPayment(order);
} catch (error) {
  console.log('Payment failed:', error);
  return { success: true }; // ← the real problem
}

The tell: the catch block logs but doesn't change the outcome. The function returns success regardless. This pattern is everywhere in AI-generated code because the model is completing a "handle errors" pattern without reasoning about what handling should actually do.

2. Hallucinated imports

AI models confidently import packages that don't exist, functions that were renamed, or methods from the wrong module.

import { sanitizeHtml } from 'express-validator'; // doesn't exist there
import { parseJWT } from 'jsonwebtoken'; // it's jwt.verify(), not parseJWT
import { createLogger } from '@company/utils'; // your internal package, maybe

These fail at runtime, not compile time (unless you have strict module checking). They're easy to miss in review because the import looks reasonable.

3. Placeholder stubs that look complete

async function sendNotification(userId: string, message: string) {
  // TODO: integrate with notification service
  console.log(`Notification queued for ${userId}: ${message}`);
  return { queued: true };
}

The function signature is real. It returns a typed response. It logs
something. It will pass a basic smoke test. The actual work is never done.
AI generators do this when they're implementing something they don't have
enough context to complete — they produce scaffolding that looks finished.

4. Silent async failures

// somewhere in initialization
loadUserPreferences(userId); // no await, no .catch()

// result: preferences silently fail to load, app continues with defaults,
// user wonders why their settings aren't saving

Unhandled promise rejections are a top-tier AI slop pattern. The model adds the function call, forgets the await, and the error disappears into the void.

5. An optimistic state that never rolls back

// Update UI immediately
setCartItems(prev => [...prev, newItem]);

// Then try the server
try {
  await api.addToCart(newItem);
} catch {
  // ← nothing here
  // cart shows item that wasn't actually saved
}

AI models learn to write optimistic updates from examples that include
rollback logic — but they frequently omit the rollback when generating new
code.

6. Missing auth checks in route handlers

export async function PUT(request: Request, { params }: { params: { id: string } }) {
  const body = await request.json();

  // ← where is the auth check?
  // ← where is the ownership check?

  await db.update(posts).set(body).where(eq(posts.id, params.id));
  return Response.json({ success: true });
}

This is IDOR (Insecure Direct Object Reference) — any authenticated user can update any post. AI models write the happy path correctly but skip the
authorization layer because it requires knowledge of your specific auth
system that isn't in the immediate context.

7. Hardcoded ARIA states

// This button controls a dropdown
<button aria-expanded="false" aria-controls="menu">
  Options
</button>

The ARIA attribute is there. The accessibility auditor won't flag it as
missing. But aria-expanded is hardcoded to false and never updates when the menu opens. Screen reader users get incorrect state information on every interaction.

AI models add ARIA attributes to pass static analysis without connecting
them to the component state.

8. Array index as React key

{items.map((item, index) => (
  <ListItem key={index} item={item} />  // ← classic
))}

Everyone knows this one, and AI still generates it constantly. It causes
subtle reconciliation bugs when items are reordered or deleted. The fix
(key={item.id}) requires knowing your data shape, which the model doesn't always have.

9. TypeScript escape hatches

const user = response.data as User; // trusts external data unconditionally
const element = document.querySelector('.target') as HTMLInputElement; // assumes
const config = value as unknown as Config; // the double cast — worse

Type assertions instead of type guards. The code compiles, and TypeScript
stops complaining, but the runtime behavior is undefined if the assumption
is wrong. AI models reach for as when the type system resists them, rather than fixing the underlying issue.

10. useEffect with no cleanup

useEffect(() => {
  const subscription = eventEmitter.subscribe(handleEvent);
  // ← no return () => subscription.unsubscribe()
}, []);

Memory leaks and stale closure bugs. The model writes the setup, skips the
teardown. Shows up in event listeners, subscriptions, timers, and WebSocket connections.

11. N+1 query patterns

const users = await db.select().from(usersTable);

// for each user, a separate query — scales as O(n)
const usersWithPosts = await Promise.all(
  users.map(user => 
    db.select().from(postsTable).where(eq(postsTable.userId, user.id))
  )
);

This works correctly in development with a handful of records. In production with thousands of users it's a significant performance problem. AI generates the naive version because it's the direct translation of the requirement.

12. Unbounded list rendering

function UserList({ users }: { users: User[] }) {
  return (
    <ul>
      {users.map(user => <UserItem key={user.id} user={user} />)}
    </ul>
  );
}

No pagination, no virtualization, no limit. Renders fine with test data.
Blocks the main thread with 10,000 records. AI models generate the complete render because truncating the list requires product decisions they don't have context for.

13. Missing loading and error states

function Dashboard() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetchDashboardData().then(setData);
  }, []);

  return <DashboardContent data={data} />;  // null crash on first render
  // no loading state, no error state, no empty state
}

The happy path is complete. The other three states (loading, error, empty)
are absent. This pattern comes up because the model implements what was
asked for without considering the temporal states of the component.

14. Over-broad catch with specific handling

try {
  await stripe.paymentIntents.create(params);
} catch (error) {
  if (error.code === 'card_declined') {
    return { error: 'Your card was declined' };
  }
  // ← every other error silently returns undefined
  // network errors, auth errors, rate limits — all disappear
}

Handles one specific case, drops everything else. The model generates the
case it was asked to handle and stops.

The pattern behind the patterns

All 14 of these share the same root cause: AI models generate code that
satisfies the immediate requirement without reasoning about failure modes,
state transitions, or the implicit contracts of the surrounding system.

The fix isn't to stop using AI code generation — it's to review specifically for these patterns rather than doing a general read-through. They're consistent enough that you can check for them systematically.

I automated this check in a Claude Code plugin
(rad-code-review) that specifically looks for these patterns in diffs before you commit. But even without automation, knowing the list makes manual review significantly faster.

Any patterns I missed? Drop them in the comments — I'm still actively
updating the detection logic.