Best Tools to Predict Bug-Prone Files (2026)

To predict bug-prone files from git history, rank files by past bug-fix activity weighted by recency, then add a code-quality signal; CodeScene packages this commercially, the Google heuristic is the easiest to reimplement, and repowise does it locally with a deterministic code-health score. Researchers use SZZ-based pipelines to label bug-introducing commits, and SonarQube finds rule violations but does not predict defects from history.

Facts as of November 2026 from CodeScene Code Health, CodeScene pricing and the Google research page.

What does bug-prone file prediction mean?

Bug-prone file prediction ranks files by how likely they are to receive a bug fix soon. The label is usually a commit whose message marks a fix. A good tool is judged on whether the files it ranked high are the ones that later received fixes, which needs a time split: score first, wait, then check. For the churn side of the input, see code churn; for the practical list, see git hotspot analysis.

How we compared

• Signal: which inputs the tool uses and whether they come from your own history.
• Evidence: whether a method or validation is published.
• Output: a per-file score, a per-change score, or raw data.
• Fit: where it runs and who can read the result.

CodeScene

CodeScene scores each file's Code Health and states that its factors correlate with maintenance cost and defect risk. Its Code Health page covers 30+ programming languages and cites a marketing figure of preventing "up to 15x more defects" that the page does not explain (codescene.com). Pricing is per active author, with open source projects free (pricing).

Pick CodeScene if you want a supported commercial product and a single health number your managers already recognise.

Google's bug prediction heuristic

Google described a simple approach in a public engineering write-up: score files by their past bug-fix commits, with older fixes counting less. The write-up is on the Google Engineering Tools blog; I could not load its body today, so check it for the exact weighting. Google's own ICSE 2013 study of the deployed algorithm reports that it observed no identifiable change in developer behavior, and lists characteristics prediction tools need to be accepted by developers (Google Research). The lesson is practical: a ranked list nobody acts on is wasted, so put the signal where reviews happen.

Pick the heuristic if you want a baseline in a weekend and are fine matching fix commits by message keywords.

SZZ-based research tools

The SZZ algorithm finds the commit that introduced a bug by blaming the lines a fix commit changed. It is the standard way to label bug-introducing commits in defect prediction research. PyDriller is a Python framework for mining repositories and is commonly used to build such pipelines (docs); check its API reference for the exact SZZ support in your version.

Pick this route if you are running a study or training a model. It is not a ready-made tool for a team that wants a list on Monday.

SonarQube

SonarQube reports rule violations and quality gate status; it does not rank files by predicted defects from git history. Its Security Hotspots feature marks security-sensitive code for review (docs). Keep it for rules and add a history-based signal for prediction.

repowise

repowise ranks files by bug-fix history, churn and ownership, and scores code health with 59 deterministic detectors, with no LLM calls. It traces bug-fix commits to files and symbols and warns on bug magnets, so a file with repeated fixes is marked before you edit it (code health, change risk). repowise risk main..HEAD scores a range against the repository's own commit history, and the same scoring runs in the PR bot on GitHub, the VS Code extension and the get_risk and get_change_risk MCP tools.

The score was tested in public. In the 21-repo validation study, the code-health score reached a cross-project mean ROC AUC of 0.74 [95% CI 0.68-0.79] across 21 repositories and 9 languages. On 2,770 files scored by both tools, it surfaced 2.3x the defects CodeScene's score did under a fixed review budget of 20% of lines. Read the post for method and controls.

uv tool install repowise
repowise init
repowise risk --target src/pipeline/persist.py
repowise risk main..HEAD

Pick repowise if you want history-based prediction on your machine, shared with agents and CI.

How to choose

• Individual developer: repowise init, then repowise risk before edits to the top files.
• Team that wants a supported product: CodeScene.
• A baseline or a teaching exercise: reimplement the Google heuristic.
• A paper or a model: PyDriller with SZZ.
• Enterprise with many repositories: self-hosted repowise with workspaces, so the history is read per repo and results are shared across teams.