The way to conduct a code review on a mixed-ownership PR is to split the diff first, then apply different depths of scrutiny to each half. Files you own get a full pass: correctness, contract, security, and performance. Files you don't own get a focused pass for interface breaks and cross-cutting risks. Done carefully, the whole review takes one to three hours depending on PR size.
Most code review guidance treats every file in a diff as equal. In practice, a PR that touches your authentication middleware, a payments service you've never deployed, and a logging utility owned by a third team is three different reviews happening at once. Getting the depth wrong in either direction costs you: too shallow on your own files and you ship bugs you should have caught; too deep on unowned files and you block a PR with architectural opinions nobody asked for.
Here's what you need before you start, and then the five steps to work through.
What You Need Before You Start
Before opening the diff, get a clear picture of which files sit inside your ownership and which don't. Pull up the PR description, the linked ticket, and any architecture diagram or README that maps ownership boundaries. If your team uses a CODEOWNERS file, check it now. GitHub and GitLab both support CODEOWNERS, and it tells you exactly which directories trigger your mandatory review.
Note the PR's stated scope. A PR described as a "small refactor" that touches authentication middleware and a payment service is not a small refactor. That mismatch is important information before you read a single line.
For non-trivial PRs, have a local copy you can run. Reading a diff without being able to reproduce the behaviour is the single biggest source of missed bugs.
1. Split the Diff Into Owned and Unowned Files
Separate every changed file into two lists before you read any logic. In GitHub, the file tree on the left of the diff view lets you jump file by file. In GitLab, use the Changes tab. Work the list top to bottom and label each file, either mentally or in a scratch note.
Owned files get your full scrutiny: correctness, edge cases, performance, security, and whether the change fits the module's existing contract. Unowned files get a lighter pass: obvious logic errors, security anti-patterns that cross your stack (SQL injection, unsafe deserialization, missing auth guards), and anything that breaks a contract your owned code depends on.
This split is the core answer to broad how-to-conduct-code-review questions: match the depth of your review to your depth of knowledge of that code, and be explicit about which mode you're in. When this step is done, you'll have two annotated lists and a rough sense of where the review will cost the most time.
2. Review Owned Files With Full Authority
Owned files are your responsibility. Treat every line as something you could be asked to debug at 2am.
Check correctness first: does the logic do what the ticket asks? Then check the contract: does the public interface, API response shape, or data model change in a way that callers outside this PR haven't been updated to handle?
Security gets its own pass. For backend files, look for missing input validation, privilege-escalation paths, and secrets committed to source. For frontend files, look for dangerously-set HTML, missing CSRF handling, and exposed environment variables. React, Vue, Svelte, and Angular each have stack-specific patterns here, so your checklist should reflect the framework you're working in. The security issues junior developers most often miss in pull requests are worth having in mind as a baseline.
Performance is the third pass, not the first. Flag a performance issue only when you can name a concrete cost: an N+1 query, a synchronous operation on the main thread, or a missing database index on a column that will reach millions of rows. Vague performance notes add noise.
When you leave a comment on an owned file, make it a request with a reason. "This will throw a null reference when the user has no billing address, which happens for trial accounts" is actionable. "I'd do this differently" is not. For more on writing comments that actually move a review forward, how to give useful code review feedback without being vague or harsh covers the pattern in detail.
This pass is complete when every changed function in your owned files has a status: approved, approved with a minor nit, or blocking issue.
3. Review Unowned Files as a Specialist Visitor
For files outside your ownership, your job is narrower: catch what would hurt the parts of the system you do own, and flag anything dangerous enough to warrant the owning team's attention.
Focus on interfaces, not implementations. If a service you call changes its return type, adds a required parameter, or silently swallows an error, that matters to you regardless of how the internal logic works. Cross-cutting concerns are always your business. Authentication, logging, rate limiting, and error propagation touch every part of a system. A missing auth check in a route handler the payments team owns is still a problem you should catch.
Phrase comments on unowned files differently. "I'm not the owner here, but this endpoint no longer returns the status field my component reads, which will break the dashboard" is useful. Architectural rewrites of someone else's module are outside your scope.
AI tools can generate review comments on a diff, but they review with no knowledge of your system's ownership model, runtime behaviour, or history. They catch syntactic issues and common security patterns reasonably well. They miss business-logic bugs, context-dependent edge cases, and anything that requires knowing what the code looked like three months ago. Use them as a supplement on unowned files where your context is already limited, not as a replacement for the passes above.
This step is done when every unowned file has either a clear "no concerns from my side" status or a specific, scoped comment.
4. Write the Summary Comment
A summary comment tells the author, at a glance, what you found, how serious it is, and what you need from them before approving.
Structure it in three parts: your approval status (approved, approved with nits, or changes requested), a one-sentence scope note naming which parts of the PR you reviewed with full ownership-level scrutiny versus a lighter pass, and a numbered list of blocking issues if any exist.
The scope note protects everyone. "I reviewed the cart service files in depth and gave the analytics pipeline a lighter read for interface changes" tells the author and any future reader exactly what your review covers. Avoid vague summaries like "looks good overall". They give the author no signal and give you no record. If there are no issues, say: "No blocking issues. Reviewed cart/ thoroughly and analytics/ for interface compatibility only."
A scoped summary comment is one of the highest-value habits a reviewer can build. It takes two minutes and makes partial reviews auditable.
5. Build the Habit With Deliberate Practice
The gap between knowing how to conduct a code review and actually catching the bugs that matter comes down to pattern recognition. That only sharpens through repetition on real code.
Reading your own team's PRs builds familiarity with one codebase but gives you a narrow sample of bug types. Reviewing unfamiliar code, under graded conditions, trains the instincts that carry across contexts. If you're working toward a senior or lead role, what separates a senior developer's code review from a junior's is worth reading alongside the practice itself.
Goodcatch is built for this kind of deliberate practice. It presents real pull requests in stack-specific tracks, React, Vue, Svelte, Angular, Laravel, Django, Rails, Node, Spring Boot, ASP.NET Core, Next.js, and others, grades you on what you caught and what you missed, and tracks weak spots over time as you progress from junior to lead difficulty tiers. You can try it in-browser with no account required.
If you're early in building this skill, start with the free tier (three graded reviews) on the stack you work in daily. The feedback on what you missed is where most of the learning happens. If you're preparing for a senior or lead role, the weak-spot analytics in the unlimited plan ($19/month, $45 for three months, or $144/year) show you which categories you consistently miss across reviews.
Goodcatch is the wrong tool if you need live team collaboration features or PR workflow integrations. It's a practice environment, not a replacement for your team's review process.
The goal is to reach the point where the owned/unowned split happens automatically, your security pass has a personal checklist built from past misses, and your summary comments are precise enough that authors rarely need to ask for clarification.
Frequently asked questions
What are the best practices for conducting code reviews?
The most consistent best practices are: match review depth to your knowledge of the code, check correctness before style, give every comment a reason, and write a scoped summary so the author knows exactly what you covered. A habit of reviewing unfamiliar code under structured conditions, rather than only your own team's PRs, builds the pattern recognition that makes those practices automatic.
Can ChatGPT do a code review?
ChatGPT can flag common security anti-patterns, style inconsistencies, and straightforward logic errors in a diff. It has no knowledge of your system's history, ownership model, or runtime behaviour, so it misses business-logic bugs and context-dependent edge cases. It's a reasonable supplement for a quick first pass on unowned files, not a substitute for a reviewer who knows the codebase.
What is a good prompt for a code review?
A useful prompt names the language and framework, specifies what kind of issues to prioritise (security, correctness, interface changes), and provides the relevant context the model lacks by default, such as what the function is supposed to do and what calls it. Even a well-structured prompt won't close the gap on business-logic bugs, so treat the output as a starting point rather than a verdict.
Start your first graded code review on Goodcatch, no account required.
Sources
- GitHub Docs: About code owners checked
- GitLab Docs: Code Owners checked