Which file breaks next — not just what's wrong in today's diff
Every code review tool tells you about the PR in front of it. Code Risk Prediction is bugweg's answer to a forward-looking question instead: given everything that's happened to this codebase, which files are most likely to cause the next incident?
What actually feeds the score
Every file touched by a PR updates three cumulative counters: change_velocity (+1 per PR that touches it — files that get edited constantly carry more risk), complexity_delta (a real cyclomatic-complexity score — 1 plus every branch, loop, case, catch, ternary, and &&/|| a tree-sitter parse finds in the file — for files in one of the 5 supported languages that the structural-context stage fetched; otherwise that PR's added-plus-deleted line count, a cruder size-of-change proxy), and defect_density (+1 per issue bugweg actually flags in that file). Each counter is scaled by a 30-day half-life before a new PR's update is added, so a file that hasn't been touched in a month carries half the weight of an equally-active file touched today — recent activity matters more than a spike from three months ago. Two approximations remain: it's one score per file, not per function, and LOW-tier PRs, unsupported languages, or files outside the structural stage's 15-file cap fall back to the line-count proxy.
Box sizing on the dashboard's risk heat map uses real file line count where it's already been captured during review (no extra API call — it piggybacks on the structural-context stage's existing file fetch), falling back to the risk score itself for files that stage hasn't touched yet. This is live and running today — see the exact current status of every bugweg feature, including what's still simplified, on Features.
Why forward-looking risk beats a static lint report
A lint report tells you a rule was violated. It doesn't tell you that the file you're about to touch has been edited nine times in the last two weeks by three different people and already produced two flagged bugs this month. That's exactly the kind of signal a static analyzer can't see, because it has no memory of anything outside the current diff — the same gap Bug Genealogy closes at the individual-bug level, this closes at the file level.
This heat map is separate from the per-PR User Impact Score, which is derived from the highest-severity issue found in the PR and isn't computed from these counters.
See where this fits in the full review pipeline on How it works, or install bugweg to see your own repo's risk map.