# How do you review multi-file diffs from Cursor or Claude Code?

> Learn a step-by-step review checklist for auditing multi-file edits generated by agentic coding tools like Cursor, Claude Code, and GitHub Copilot.

- Canonical HTML: [https://unrust.dev/guides/reviewing-cursor-and-claude-code-diffs](https://unrust.dev/guides/reviewing-cursor-and-claude-code-diffs)
- Markdown representation: [https://unrust.dev/guides/reviewing-cursor-and-claude-code-diffs/index.md](https://unrust.dev/guides/reviewing-cursor-and-claude-code-diffs/index.md)

Published: 2026-10-22
Published by Unrust. Scoring and editorial method: https://unrust.dev/help#methodology

## Direct answer

To review a multi-file diff from Cursor, Claude Code, or Copilot safely, inspect the cross-file contract before reading individual lines: verify that every caller and callee agree on boundary values (0, false, null, empty arrays), check that error paths do not silently swallow failures with fallback defaults, and confirm that no unrelated helper or test assertion was weakened to make the build pass.

## Why agentic multi-file diffs require seam-first review

Agentic coding tools can edit a route handler, a service module, a type definition, and a test file in a single turn. Each file in isolation usually compiles cleanly and follows local naming conventions.

The most common defects hide at the seams between those edited files: a helper normalizes an optional parameter with || instead of ??, a catch block returns an empty array that a caller treats as 'no pending records', or a test assertion is relaxed to match buggy output.

- [Open the free code review lab](https://unrust.dev/guides/public-code-review-challenges/index.md)
- [Read the cross-file debugging guide](https://unrust.dev/guides/debugging-across-multiple-files/index.md)


## Read the test diff and type changes before the implementation

Start your review with the test file and shared type signatures. If an agent modified existing test expectations or widened a parameter type to any or unknown, ask whether the change reflects a legitimate requirement update or a shortcut to silence a failing check.

Next, pick one concrete boundary input—such as an explicit false flag, a zero retry budget, or an empty generator—and trace it across every file the diff touched.



## Audit silent fallbacks and partial-failure cleanup

Generated diffs frequently wrap asynchronous calls in try/catch blocks that log a warning and return a benign-looking default. Trace what the caller does with that default: if it commits state or marks a job complete, the fallback just turned a transient outage into silent data loss.

Use Unrust's text diff and boundary explorers to inspect code changes with a concrete counterexample in mind before approving.



## An agentic multi-file diff review table

Use this table when auditing multi-file pull requests or composer diffs generated by Cursor, Claude Code, or Copilot.

### The diff modifies both implementation files and existing unit or integration tests

- **Review decision:** Inspect the test diff first to verify no existing edge-case assertion was weakened or deleted
- **Evidence to verify:** Confirm that new or updated assertions test both the happy path and the rejected/boundary neighbor

### A shared options or payload object is threaded through multiple edited modules

- **Review decision:** Trace falsy and boundary values (false, 0, '', empty iterable) from the entry caller to the leaf consumer
- **Evidence to verify:** Verify that nullish coalescing (??) or explicit undefined checks preserve valid caller-supplied falsy values

### The diff adds try/catch blocks or fallback return values in a helper module

- **Review decision:** Trace how upstream callers branch on the fallback return value
- **Evidence to verify:** Confirm that a caught error cannot be mistaken for a valid empty result or completed operation

## Try the diff review: which multi-file change hides a defect?

An coding agent updates three files to add a dryRun option to a billing sync:
1. types.ts adds dryRun?: boolean.
2. sync.ts normalizes const isDryRun = Boolean(options.dryRun ?? true).
3. cron.ts calls runBillingSync({}) for the nightly production charge run.
What happens during the nightly production run?

- The nightly cron charges customers normally because dryRun was omitted.
- options.dryRun ?? true defaults omitted dryRun to true, silently turning the nightly production cron into a no-op dry run.
- TypeScript rejects runBillingSync({}) because dryRun is required.
- Boolean(true) evaluates to false in JavaScript.

**Reasoning:** Because dryRun?: boolean is optional, existing callers that pass {} rely on the default in sync.ts. Defaulting dryRun to true via ?? true silently disables production work for any caller that omits the flag.

## Practice loop

1. Read the test diff and shared type changes first before reading implementation lines.
2. Pick one omitted or falsy option ({}, { flag: false }, { retries: 0 }) and trace it across every touched file.
3. Check every new catch block or default fallback to verify what the caller does when that fallback value is returned.

## Common questions

### Why do multi-file agent diffs often look clean on a quick skim?

Coding agents generate locally idiomatic syntax and matching variable names across files, which satisfies surface pattern recognition even when two modules disagree on edge-case semantics.

### Which Unrust skill dimensions practice reviewing agent-generated diffs?

Find the Flaw (contract comprehension), AI-Slop Detection, State Debugging, and our multi-file workspace drills all practice isolating plausible defects in existing code.

## Limitations

This checklist covers logical and contract review of multi-file diffs; it does not replace automated test suites, static analysis, or security review. Unrust diagnostic scores are a personal snapshot and do not measure tool productivity.

## Provenance

Original editorial guide by the Unrust team synthesizing code-review research and common cross-file failure modes in AI-assisted workflows.

## Sources

- [Comprehension Strategies and Difficulties in Code Review](https://link.springer.com/journal/10664) — Empirical Software Engineering. Shows that effective reviewers trace execution paths and data contracts across changed callers and callees rather than reading lines in isolation.
- [Expectations, Outcomes, and Challenges of Modern Code Review](https://dl.acm.org/doi/10.1109/ICSE.2013.6606617) — ICSE / ACM Digital Library. Documents how subtle logic and contract defects are missed when reviewers focus only on local surface style.

## Related guides

- [How do you review AI-generated code?](https://unrust.dev/guides/reviewing-ai-generated-code/index.md): Review a JavaScript bug that mishandles zero, compare the corrected code and boundary tests, and learn how to verify AI-generated changes against a contract.
- [How do you trace a bug across multiple files without an IDE?](https://unrust.dev/guides/debugging-across-multiple-files/index.md): Learn a structured method for tracing contracts, data shapes, and state mutations across module boundaries when a bug spans multiple files.
- [Why does a TypeScript default erase an explicit false?](https://unrust.dev/guides/typescript-explicit-false-challenge/index.md): Test a boolean default with false and an omitted field, then use nullish coalescing to preserve an explicit user choice.

Next step: [Take the free diagnostic](https://unrust.dev/diagnostic/index.md)
