What is code review?

What is code review?

Code review is a practice in which people or tools check a proposed code change, usually before it becomes part of the shared codebase. The main goals are to find defects early and to spread knowledge of the code across a team. Review also keeps style and design consistent. It is sometimes called peer review.

Wikipedia defines code review as an activity in which one or more people examine a program's source code. Automated tools can also read a change and comment on it, so the definition used here counts them as reviewers.

On most teams, review happens on a pull request, a request to merge a branch that shows the diff (the lines that changed) and collects comments. GitHub's Octoverse 2025 counted an average of 43.2 million pull requests merged each month, up 23% on the year before. For many teams, the approval on a pull request is the last point where a person reads a change before users receive it.

How does code review work?

On a code host, e.g. GitHub, a pull request moves through review in six steps:

1. The author commits the change to a branch and opens a pull request that describes it.
2. A continuous integration (CI) pipeline builds the branch and runs the test suite.
3. A reviewer reads the diff and leaves comments on the lines that raise questions.
4. The author answers each comment or pushes a commit that addresses it.
5. The reviewer approves the change or asks for more changes, which repeats steps 3 and 4.
6. The author or a merge rule merges the approved change into the main branch.

The checks in step 2 run only the paths that the tests cover. The reviewer in step 3 usually reads only what the diff shows. A change can pass both and still break a workflow that runs through code outside the diff.

Teams also choose when review happens. Many teams require approval before a change enters the main branch. Some projects let a change land first and review it afterward, which is faster but lets defects reach the main branch. Fast checks can run even earlier on the author's machine, e.g. a pre-push hook.

A few practices keep review useful:

• Small changes. A short diff gets a closer reading, so teams split large work into several pull requests.
• A clear description. The author states what the change should do and how it was checked.
• A self-review first. The author reads the diff and runs the change before asking for review.
• Automated checks first. Tools handle formatting and known bug patterns, so the reviewer can read for design and logic.

What are the types of code review?

The types differ in when the review happens and in who or what does the reading.

Formal inspection

A formal inspection is a planned meeting where several reviewers go through code line by line, with set roles and a checklist. It is also called a Fagan inspection, after the engineer who defined the method. Inspections are thorough and slow, so teams often keep them for code where a defect would cost the most.

Pull request review

Pull request review examines one change at a time on a code host. Reviewers comment on the diff when they have time, so the author and the reviewer do not need to meet. Because the reviewer usually sees only the diff, the author's description has to explain the goal of the change.

Pair programming

In pair programming, two developers work at one screen, and one reviews each line while the other types it. Review happens during writing, so no queue forms. A separate and lighter practice is the over-the-shoulder review, in which the author walks a colleague through a finished change in person.

Secure code review

A secure code review reads a change for security flaws. The Open Worldwide Application Security Project (OWASP) describes secure code review as manual examination of source code for vulnerabilities that automated tools often miss, e.g. business logic flaws.

Automated review

Automated review runs tools on the change before or alongside a person. Linting checks code against style and correctness rules, and static analysis flags likely bugs, both without running the code. AI review tools use a language model to read the diff and post comments. A person still judges whether the change does what the author was asked to do.

What is an example of a code review?

Here is an illustrative example. Acme Co. sells furniture online, and a reviewer there handles one pull request from a coding agent:

1. A developer asks the agent to "Let customers edit their delivery address during checkout."
2. The agent changes 2 files and opens a pull request titled "Edit delivery address in checkout."
3. The CI pipeline runs 214 tests on the branch, and they pass.
4. The reviewer reads the diff and asks for a clearer name for one variable.
5. The agent renames the variable, the tests pass again, and the reviewer approves.
6. After the merge, a customer with 2 items in the cart changes the address. The address saved, but the cart emptied.

In one of the 2 files, the approved diff changed one function:

 export async function updateAddress(session, address) {
-  session.order.address = address;
+  await saveAddress(session.customerId, address);
+  await session.reload();
   return session.order;
 }

Each changed line looks correct on its own. The session.reload() method is defined in another file. It rebuilds the session from saved data, and Acme saves the cart only at payment, so the reload dropped the cart. No test checked the cart after an address change, and the reviewer had no reason to open the file that cleared it. One run of the checkout with items in the cart would have shown the failure.

This example is simplified. A real review would also cover the payment step and the order total.

What changes when a coding agent writes the code?

When a coding agent writes the code, the code to review often grows faster than the time people have to read it.

Pull requests then wait in a queue that grows faster than reviewers can clear it, which is the review bottleneck. A long queue can end in rubber-stamp review, where an approval no longer means that anyone checked the change.

The author is different too. The pull request description is text the agent generated, not a record of what the software did. Code that reads well can still be AI slop, output that looks finished but is bloated or unchecked.

The person who submits AI-generated code still owns it. Disclosing AI help tells reviewers which parts to read most closely. Saved AI coding session history holds the prompt behind the change, so a reviewer can compare the request with the result.

A team can also require evidence of a run with each agent pull request, e.g. the steps taken and what happened, so approved code does not add to verification debt.

What does code review catch, and what does it miss?

Code review catches problems that a reader can find in the source:

• Unclear design. A reviewer flags code that is hard to follow or that breaks the codebase's conventions.
• Logic errors in the change. A reviewer who knows the goal can spot a missing case, e.g. an empty cart.
• Visible security flaws. A reviewer can spot a missing permission check, e.g. an admin action that any customer account can call.
• Missing tests. A reviewer can ask for a test that the author did not write.

Code review often misses problems that the diff does not show:

• Behavior at runtime. What the software does can depend on saved data, e.g. the cart that Acme had not saved yet.
• Code outside the diff. A changed line can call code in a file the reviewer never opens.
• Missing work. A reviewer comments on what the change contains and can miss a requirement that it left out.

Review also costs time. A change waits until a reviewer is free, and each comment needs an answer. In a 2024 industrial study of an AI reviewer, pull requests took longer to close (from about 6 to about 8 hours on average).

No findings is not the same as complete coverage. An approval records that someone read the change, not that the software works. Checking behavior takes a run of the software, e.g. runtime verification, which observes the program while it runs.

How is code review different from testing?

Code review reads a change, while software testing runs or examines a program to find where its behavior differs from what it should do. Review can find problems that no test checks, and tests can find problems that no reader traces. The two overlap on logic errors that are visible in the source and also fail a test. A full comparison of reading code and running code sets out which bugs each one finds.

What does code review cover?

These articles cover the main parts of code review:

• AI code review uses a language model to read a pull request and comment on possible bugs and risks.
• Reviewing agent pull requests means checking intent, scope, tests, and evidence of a real run, not only reading the diff.
• Static and dynamic analysis split automated checks into those that examine code without running it and those that observe it while it runs.
• Linting compares source code with a set of rules, without running it.
• Static code analysis checks source code for likely bugs and security flaws without running it.
• The review bottleneck is the backlog of pull requests that builds up when changes arrive faster than reviewers can read them.
• Refactoring changes the structure of existing code without changing its behavior, in small steps that tests check.
• Technical debt is the extra work that later changes cost because of an earlier shortcut.

See every Code review article

What should a review pair with besides reading the diff?

Pair the review with a run of the changed software. Reading shows what the code says, and a run shows what the software does, e.g. whether the cart still holds its items after the address changes.

Coding agents outpace testing, even with AI review. RunStory runs your software in a separate environment, tries relevant workflows, and checks the results. When something breaks, your coding agent receives the actions RunStory took and evidence of the unexpected result. It is in private alpha for CLIs and web apps, and your team keeps the final release decision.

Join the RunStory alpha →

FAQs

What is the purpose of a code review?

The purpose of a code review is to catch problems in a change early, before it merges. Reading the change also teaches a second person how that code works. Reading cannot show how the software behaves when it runs, so review works best next to tests that run it.

Should review happen before or after commit?

Code review usually happens after the author commits to a branch and before the change merges into the main branch. Reviewing after the merge saves waiting time, but a defect then sits in the main branch until someone reverts or fixes it. Checks that need no person can run earlier, before a push.

How do you review your own code?

To review your own code, open the diff on the code host and read it line by line, the way a reviewer will. Then run the changed software yourself and check the result before you request a review.

What makes a code review effective?

A code review is effective when the change is small and its description states what it should do and how it was checked. The author reviews the diff first, and automated checks handle formatting, so the reviewer can read for design and logic.