Code review is one of those tasks that looks passive but drains you fast. You're context-switching between your own work and someone else's mental model, trying to be thorough without being slow. I started using AI as a first-pass review layer a few months ago, and it's changed how I approach the whole process.

Here's exactly how I do it — copy-paste ready.

The Problem With "Just Reading" a PR

When you open a PR cold, you're doing three things at once:

• Building a mental model of what changed and why
• Spotting logic errors, edge cases, and style issues
• Thinking about downstream effects (tests, dependencies, API contracts)

Most of us do all three simultaneously, which means we do all three worse. AI doesn't replace your judgment — but it handles the scaffolding so you can focus on the things only you can catch.

Step 1: Dump the Diff Into Context

Start by copying the raw diff from the PR. Most platforms (GitHub, GitLab) have a "view file" or copy-paste friendly diff view. Grab the relevant files — don't paste everything if the PR is large; focus on the files with real logic changes.

Then open your AI assistant of choice (ChatGPT, Claude, Cursor, etc.) and use this prompt:

You are a senior software engineer doing a thorough code review.

Here is a diff from a pull request:

<paste diff here>

Do the following:
1. Summarize what this code is doing in 3-5 sentences.
2. List any logic errors, missing edge cases, or potential bugs.
3. Flag anything that could cause a regression or break an existing contract.
4. Note any readability or maintainability issues worth raising.

Be direct. Skip praise. If something looks fine, just say so.

The "skip praise" instruction matters more than it sounds. Without it, you get a lot of "Great use of early returns here!" filler before the actual issues.

Step 2: Check for Missing Tests

After the logic review, I run a second pass specifically on test coverage. This is separate on purpose — mixing it into the first prompt usually results in the model being too vague about both.

Given this diff and the summary you just provided, what test cases are missing or underdeveloped?

Consider:
- Happy path
- Edge cases (empty input, null values, boundary conditions)
- Error handling and failure modes
- Any async or concurrency concerns if applicable

List each missing test as a one-liner describing what it should verify.

This gives you a concrete checklist you can paste directly into your review comment as suggestions. Reviewees love it because it's specific, not just "needs more tests."

Step 3: Write Your Opening Review Comment

This is the underrated one. A good opening review comment sets the tone and saves everyone time. I use AI to draft it based on the findings:

• Paste the AI's summary + issues back in
• Ask it to write a 3-4 sentence opening comment that's direct and constructive
• Edit it to sound like you (takes 30 seconds)

Total time for steps 1–3: about 5–7 minutes per PR, vs. 20–30 minutes of unstructured reading.

A Few Things That Actually Matter

Context is everything. The more you tell the model about the codebase conventions, the better the output. I keep a short "codebase context" snippet I prepend to reviews for repos I work in frequently — things like "we use Result types instead of throwing exceptions" or "all API responses are paginated."

Don't skip your own read. AI misses things that require understanding the business logic or team history. Use it to handle the mechanical layer, then do your own read with that scaffolding already in place.

Iterate the prompts. The first time you try these, the output will be 70% useful. After you've tuned your prompts to your stack and team conventions, it's closer to 90%.

The Habit Loop

Once this becomes a habit, you stop dreading large PRs. The cognitive cost of "starting" drops significantly when you know your first move is just pasting a diff and running a prompt.

I do this for my own code too before I open a PR — catching things myself before review has probably saved me more embarrassment than I'd like to admit.

If you want to go deeper on this workflow, I put together a prompt playbook that covers code review, debugging sessions, sprint planning, and a few other high-leverage engineering workflows — you can find it at https://gumroad.com/l/nhltvo.