Also called Change risk analysis, Just-in-time defect prediction, Commit risk
In depth A deterministic PR review bot, no LLM: how the checks behind a pull request review are computed without a model.
How change risk is measured
Change risk scores a change by features of the diff, often combined with file history. The research version is just-in-time (JIT) defect prediction. Kamei et al., "A Large-Scale Empirical Study of Just-in-Time Quality Assurance" (IEEE Transactions on Software Engineering, 2013), fit models on change-level metrics in several projects. Those metrics include lines added and deleted, number of files, directories and subsystems touched, the entropy of how scattered the edits are, and the author's experience.
A simplified illustration, not a real model:
| Change | Lines added | Files | Directories | Prior bug fixes on touched files |
|---|---|---|---|---|
| A: rename a constant | 4 | 1 | 1 | 0 |
| B: new endpoint plus migration | 380 | 9 | 4 | 2 |
| C: one-line edit in a file fixed 20 times | 1 | 1 | 1 | 20 |
A scores low on every axis. B scores high on size and spread. C is tiny, yet its history says people keep getting this file wrong, which is why size alone is not enough.
Why change risk matters
Reviewers have limited attention, and most changes are safe. A score lets a team send the large, scattered or bug-prone changes to a second reviewer and let routine ones through quickly. It also catches omissions a diff cannot show: a file that nearly always changes with the one you edited (temporal coupling) but is missing from the pull request, or a changed line no test runs.
A score is a prioritization aid, not a verdict. Models built from change metrics rank commits better than chance, but they predict defects imperfectly, so use them to decide where to look.
How to measure change risk yourself
Without a tool you can approximate the inputs with git:
# Size and spread of a branch against main
git diff --shortstat main...HEAD
git diff --dirstat main...HEAD
# Prior bug fixes on a file (commit messages containing "fix")
git log --oneline -i --grep="fix" -- path/to/file.py | wc -lCounting commits whose message contains "fix" is a crude bug-fix proxy. For a model from the research literature, public JIT defect-prediction datasets and replication packages exist, but fitting and maintaining one is a project of its own. Code hotspot analysis, which ranks files by churn, is the cheaper first step. For packaged options, see the PR risk score and blast radius tools roundup.
How repowise measures change risk
get_change_risk (an MCP tool) and repowise risk (CLI) score a commit, a base..head range or uncommitted work. Both are deterministic, run on git alone, and need no LLM or network. See change risk.
- Score: 0 to 10, from a logistic model over seven change features (lines added, lines deleted, files, directories, subsystems, entropy, author experience) with constants learned offline. Drivers list each feature's push on the score against a baseline commit.
- What it means: repowise reports it as size and spread, shown as a percentile among the repository's recent commits, so reviewers know which changes deserve a second pair of eyes.
repowise risk --fail-above-percentile 95gates on that percentile. - Bug-fix record: the touched files' prior bug-fix commits, weighted by age, which is the part that says whether the files have broken before.
- Also reported: independent change groups (a hint to split), co-change files missing from the diff, and tests that reach the changed lines, with patch coverage when a report is ingested.
Usage:
repowise risk # uncommitted work, or HEAD if clean
repowise risk main...HEAD # what a pull request changed
repowise risk --format jsonThe PR bot (GitHub only) posts the same kind of checks on pull requests. Full details are in the change risk docs.