Reference · 57 terms
The code review glossary
Vendors lean on vocabulary that sounds precise and often isn't. These are plain definitions of the terms that show up in AI code review pitches, docs and pricing pages — each one with what it actually means when you are the buyer.
AI & models 11 Code quality 10 Review practice 7 Delivery & CI 8 Metrics 12 Security 9
A
Agentic AI A model given tools and a loop — it can run commands, read files, and act on the results across several steps, instead of producing one answer from one prompt. AI code review Using a large language model to read a proposed code change and leave findings on it, the way a human reviewer would — as a complement to human review, not a replacement for it. Alert fatigue What happens when a tool produces more findings than a team can process, so the team stops processing any of them — including the true ones.
B
Blast radius How much of a system a given change can affect if it is wrong — the practical measure of how carefully it should be reviewed. Blocking comment A review comment that must be resolved before a change can merge, as opposed to a suggestion the author can acknowledge and move past. Branch protection Rules on a branch that constrain how changes land — required reviews, required status checks, restrictions on force-push and direct commits. BYOK (bring your own key) A model where you supply your own LLM provider credentials, so inference is billed directly to your account instead of being resold by the tool vendor.
C
Change failure rate The share of deployments that cause a degraded service — a rollback, a hotfix, an incident — one of the four DORA metrics. CI/CD Continuous integration and continuous delivery: automatically building and testing every change, and keeping it in a state where it can be released. Code churn How often a piece of code is rewritten shortly after being written — a signal of unstable requirements or unclear design, not of productivity. Code coverage The percentage of code executed by the test suite — a measure of what is tested, not of how well it is tested. Code duplication The same or near-identical logic existing in more than one place, so a change has to be made more than once to be made correctly. Code owner The person or team automatically requested for review on a given path, usually declared in a CODEOWNERS file at the repository root. Code review The practice of having a change read by someone other than its author before it lands, to catch defects, spread knowledge, and hold a shared standard for the codebase. Code smell A surface pattern that suggests a deeper design problem — not a bug, but a signal worth investigating. Cognitive complexity A measure of how hard code is for a human to follow, weighting nesting and interrupted flow more heavily than raw branch count. Context window The maximum amount of text — code, instructions, conversation — a model can consider in a single request, measured in tokens. CVE Common Vulnerabilities and Exposures: a public identifier for a specific known vulnerability in a specific product, in the form CVE-YYYY-NNNNN. CWE Common Weakness Enumeration: a catalogue of the categories of software flaw — the class of mistake, rather than a specific instance of it. Cycle time How long a change takes to get from started to shipped — usually first commit to production, and the number most teams feel most directly. Cyclomatic complexity A count of the independent paths through a piece of code — effectively the number of branch points plus one.
D
DAST Dynamic application security testing: probing a running application from the outside with crafted requests, to find vulnerabilities that only appear at runtime. Defect escape rate The proportion of defects that reach production instead of being caught by review, tests or staging. Deployment frequency How often a team successfully releases to production — a DORA metric, and a proxy for how small and safe its changes are. Diff The line-by-line difference between two versions of a file — what a reviewer sees, and the minimum context most AI review tools work from. DORA metrics Four measures of software delivery performance — deployment frequency, lead time for changes, change failure rate and time to restore service — from the DevOps Research and Assessment programme.
E
F
H
I
L
M
MCP (Model Context Protocol) An open protocol for connecting models to external tools and data sources through a common interface, instead of a bespoke integration per system. Merge queue A system that serialises merges, testing each change against the current tip of the main branch before it lands, so green pull requests cannot break the branch on arrival. Model routing Choosing which model handles which part of a review — a cheap fast model for triage, a stronger one for deep reasoning — instead of sending everything to one model. Monorepo A single repository holding many projects or services, with one history and usually one build system. MTTR Mean time to restore: how long it takes to recover service after a failure in production — the fourth DORA metric.
N
O
Open source Software whose source code is published under a licence that permits reading, modifying and redistributing it — which is a licensing property, not a deployment one. OWASP Top 10 A periodically updated list of the ten most critical web application security risk categories, published by the Open Worldwide Application Security Project.
P
Pre-commit hook A script that runs on a developer's machine before a commit is created, blocking it if a check fails. Prompt injection An attack where text the model reads — a comment, a README, a pull request description — carries instructions the model follows as if they came from you. Pull request A proposal to merge one branch into another, with a diff, a description and a discussion thread — the unit of work most review and AI review tooling operates on.
R
RAG (retrieval-augmented generation) Fetching relevant material from a repository or knowledge base and putting it into the model's prompt, so the answer is grounded in your code rather than in the model's memory. Review coverage The share of changes that actually received a meaningful review before merging — as opposed to the share that received an approval. Review latency The time between a pull request being ready and a reviewer responding to it — usually the largest single component of cycle time.
S
Sandbox validation Running or testing a proposed change in an isolated environment to confirm a finding is real, instead of only reasoning about it. SAST Static application security testing: scanning source code for vulnerability patterns — injection, unsafe deserialisation, hardcoded credentials — without running the application. SCA (software composition analysis) Scanning a project's dependencies for known vulnerabilities and licence obligations, by matching the dependency tree against vulnerability databases. Secret scanning Detecting credentials — API keys, tokens, private keys, connection strings — committed into source control or present in a proposed change. Self-hosting Running a tool on infrastructure you control, so the code it analyses stays inside your network boundary rather than passing through a vendor's cloud. Shift left Moving quality and security checks earlier in the development process, where problems are cheaper to find and fix. Signal-to-noise ratio The proportion of a tool's findings that a team acts on — the practical measure of whether a code review tool is worth keeping. Static analysis Analysing source code without running it, using parsers and rules rather than execution — the deterministic half of automated code review. Supply chain attack Compromising software by attacking something it depends on — a package, a build step, a maintainer account — rather than the application itself.
T
Know the vocabulary — now check the claims
Every tool in the directory is scored on what its own docs actually back up.