甚麼是程式碼審查？類型、演變與 2026 年的 AI 審查

I've reviewed other people's architecture for most of my career, and these days I also review what coding agents write. Ask five engineers what code review means and you'll get five answers: a meeting, a comment thread on a pull request, a lint job, a security audit and an AI bot. All five are right.

The newest answer is arriving at scale. More than 40% of pull requests on GitHub in September 2026 were started by an agent, up from 17% in March, according to GitHub's Octoverse report. Review practices that worked for human-sized output now have to absorb agent-sized output.

In this guide you'll learn:

1. What code review is, in one definition.
2. The six types of code review and how they differ.
3. How code review changed over five decades.
4. How peer review on pull requests works, with a worked example.
5. What AI code review adds, and why the reviewer should be independent of the tool that wrote the code.
6. Which tools and metrics go with each type, with a link to a deeper guide for each.

What Is Code Review?

Code review is the practice of having someone other than the author, whether a teammate, an automated check, a security specialist or an AI reviewer, read a change to source code before it ships. The goal is to catch defects, keep the design consistent and spread knowledge across the team.

The term covers several practices, and people mix them up. Some mean a teammate reading a pull request. Some mean a formal inspection meeting with a moderator. Some mean the CI job that runs linters and security scanners on every commit.

"Source code review" often means something else again: a security-focused read of a codebase by a specialist or a third party, run for an audit, a compliance check or due diligence. And since 2024 or so, many people mean an AI reviewer that comments on every PR.

Code review in software engineering is the umbrella over all of them. The type you need depends on what you're trying to catch, and most teams run three or four types at once.

Types of Code Review at a Glance

Six types of code review cover nearly everything people mean by the term. They differ in who or what does the reviewing, when it happens, and what it's built to catch.

The types stack rather than replace each other. A typical team in 2026 runs automated checks in CI, an AI reviewer on every PR, peer review for design, and a security review for the riskiest changes.

How Code Review Changed: Five Shifts

Each shift in code review answered a cost the previous one couldn't carry. Inspection was thorough but slow. Lightweight review cut the meetings. Pull request tools made review async and recorded. Automation took over the checks a rule can express. AI review is the answer to a volume problem that AI-written code created.

The five shifts happened in this order.

1. Inspection meetings, from the 1970s.
2. Lightweight peer review, through the 1990s.
3. Peer review on pull requests, from 2008.
4. Automated checks in CI, alongside the pull request era.
5. Independent AI review, from about 2023 to now.

Secure source code review runs alongside all five as a parallel track. Security teams have audited code in every era, and the way they do it moved along with everything else.

Formal Inspection: Where Code Review Started

Code review as a named method starts with Michael Fagan at IBM. His 1976 paper in the IBM Systems Journal described design and code inspections as a structured process with defined roles, and the method still carries his name: Fagan inspection.

An inspection runs in fixed stages: an overview of the change, individual preparation, an inspection meeting, rework by the author, and a follow-up check. Later versions of the method added a planning stage up front.

The meeting has roles, usually a moderator, the author, a reader who walks through the code, and inspectors who log defects.

The method is thorough, and it's expensive. Every inspection books several people into a room and adds days to the calendar. Most product teams moved on, but software inspection survives in safety-critical and regulated work, where a documented review record is worth the cost. You can read Fagan's original paper through IBM's journal archive.

Lightweight Code Review: Over the Shoulder and Pair Programming

Lightweight code review dropped the meeting and the roles. In an over-the-shoulder review, the author walks a colleague through the change at the author's desk. Before shared code servers, teams also passed diffs around by email for comments.

Pair programming took the idea furthest: two people write the code together, so review happens while the code is written. Kent Beck made it a standard practice of Extreme Programming on Chrysler's C3 payroll project, which restarted under his lead in 1996.

Beck's 1999 article on XP in IEEE Computer put the rule plainly, saying that "all production code is written by two people at one screen/keyboard/mouse."

Lightweight review costs less than inspection and spreads knowledge well. The trade-off is the record: a conversation at a desk leaves no trail, and nobody can check later what was looked at. For how to run these approaches today, and when each works, see my guide to peer code review.

Peer Code Review on Pull Requests

The pull request made review async, recorded and tied to a branch. GitHub shipped pull requests in February 2008, and Google released Gerrit for the Android open source project later that year. Gerrit grew out of Rietveld, a review tool Guido van Rossum built on lessons from Google's internal review tooling.

By 2013, review was "less formal and more lightweight" than the inspections of the 1970s and 1980s, according to a Microsoft Research study by Alberto Bacchelli and Christian Bird presented at ICSE 2013.

Finding defects was still the main motivation, but reviews turned out to be less about defects than expected and brought knowledge transfer and team awareness, according to the Bacchelli and Bird study.

Pull request review is still the center of most teams' workflow, so the rest of this section covers how it works day to day.

How Code Review Works, Step by Step

Here is how to do code review on a pull request, as most teams run it in 2026. Qodo's guide to a code review process covers scaling it to agent volume.

1. The author checks their own change, or the coding agent reviews its own change before opening the PR.
2. The author opens the PR with context: the ticket, the intent and the risky parts.
3. Automated checks run: formatting, lint, tests, static analysis and security scans.
4. An AI reviewer and one or more human reviewers read the change.
5. The author and reviewers discuss findings and push fixes.
6. A reviewer approves.
7. The change merges.
8. Signals after merge, such as incidents, reverts and review analytics, feed back into the team's standards.

Teams that follow this code review process treat steps 1 and 8 as part of review, not extras. Most review problems I've debugged started at step 2, with a PR that gave the reviewer no reason for the change.

A Code Review Example

Here is a small change and three review comments. The author added a discount helper to a checkout service.

def apply_discount(order, code):
    discount = DISCOUNTS.get(code)
    order.total = order.total - discount.amount
    return order

The first comment is a question: "What happens when code isn't in DISCOUNTS? discount is None, so .amount raises." The second is a suggestion: "Totals can go negative if a discount is larger than the order. Clamp at zero?" The third is a nit: "Rename to apply_discount_code to match the other helpers."

def apply_discount_code(order, code):
    discount = DISCOUNTS.get(code)
    if discount is None:
        raise InvalidDiscountCode(code)
    order.total = max(order.total - discount.amount, 0)
    return order

The author fixed the crash, clamped the total and took the rename. A good code review example has the same shape every time: a question that finds a bug, a suggestion about behavior, and a small style note that nobody argues about.

What Reviewers Look For

Reviewers on a pull request check a short list of things, in roughly this order of importance:

• Correctness and edge cases, such as the missing discount code above.
• Design and fit with the existing architecture.
• Security, including authorization checks, input handling and secrets.
• Tests that cover the new behavior.
• Readability and naming.
• The team's written standards.
• Impact beyond the diff, such as callers in other services or repositories.

For how teams run peer review on PRs, including the five approaches, writing good comments and async review across time zones, see the full guide to code review approaches.

Automated Checks and Static Code Analysis

Automated checks moved the repeatable part of review into CI. Linting goes back to Bell Labs, where Stephen C. Johnson described lint, a checker for C programs, in a 1978 technical report. Once CI ran on every change, linters, formatters, static analyzers and SAST tools could check every commit.

Teams stopped arguing about style in review comments. A rule caught the problem first, the same way every time, and humans spent their attention on design and intent instead.

Machines apply rules, and people apply judgment. Static analysis can't tell whether a change does what the ticket asked, and it raises false positives that someone has to triage.

For how static analysis works, static vs dynamic analysis, and how to layer static checks with AI review, see my guide to static code analysis.

Secure Source Code Review and Audits

When people search for source code review, they often mean a security-focused read of a codebase. AppSec teams run these reviews internally, and outside firms run them for audits, compliance or due diligence before an acquisition. The output is a findings report, not a comment thread.

The OWASP Code Review Guide is the usual reference method for this kind of review. Security review is moving from periodic audits toward advisory findings on every PR, with full audits kept for the highest-risk scope.

For the OWASP-based method, a checklist, and how to review AI-generated code for security, see my guide to secure code review.

AI-Assisted and Independent AI Code Review

The latest shift started when generation scaled and human review didn't. Agent-started PRs reached about 110 million on GitHub in September 2026, and GitHub calls its agent detection a floor, not a full count, according to GitHub's Octoverse 2026 report.

Review is where that volume lands. After firms adopted AI agents, they opened more pull requests, waited longer from review submission to approval, and left more comments per change, according to a working paper by Chen and Stratton that uses Jellyfish platform data from 655 firms.

Most of those firms had adopted AI code review tools but still largely kept humans in the loop. The paper is observational and not peer-reviewed, and I'm citing the November 1, 2026 version only, because earlier drafts reported different numbers.

AI review comes in two kinds. AI-assisted review is a bot or assistant inside the product you already use to write or store code. Independent AI review is a separate layer that reviews changes from any agent or human against the team's own standards.

Several reviewers now ship inside the product that writes the code. GitHub Copilot code review lives in Copilot, and GitLab Duo lives in GitLab. Bundled reviewers need no new vendor and run inside the existing workflow. GitHub's own documentation advises teams to supplement Copilot's feedback with a human review.

The trade-off is independence. The system that generates code shouldn't be the system that decides whether it ships, a point Qodo makes when it explains why generation and review should be separate systems.

AI review also moves review earlier and wider. Coding agents can review their own changes before a PR exists, which is the shift left idea applied to review. And a reviewer with codebase-wide context can follow a change into the repositories that depend on it.

Tools made for agentic code review plan their own checks and pull in the context a change needs.

For a longer primer on how AI reviewers read a change, see Qodo's AI code review guide.

Qodo Review is the independent layer I recommend when review is your bottleneck. Qodo reviews every PR with full codebase context, PR history, linked tickets and your team's standards, and coding agents can run the same engine before a PR exists through the Qodo Agentic Toolbox. Findings are advisory, and a human still decides.

Choose Qodo if you need one review layer across hundreds of repositories and several Git providers. Qodo reviews pull requests on GitHub, GitLab, Bitbucket, Azure DevOps and Gerrit, and applies one list of team standards on GitHub, GitLab, Bitbucket Cloud and Azure DevOps.

Qodo matches review depth to the change. Auto mode, the default, picks Fast, Balanced or Deep review by the risk of each PR, and teams can cap or fix the review depth per repository. Multiple review agents check bugs, security, team standards and ticket requirements, and severity routing keeps high-signal findings inline.

Qodo learns from what your team fixes and skips. On GitHub, GitLab and Azure DevOps, Rule Miner turns accepted review comments into rules, and Qodo deactivates rules whose findings are rarely fixed.

Before the PR, the Qodo Agentic Toolbox gives coding agents the same reviewer plus Codebase Wisdom, the codebase context and Git history, through the qodo review CLI, MCP, and plugins for Claude Code, Codex and Kiro.

High-velocity teams merge sooner, because agents clean up their own PRs first and humans see fewer, sharper findings. Enterprise and high-velocity teams alike get safer merges, with standards checked on every PR.

Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for teams that want every change, human- or agent-written, reviewed by a system that didn't write it.

Qodo's glossary defines AI-generated code validation: proving that agent output meets your standards before it merges.

My Experience: When Agents Start Opening PRs

The pattern I see when agents start opening PRs on their own is predictable. The review queue grows and the reviewer pool doesn't. A few senior engineers become the approval path for anything risky, and much of what they write in comments repeats the same reminders about standards.

More reviewers rarely fix it. What works is moving the repeat checks into an independent AI review layer, having agents review their own changes before a PR exists, and saving senior attention for design calls. The queue shortens, and human comments move from style to intent.

Code Review Tools, by Group

Code review tools fall into four groups, and each one matches a type above:

1. Review bundled into coding platforms, which reviews the diff inside the tool that wrote it.
2. Independent AI code review, such as Qodo, which reviews changes from any source against your own standards.
3. Static analysis, which applies deterministic rules and quality gates.
4. Security scanning and SAST, which follow data flows to find vulnerabilities.

Most enterprise teams combine groups rather than pick one. Qodo keeps a comparison of AI code review tools for enterprise teams if you want a second view.

For six tools in four groups, what each group catches and how to combine them, see my guide to code review tools.

How Teams Measure Code Review

Every shift changed what teams could measure. Inspections logged defects found per meeting. Pull requests logged time to first review and review cycles. AI review now logs findings raised and findings acted on.

Four review metrics are worth tracking from day one: time to first review, review cycles until merge, rework after merge, and the share of AI review comments that authors act on. The last one tells you whether your AI reviewer is signal or noise.

For ten software engineering metrics and how review metrics feed DORA, see my guide to engineering metrics.

Benefits and Drawbacks of Code Review

The benefits are well documented. Review catches defects before users do, keeps the design consistent, and leaves a record of who approved what. Juniors learn the codebase from it, and seniors learn what the juniors are struggling with.

The drawbacks are just as real. Review adds queue time, and reviewers get tired. Tired reviewers rubber-stamp large PRs, and noisy bots train people to ignore comments. Agent-written code makes queue time, reviewer fatigue, rubber-stamping and bot noise worse, because the volume grows while the reviewer pool stays the same.

Code Review Best Practices

A short list covers most of what I'd tell a new team:

1. Keep changes small enough to review in one sitting.
2. Give reviewers context: the ticket, the intent and the risky parts.
3. Review the plan before the code when an agent writes the change.
4. Match review effort to the blast radius of the change, not its line count.
5. Write your standards down and check them on every PR, as in Qodo's code review best practices.
6. Use a reviewer that is independent of the tool that wrote the code.

Summary

Code review is six practices, not one. Formal inspection gave review its structure, lightweight review made it cheap, pull requests made it async and recorded, automation took over the repeatable checks, and AI review is answering the volume that agents create. Secure source code review runs alongside all of them.

Most teams in 2026 combine automated checks, an independent AI reviewer, peer review for design and targeted security review. The deeper guides linked above cover each type in detail.

FAQ

What is the purpose of code review?

Code review catches defects before they ship, keeps the design consistent and spreads knowledge across the team. Research on review at Microsoft found that knowledge transfer and team awareness are frequent outcomes, even though finding defects is the main reason teams review.

What are the types of code review?

The six common types are formal inspection, lightweight review (over the shoulder and pair programming), peer review on pull requests, automated checks and static analysis, secure source code review, and AI-assisted or independent AI review. Most teams combine three or four of them.

What is the difference between code review and code inspection?

Code inspection usually means Fagan-style formal inspection: a meeting with defined roles, entry and exit criteria, and logged defects. Code review is the broader term and includes lightweight, async and automated practices.

What is source code review?

In search, source code review often means a security-focused review of a codebase by AppSec specialists or an outside firm, usually for an audit, compliance or due diligence. The result is a findings report rather than PR comments.

What are the steps in a code review?

The author self-checks and opens a PR with context. Automated checks run, AI and human reviewers read the change, the author fixes what they find, a reviewer approves and the change merges. Signals after merge feed back into the team's standards.

Can AI replace human code review?

AI can take over the repeatable checks and flag issues on every PR, but humans still own design decisions and the final call. The bigger question is independence: the tool that writes the code shouldn't be the only one that reviews it.

Is Qodo a test generation tool?

Qodo isn't focused on test generation, even though some authors still point to it as a key strength. In my experience, Qodo is best at AI code review and code governance for teams that want every change, human- or agent-written, reviewed by a system that didn't write it.