靜態程式碼分析與程式碼審查：各自能發現甚麼，以及如何在 2026 年分層使用

Static code analysis catches patterns, and code review catches intent, design and impact across files and repositories. No pattern rule can tell you whether a change does what the ticket asked: 13.2% of developers named matching code to intent as their top AI code review challenge in Qodo's State of AI Code Quality 2026 survey.

As an architect, I layer linters, SAST and an independent AI reviewer, then hand humans only the calls that need judgment.

Automated checks are one of the types of code review in my code review guide. Here's what I cover:

What static code analysis is and how it works.
Static vs dynamic code analysis, and SAST vs DAST.
What static analysis catches compared with code review.
Where AI code review sits as a third layer.
Where each check runs, from the IDE to the PR.
Strengths, limits and false positives.
How to layer linters, SAST and AI review in one workflow.

What Is Static Code Analysis?

Static code analysis is the automated inspection of source code without running it. An analyzer parses the code and applies rules, type checks and data-flow analysis to find bugs, security flaws, style violations and risky patterns. Because it doesn't need a running system, static analysis can check every change, early and cheaply.

Linters are the simplest form of static analysis. Full static analysis platforms add cross-file data flow, quality gates and dashboards, and static application security testing (SAST) focuses the same techniques on vulnerabilities.

How Static Analysis Works

Most analyzers follow the same pipeline:

Parse the source into an abstract syntax tree (AST), a structured model of the code.
Match rules against the tree: an unused variable, an unchecked return value, a string concatenated into a SQL call.
Track data flow across functions and files, including taint analysis that follows untrusted input from a source to a sink.
Score and report each finding by severity and rule.
Apply a quality gate that passes or fails the change, usually on new code only.

The output is deterministic: the same code and the same rules give the same findings every time. Repeatability makes static analysis easy to audit, and it also caps what static analysis can find.

Static vs Dynamic Code Analysis

Static analysis reads code without running it. Dynamic analysis watches the code while it runs, through tests, fuzzing or attacks against a running application.

Aspect	Static analysis	Dynamic analysis
When the code runs	Never; source only	At runtime, in a test or staging system
What it finds	Patterns, data flows, rule violations	Runtime behavior, configuration and integration flaws
Cost per run	Low, so it runs on every change	Higher, so it runs less often
False positives	More, because it can't see runtime context	Fewer, but it misses code paths it never exercises

SAST vs DAST

SAST is static analysis aimed at security: it reads source code for vulnerable patterns and data flows. DAST, dynamic application security testing, attacks a running application from the outside, the way a pentester would.

SAST finds issues early, with line numbers. DAST confirms which ones are exploitable in a deployed system. Most security programs run both.

Static Code Analysis vs Code Review: What Each Catches

The cleanest split I know: machines apply rules, and people, and now AI reviewers with enough context, apply judgment.

Aspect	Static code analysis	Code review
What it checks	Known patterns, rule violations, data flows	Correctness, design, intent, readability, impact
How it decides	Deterministic rules	Judgment, from a person or a context-aware AI reviewer
Context	The file, or the repository the rules can see	The ticket, the system and other repositories
Speed	Seconds to minutes, on every change	Minutes to hours, depending on the reviewer
False positives	Common, tuned through rules	Fewer, but depends on the reviewer
Who acts on it	The author, guided by a rule ID	The author and reviewer, in a discussion

One naming trap: "static code review" sometimes means a manual review of code without running it, done by people. Don't confuse it with static analysis tools.

Generation and governance need different things. Intelligence is enough to generate code, but governing it takes wisdom: knowing your team's standards, your architecture and what went wrong last time. Rules encode some of that. Review supplies the rest.

Qodo calls that layer Codebase Wisdom: the codebase context and Git history its reviewer and your coding agents share.

Where AI Code Review Sits: The Third Layer

AI code review sits between static analysis and the human reviewer. A context-aware AI reviewer reads the change against the codebase, the ticket and the team's standards, so it can ask questions no rule can: does this change do what the ticket asked, and does it break a caller in another repository?

Context is what separates useful AI review from noisy AI review. A reviewer that sees only the diff guesses, while one fed by a context engine across the whole codebase can reason about callers, contracts and history.

Only 34.6% of developers said their agents always follow the org's standards, in Qodo's State of AI Code Quality 2026 report.

Censuswide ran the survey with 500 US developers and 300 US leaders in August 2026, and all answers are self-reported.

For a longer comparison, Qodo's blog weighs static analyzers vs AI code reviewers by use case.

Where It Runs: IDE, Pre-Commit, CI and the Pull Request

Static analysis can run at four stages of the SDLC, and most teams use all four:

IDE: a linter flags issues as you type.
Pre-commit: a formatter and fast linter run before code leaves the laptop.
CI: the full analyzer and SAST run on every push, with quality gates on new code.
Pull request: results appear as PR decoration or comments, next to the human and AI reviews.

AI code review now runs at two of those stages: before the PR, when a coding agent reviews its own change, and on the PR itself.

Strengths and Limits, Including False Positives

Static analysis is consistent, quick and broad. Every line of every change gets checked against the same rules, the analyzer never gets tired, and the audit trail shows which rule fired where.

The limits are just as clear. Static analysis can't see intent, so it can't tell whether a change matches the ticket. Most analyzers see little across repository boundaries. And rules need upkeep: every new framework and pattern means new rules, or new false positives.

False positives are the expensive part. One traditional analyzer raised 6,345 warnings on a single project, with a sampled false-discovery rate of 76%, in a January 2026 project-scale study of LLM-based vulnerability detection. The same study found LLM-based agents recalled more known vulnerabilities, though every tool raised many false alarms.

LLM-based scanners had higher recall than rule-based SAST across 15 scanners and 26 intentionally vulnerable Python repositories in RealVuln, a second 2026 preprint. The authors sell a scanner that ranked first, which they disclose, and the test repositories are denser with flaws than real code.

Both studies are preprints, so treat them as direction, not verdicts. Qodo's glossary explains how teams track the false positive rate in code review.

My Experience: The Bug Every Analyzer Misses

The bug class I worry about most passes every check. A service renames a field in its API response, and lint, types, tests and SAST all stay green. A consumer in another repository keeps reading the old field and quietly falls back to a default.

No rule can flag it, because nothing in either repository is wrong on its own. The failure exists only across the two. Patterns like this one are why I put a review layer with cross-repo context into every stack I design, and why I don't treat a green pipeline as a reason to merge.

How to Layer Linters, SAST and AI Code Review in One PR Workflow

Here's the stack I recommend, in order:

Formatter and linter in pre-commit.
SAST and secrets scanning in CI.
AI review with full context, before the PR and on the PR.
Human review for design and risk.
Analytics after merge, to see which findings get acted on.

Green CI plus the coding agent's own "looks good to me" isn't enough to merge on. Your team's rules shouldn't be left to the system that generated the code. Qodo's academy has a guide to integrating AI code review into your tool stack for teams wiring this up.

The third layer covers changes that pass every rule but still break a contract in another repository, or ignore how the team works. Qodo Review fills that gap. Qodo sits after linters and SAST, before the human, and reviews each PR against the codebase, PR history, tickets and team standards.

Over time, Rule Miner can turn accepted review comments into rules on GitHub, GitLab and Azure DevOps, and Qodo switches off rules whose findings are rarely fixed, which cuts noise instead of adding one more bot. For multi-repo teams, cross-repo findings can link to the affected lines in the other repository.

Coding agents run the same engine before the PR through the Qodo Agentic Toolbox.

Auto mode matches review depth to the risk of each change, so a config tweak gets a fast pass and a contract change gets a deep one. Findings are advisory, and the human still decides.

Choose Qodo if static analysis is green but reviewers still catch design and intent issues by hand. Qodo complements your linters and SAST rather than replacing them.

Enterprise teams get one list of standards checked on every PR across GitHub, GitLab, Bitbucket Cloud and Azure DevOps, and high-velocity teams merge sooner because the repeat checks no longer wait for a human. Qodo's glossary covers bug detection in AI review if you want the background.

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 the layer static analysis can't cover: intent, team standards and impact across repos.

Tool Categories at a Glance

Each layer has its own category of tools, with one or two examples below.

Linters, such as the open source ESLint for JavaScript and Ruff for Python.
SAST, such as Snyk Code, a developer-first SAST tool with PR Checks that fail only on new issues.
Static analysis platforms and quality gates, such as SonarQube, which Sonar describes as code verification and governance, with quality gates that can block a merge.
AI code review, such as Qodo, for intent and team standards.

For a wider list, Qodo compares code analysis tools for large codebases.

For how all the code review tools group together, see my guide to code review tools.

For security-specific review, see my guide to secure code review.

Static Code Analysis Best Practices

For AI-heavy codebases, a few practices matter most.

Run quality gates on new code, so old findings don't block every PR.
Tune rules quarterly, and delete the ones nobody acts on.
Track false positives per rule, rather than total findings.
Keep the code generator separate from the verifier.
Route findings by severity, so high-severity ones stay visible.
Measure which findings get fixed, and feed that back into the rules.

Summary

Static code analysis checks code against rules without running it, and it's the right first layer for every team. Code review checks intent, design and impact, which rules can't express. Layer them: linters and SAST in CI, a context-aware AI reviewer before and on the PR, and humans for design and risk.

FAQ

What is static code analysis in simple terms?

Static code analysis is software that reads your code without running it and flags patterns that match known bugs, security flaws or style problems. Think of it as a spell checker for code that also follows data from one function to another.

In which stage of the SDLC is static code analysis performed?

As early as possible, and then repeatedly. Linters run in the IDE and pre-commit, full analyzers and SAST run in CI on every push, and the results show up on the pull request.

What's the difference between static and dynamic code analysis, and SAST vs DAST?

Static analysis reads code without running it, and dynamic analysis tests the code while it runs. SAST and DAST are the security versions: SAST scans source code, and DAST attacks a running application.

Linter vs static analysis: what's the difference?

A linter is a simple, fast kind of static analysis focused on style and obvious bugs, usually one file at a time. Static analysis platforms add cross-file data flow, security rules, quality gates and reporting.

Can static analysis replace code review?

No. Static analysis checks rules, while code review checks whether a change does what it should and works with the rest of the system. Most teams run static analysis first so reviewers can spend their time on design and intent.

What are the benefits of static code analysis?

Static analysis finds known problems early and cheaply, applies the same rules to every change, and leaves an audit trail. Teams also stop arguing about style in review comments.

Should AI code review run before or after static analysis?

After. Linters and SAST clear the known patterns first, so the AI reviewer spends its attention on intent, standards and impact across repositories. Qodo sits after linters and SAST and before the human reviewer.