Which file breaks next? A predictive risk score, not a lint report

Static analysis tells you what's wrong with the code in front of you right now. It doesn't tell you which file is about to become a problem next month. Those are different questions, and most review tooling only answers the first one.

Software engineering research has repeatedly found that how often a file changes is one of the strongest available predictors of where its next defect will show up — a file rewritten twenty times in a month is empirically a worse bet than one that's sat untouched for a year, independent of how "clean" either one looks in a single diff. bugweg's Predictive Bug Risk Score is built around that signal, combined with two others, to answer a question static analysis doesn't ask: not "is this diff okay," but "which part of this repo is likely to break next, and why."

Three signals, one score per file

The score recalculates after every commit, from three inputs:

• Change velocity — how many times a file has been touched in the last 30 days. Churn concentrates risk; a file edited by five different people in a month has had five separate chances to introduce a regression.
• Complexity delta — how much a change increases a file's cyclomatic complexity, not just its line count. A ten-line change that adds three new branches is a different risk profile than a ten-line change that renames a variable.
• Historical defect density — how many bugs-per-KLOC bugweg has actually flagged and confirmed in that file over the last 90 days, weighted toward recent activity.

None of these three signals is novel in isolation — change frequency and complexity tracking both show up across static-analysis tooling in one form or another. What none of today's AI code review tools do is combine change velocity, complexity delta, and defect density into one forward-looking, per-file score, updated automatically after every commit rather than computed on demand. As of our last competitive pass (June 30, 2026), Greptile, CodeRabbit, DeepSource, and SonarQube each catch real problems in the PR you just opened — none of the four ships predictive, file-level risk scoring ahead of the next change landing there.

An illustrative example, not a claim about any specific customer repo: a payments webhook handler touched fourteen times in a month, where the most recent change added three new conditional branches and the file already has two confirmed defects behind it this quarter. None of those three facts is alarming by itself. Together, they're the profile of a file where the next PR deserves a closer look before merge — which is exactly what the score is for.

What it looks like in review

Every PR that touches a high-risk file gets a banner directly in the review: which of the three signals is driving the score, how the file's risk has trended over the last few commits, and — where bugweg has flagged and confirmed prior defects there — a link back into the same Bug Genealogy history described in our post on recurring bugs. The two features share data: a file's genealogy record is part of what feeds its defect-density signal.

Why per-file, not per-PR

A PR-level score answers "is this changeset risky." A file-level score, updated continuously, answers a longer-running question: "which parts of this codebase are accumulating risk over time, regardless of whether this week's PR touching them looks clean." The second question is the one that shows up on a dashboard, not just in a single review comment — a small number of files carrying a disproportionate share of a repo's defect history is a pattern every team has, and most have no tooling that surfaces it automatically. The code risk prediction page shows exactly how each signal is computed.