How Do You Review PRs in Code You've Never Worked In?

Why Do Most Cross-Team Code Reviews Fail?

Be honest: when you're tagged as a reviewer on a PR that touches an unfamiliar part of the codebase, do you give a genuine review or a rubber-stamp approval? Most developers, when pressed for time and context, default to checking for obvious issues—typos, missing tests, style violations—and approving without understanding the actual impact of the change.

This isn't laziness. It's a context problem. You don't have the mental model needed to assess whether the change is correct, and building that mental model by reading code manually takes more time than you have. The PR author is in another time zone. The documentation is sparse.

Priscila Andre's Comprehend-First method solves this by giving you a fast, structured way to build enough context to review meaningfully.

How Do You Build Context for a PR Review in Minutes?

Invoke the Catch Me Up prompt with these inputs:

1. Role: "I am a PR reviewer with partial context. I know this area of the codebase exists but have never worked in it directly."

2. Exploration modes: Feature (to understand the end-to-end feature being modified) + Trace (to follow the data path the PR changes).

3. Specific question: "Walk me through how this feature works end-to-end and trace the data path this PR is modifying. Show me what's upstream and downstream of the changed code."

4. Output format: "Show me a flow diagram of the data path and a table of affected components."

In 10–15 minutes, you'll have a structured understanding of what the PR is actually changing, what depends on it, and what could break. This is genuine review context, not surface-level familiarity.

What Should You Verify Before Approving?

Once the AI gives you the feature overview and data trace, apply the comprehension gate:

- Can you explain, in plain language, what the PR changes and why?

- Does the PR's approach align with the codebase conventions you discovered?

- Are there upstream or downstream effects the PR author may have missed?

- Do the tests actually cover the modified path, or are they testing adjacent functionality?

Use the Convention exploration mode if you need to check whether the PR follows coding standards. Use History mode if you want to understand whether the area has been recently refactored and whether this PR might conflict with ongoing changes.

If you find a genuine concern, you can raise it with specific context—not a vague "this doesn't look right" but "this change modifies the data path between X and Y, but the test only covers the path from Y to Z." That's the kind of review comment that actually prevents bugs.

How Does This Compare to Just Asking the PR Author?

Asking the PR author is always valid, but it has costs: they may be in a different time zone, busy with other work, or not available for synchronous discussion. Comprehend-First lets you do 80% of the context-building asynchronously with AI, then ask the author only targeted, high-value questions that the code alone can't answer—like "Was there a product reason for this approach vs. the alternative?"

This is also more respectful of the author's time. Instead of asking them to explain the entire feature from scratch, you arrive with a working understanding and ask only about the gaps.

What Should You Do Next?

The next time you're tagged on a PR in unfamiliar code, spend 10 minutes with Catch Me Up before opening the diff. Use Feature + Trace modes to understand the context, then review the actual changes with that mental model. Track how many genuine issues you catch compared to your previous rubber-stamp reviews. Most developers find the difference is dramatic—and their review comments become significantly more valuable to the team.