What is code review? The process, types and what to check

Code review is the practice of having someone other than the author read a code change before it becomes part of the codebase. Teams do it to catch defects before users hit them, to spread knowledge of the code, and to keep the codebase consistent.

Today it's usually done in a review tool. On GitHub, that's a pull request: the author proposes a change, a teammate reads it and leaves comments, and the change merges once it's approved.

What is code review?

Google's engineering practices guide defines it in one sentence: "A code review is a process where someone other than the author(s) of a piece of code examines that code." Google says it uses review "to maintain the quality of our code and products" (Google's code review guide).

Peer code review means the same thing. The word "peer" stresses who does the reading, a fellow developer.

The practice used to be much heavier. In 1976, a paper by M.E. Fagan in IBM Systems Journal formalized code inspections, meetings where authors and reviewers sat in the same room and went through the code to find defects. Most organizations have since moved to something lighter, which researchers call modern code review. A Google case study describes it as informal, tool-based, asynchronous and focused on individual code changes (Sadowski et al., ICSE SEIP 2018).

On GitHub, the tool is the pull request, and GitLab calls the same thing a merge request.

Why teams do code review

Finding bugs is the main reason developers give for code review. It isn't the main thing review produces, though.

Take a real pull request. In July 2026, a contributor opened Kubernetes PR #141030 to speed up a check in the Kubernetes scheduler. Within ten minutes, the first review comment pointed out that the new check still took longer the more pods a group had. The author ran the reviewer's performance tests, fixed the code and added benchmark results to the description. A second reviewer objected that the change leaked gang-scheduling details into the scheduler's core, outside the plugin meant to own them. They settled that in a conversation off GitHub, and the author posted the decision in the thread. On October 12, 2026, the PR was still open after 198 review comments.

Those two threads, about performance and design, shaped the PR. Most of the other comments ask for simpler or clearer code, such as a missing comment, a misleading name or a field nothing reads, and several of them are labeled "Nit". Some catch real bugs, such as a cycle in the group hierarchy that could leave readiness counts permanently wrong. That mix is typical, and two well-known studies explain why.

Alberto Bacchelli and Christian Bird observed, interviewed and surveyed developers and managers at Microsoft and hand-classified hundreds of review comments. They found that "while finding defects remains the main motivation for review, reviews are less about defects than expected and instead provide additional benefits such as knowledge transfer, increased team awareness, and creation of alternative solutions to problems" (Bacchelli and Bird, ICSE 2013).

Their numbers show the gap. Finding defects was the top reason the 873 programmers they surveyed gave for reviewing, and 44% ranked it first. Yet only 14% of the 570 comments they sorted were about defects, mostly small logic slips such as a wrong condition. Code improvements made up 29%, and the second most common kind of comment was a reviewer trying to understand the change. Developers said the hardest part of reviewing was working out why a change was made.

Finding defects was the top reason to review, yet only 14% of the comments were about defects.

Google's case study, built on 12 interviews, a survey with 44 responses and review logs for about 9 million changes, reached a similar view. Code review lets developers "teach each other about the codebase, maintain the integrity of their teams' codebases, and build, establish, and evolve norms that ensure readability and consistency of the codebase." Developers there also reported they were happy with the requirement to review code.

Code review does three jobs.

Catching defects

A second reader sees what the author can't: the edge case nobody tested, the error that gets swallowed, the query that runs once per row. Finding these before merge means no user hits them and nobody has to roll back a deploy.

Sharing knowledge

Every reviewed change has been read by at least two people. Reviewers learn parts of the system they don't usually touch, and authors pick up conventions and history they didn't know. When someone leaves or goes on vacation, the code they wrote isn't a mystery to everyone else.

Keeping code consistent

A team's style guide, naming habits and architecture rules only matter if someone applies them to real changes. Review is where that happens, including for the unwritten rules that never made it into a linter.

The code review process, step by step

Tools use different names (a pull request on GitHub, a merge request on GitLab, a change on Gerrit), but the loop is the same.

1. The author makes a small, focused change. One fix or one slice of a feature, with tests, on its own branch.

2. The author opens a pull request and describes it. Say what changed, why, how it was tested, and where the reviewer should start. If it isn't ready for review yet, open it as a draft.

3. Automated checks run. CI builds the code and runs the tests and linters. Some teams also have an AI reviewer comment at this point. Branch protection can require status checks to pass before anything merges.

4. The author picks reviewers. Google's advice is to ask the person "who will be able to give you the most thorough and correct review," which "usually means the owner(s) of the code." Different people can review different parts of one change.

5. The reviewer reads the change. Start with the description and decide whether the change makes sense at all. Then read the main part of the change, then the rest in a sensible order. Send design problems right away, before reviewing the details, because a design change can make the rest of the review moot. Reading the tests first sometimes shows what the change is meant to do (Google's guide to reading a change).

6. The reviewer submits a review. On GitHub, a review ends in one of three decisions: Comment (feedback "without explicitly approving or requesting changes"), Approve (the change is ready to merge) or Request changes (feedback the author should address before merging). Reviewers can also comment on specific lines and suggest exact code.

7. The author responds. Reply to each comment, push fixes, and ask for another look. Repeat until the reviewer approves. GitHub can be set to dismiss an approval when new commits change the diff, which forces a fresh look at the new code.

8. The change merges. Once the pull request has the approvals and passing checks the branch requires, it merges. GitHub lets admins require a set number of approving reviews before anything merges into a protected branch.

Most changes don't go around the loop many times. In Google's 2018 study, more than 80% of changes needed at most one round of fixes.

Types of code review

Pull request review, the asynchronous, tool-based kind described above, isn't the only way to review code.

Pair programming

Two developers work on the same code at the same time, one typing and one reading along. Google counts this as review: "If you pair-programmed a piece of code with somebody who was qualified to do a good code review on it, then that code is considered reviewed." The cost is two people on one task, and a pair can talk itself into the same blind spot.

Over-the-shoulder review

The author walks a reviewer through the change in person or over a screen share. Google's guide allows in-person reviews "where the reviewer asks questions and the developer of the change speaks only when spoken to," which keeps the author from steering the reviewer past problems. If you review this way, write the outcome on the pull request so there's a record.

Formal inspection

This is the 1976 method described earlier. It's thorough, but it's slow and needs everyone in the room at once, which is why most organizations moved to lighter review.

Automated checks

Compilers, tests, linters such as ESLint or Pylint, and static analysis tools catch the same mechanical problems every time, so reviewers don't have to. They're a filter in front of review, not a replacement for it. They can't tell you whether the change is the right one.

AI code review as a first pass

With AI review, a model reads the pull request and leaves comments before a person does. Tools like cubic install as a GitHub app, review each pull request in minutes and leave inline comments on the lines they flag, with a suggested fix. The AI takes the first pass so the human reviewer can spend their time on design and intent, and a person still approves. Our AI code review guide covers what these tools catch and how to measure one.

How to do a code review: what to look for

Google's guide lists what a code review should look at (what to look for in a code review). Each area turns into a question a reviewer can ask:

Google also asks reviewers to read every line they were asked to review, to look at the whole file when the changed lines alone don't tell the story, and to compliment the author on good work. The bar for approval is not perfection. Reviewers should approve once a change "definitely improves the overall code health of the system being worked on, even if the CL isn't perfect" (Google's review standard). A CL, or changelist, is Google's word for a change under review.

Reading closely catches bugs that a quick skim misses. This function is meant to return the most recent n items from a list ordered oldest first:

def latest(items, n):
    """Return the n most recent items. items is ordered oldest first."""
    return items[-n:]

def latest(items, n):
    """Return the n most recent items. items is ordered oldest first."""
    return items[-n:]

def latest(items, n):
    """Return the n most recent items. items is ordered oldest first."""
    return items[-n:]

A review comment might say: "When n is 0, this returns the whole list, because items[-0:] is the same as items[0:]. Should it return an empty list? A test for n = 0 would pin this down."

The fix is one guard clause:

def latest(items, n):
    """Return the n most recent items. items is ordered oldest first."""
    if n <= 0:
        return []
    return items[-n:]

def latest(items, n):
    """Return the n most recent items. items is ordered oldest first."""
    if n <= 0:
        return []
    return items[-n:]

def latest(items, n):
    """Return the n most recent items. items is ordered oldest first."""
    if n <= 0:
        return []
    return items[-n:]

How big a change should be

Small changes get better reviews. Google's guide says "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large, but it's up to the judgment of your reviewer," and lets reviewers reject a change for being too large (Google on small changes). Its reasons: small changes are reviewed more quickly and more thoroughly, are less likely to introduce bugs, and are easier to merge and to roll back.

In practice, Google's changes were smaller still. In the case study's data, about 9 million changes from 2014 to 2016, the median change modified 24 lines, over 35% of changes touched a single file and about 90% touched fewer than 10 files.

Size also affects what reviewers find. A Microsoft Research study of 1.5 million review comments from five projects found that "the more files that are in a change, the lower the proportion of comments in the code review that will be of value to the author of the change" (Bosu, Greiler and Bird, MSR 2015).

To keep changes small, Google's guide suggests:

• Stack changes. Send one small change for review, then start the next one on top of it.

• Split by files that need different reviewers.

• Split by layer or by feature. Land a shared stub between layers first, or build one thin, full-stack feature slice at a time.

• Separate refactoring from behavior changes. "It's usually best to do refactorings in a separate CL from feature changes or bug fixes."

• Land test changes first when they stand on their own.

How fast reviews should happen

Google's guide sets a ceiling: "One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning)." If you're in the middle of focused work, finish it first. Otherwise, review shortly after the request arrives (Google on review speed).

What counts is response time. Google says "it's even more important for the individual responses to come quickly than it is for the whole process to happen rapidly," and that a typical change "should get multiple rounds of review (if needed) within a single day."

Google's own data shows what that looks like. In the case study, the median wait for first feedback was under an hour for small changes and about 5 hours for very large ones, and the median for the whole review was under 4 hours.

To find where your own reviews stall, measure the loop with three numbers: time to first review, time to merge and review depth. Watch the slow tail, not the median. Meta found that the longer engineers' slowest 25% of reviews took, the less satisfied they were, so it made that 75th-percentile time in review its main target. It also tracked "Eyeball Time", how long reviewers spent looking at a diff, so faster reviews wouldn't turn into rubber stamps. Review depth guards against the same thing: in a 2014 study of Qt, VTK and ITK, the researchers' models estimated up to five more post-release defects in components with many changes that were self-approved, approved without discussion, or approved faster than 200 lines an hour. Our guide to automated code review has a gh command that pulls the timestamps for the first two numbers.

The review loop, and where each metric starts and stops.

When the remaining comments are minor or optional and you trust the author to handle them, approve now instead of holding the change for another round. Google calls this "LGTM with comments" and recommends it especially when author and reviewer are in different time zones, where one more round can cost the author a whole day.

How to write review comments

Google's guidance fits in four sentences: "Be kind. Explain your reasoning. Balance giving explicit directions with just pointing out problems and letting the developer decide. Encourage developers to simplify code or add code comments instead of just explaining the complexity to you." Comment on the code, never on the person (Google on writing review comments).

Compare two comments on the same problem. "Why would you write it like this?" puts the author on the defensive and doesn't say what's wrong. A review comment might say instead: "This runs one query per order inside the loop, so a customer with 500 orders means 500 queries. Could we load them in one query before the loop?"

Label how much each comment matters. Google warns that "without comment labels, authors may interpret all comments as mandatory," and suggests prefixes such as "Nit:" for minor points, "Optional:" or "Consider:" for ideas that aren't required, and "FYI:" for things to think about later.

The late comments on the Kubernetes pull request above use these labels, so the author can tell polish from problems at a glance. For teams that treat every comment as blocking by default, Conventional Comments adds decorations such as "(non-blocking)".

How AI is changing code review

This blog belongs to cubic (cubic.dev), an AI code review tool, so weigh this section accordingly.

AI reviewers take the first pass

In 2013, Bacchelli and Bird suggested handing tools the code-improvement comments and small defects that made up much of what reviewers wrote, so people could look for deeper problems. AI reviewers now take a large share of that work. On a team that uses one, the first comments on a new pull request often come from a model that has read the diff and the code around it. It might flag a caller the change breaks, or a team rule the code ignores. Many also summarize what the change does, which helps with the part of reviewing people find hardest, though only the author can say why the change exists.

In Atlassian's study of its own LLM reviewer, a paper at ICSE 2026, the AI's comments led to a code change 38.70% of the time, against 44.45% for comments written by people, and median PR cycle time fell 30.8%. Faros AI, which sells engineering analytics, says many companies in its 2026 data run AI review on 50 to 80% of pull requests. Teams that use it heavily see faster first reviews and lower change failure rates, though Faros calls the findings correlational.

Coding agents write more of the code, so review becomes the bottleneck

At Google, most new code now comes from AI. In April 2026, Google CEO Sundar Pichai wrote that "75% of all new code at Google is now AI-generated and approved by engineers, up from 50% last fall." Approval by engineers is code review.

Agents made code cheap to write, and the cost moved to reading it. OpenAI said in July 2026 that its weekly PR volume had more than doubled since late 2025, and that code review can quickly become the bottleneck. In Faros AI's 2025 data from more than 10,000 developers, teams with high AI adoption merged 98% more pull requests, while PR review time rose 91%. Its 2026 report, covering 22,000 developers, found average pull request size up 71.8% and a 76.3% rise in pull requests merged without any review.

AI-written code still needs review

AI-written code has bugs like any other code. Bug Bench, our public benchmark, counts a bug when a developer upvotes a cubic review finding on AI-written code or an AI coding agent addresses it. In its current ranking, all 7 ranked models have counted bugs, with relative bug rates from 0.65 to 1.50 (1.00 is the average rate across all AI-attributed lines, and lower is better). The data is observational: teams choose their models, so each rate reflects the code a model was used for as well as the model.

When an agent wrote the change, the review may be the first time a person reads every line. Give it the same review as any other change, and confirm a few things that are easy to miss in generated code: every function, package and config key it uses exists, error paths are handled, and the code follows your team's conventions rather than generic ones. Our guide to reviewing AI-generated code covers what to check when an agent wrote the diff.

People move to intent and design

With a machine on the first pass, human review narrows to what the research says mattered all along. Google's guide puts design first, including whether the change belongs in your codebase or in a library, and whether now is a good time to add it. Bacchelli and Bird found that understanding a change is the hardest part of reviewing, and that understanding has to end up in your team, not in a tool. In the Kubernetes PR above, whose description says AI was used to write it, the comments that changed its course were about how the scheduler holds up at scale and which plugin should own which state.

Someone besides the author still has to understand each change, and that matters more when the author is an agent. It's the reason Google adopted code review in the first place.

The honest limits

• AI reviewers miss things and get things wrong. On Martian's Code Review Bench, which scores review bots on real open-source pull requests, the top F1 in the last-month view was 64.0% when we checked on October 10, 2026. F1 balances how many real issues a reviewer catches against how many of its comments are wrong. The #1 tool there is cubic, and even #1 leaves misses and misfires. The board moves daily.

• Noise costs time and trust. In a 2024 study at Beko, developers resolved 73.8% of an LLM reviewer's comments, yet average PR closure time rose from 5 hours 52 minutes to 8 hours 20 minutes. When Google built ML-suggested fixes for review comments, it tuned them so about half were correct, because wrong suggestions cost developers time and trust. Even so, by 2024 its authors were addressing 7.5% of all reviewer comments by applying one.

• They only know what they're given. If a promise made to a customer or the reason a field has to stay isn't in the code, the pull request or a written rule, the model can't weigh it.

• Someone has to own the merge. OpenAI calls Codex Code Review an additional reviewer and leaves hard enforcement to tests, branch protections and required approvals. Some AI reviewers can approve pull requests. GitHub Copilot and cubic ship with approvals off, and Greptile and cubic recommend auto-approving only low-risk changes.

To see how AI reviewers work and what they catch, read our AI code review guide. To compare tools, our ranked list of AI code review tools orders 15 of them by Martian's data.

More on code review

Each of these goes deeper on one part of code review:

• The code review checklist: checks for correctness, tests, security, performance, readability and AI-written code, plus a pull request template you can copy.

• How to review a pull request on GitHub: a step-by-step guide to reviewing in GitHub's interface, from the diff to submitting your review, plus how CODEOWNERS and required reviews decide what can merge.

• Code review best practices: guidelines for authors and reviewers, from small changes to one-day responses, plus how to review AI-written code.

• What LGTM means: the approval shorthand, how GitHub, GitLab and Gerrit record an approval, and when an LGTM is a rubber stamp.

• Code review glossary: what nit, PTAL, WIP, RFC and the other shorthand in review threads mean.

FAQ

What is meant by code review?

Code review means someone other than the author reads a code change and checks it before it's merged. The reviewer looks for bugs, unclear code and design problems, then approves the change or asks for changes. It's also called peer code review, because the reviewer is usually another developer on the team.

How do you do a code review?

Read the description and decide whether the change makes sense, then read the most important part, then the rest. Check design, behavior, complexity, tests, naming and style, and leave specific comments, with minor ones labeled as nits. Approve once the change improves the code, even if it isn't perfect, and respond within one business day.

Is code review obsolete?

No. In April 2026, Google's CEO said 75% of new code at Google was AI-generated and approved by engineers, so review is how that code gets checked before it ships. AI-written code still has bugs, and every model ranked on Bug Bench had counted bugs found in review.

Can ChatGPT do a code review?

It can review code you paste into a chat, and OpenAI's Codex can review GitHub pull requests when you comment @codex review, flagging only P0 and P1 issues. A chat only sees the code you give it, so it can miss a caller the change breaks or a rule your team wrote down elsewhere. Either way, a person should still approve the change, since deciding whether it's the right change takes context about the product and the team.