Deterministic code health
Find the files most likely to fail before they become the next incident.
21 deterministic markers score every file across defect risk, maintainability, and static performance risk. Every repository can be traced from its headline score to the exact files and findings behind it.
No model in the scoring path. The same source and history produce the same result.
See the method- cross-project ROC AUC
- 0.74
- defect lift
- 2.3x
- self-check lift
- 3.3x
- deterministic markers
- 21
n = 2,826 · 21 repositories, 9 languages, 2,826 files · 2026-08
n = 2,770 · p = 0.003 · 2,770 files scored by both tools at the same leakage-free commit · 2026-08
16 of the 20 lowest-health files had a bug fix in the prior six months in the published self-check.
Structural, historical, ownership, test, and defect-history signals.
Real product evidence
The score is the entry point. The file-level evidence is the product.
The Code Health surface keeps the repository interpretation, score distribution, co-equal health dimensions, map, and ranked findings in one reading flow. A reviewer can move from the overall result to one file without losing the scope that made the number meaningful.
Capture: Repowise indexed at 3,687 files. The visible score and finding counts belong to that captured snapshot.
How the index produces it
Three signals stay separate until the evidence earns a conclusion.
Repowise computes the dimensions independently, validates defect ranking against bug-fix history, and keeps static performance findings distinct from runtime performance.
- 01 / Measure
Extract deterministic markers
Complexity, nesting, cohesion, clones, churn, ownership, prior defects, coverage, and static performance shapes are computed directly from source and history. - 02 / Rank
Calibrate defect risk
Offline weights rank files by later-defect likelihood. Maintainability and performance remain visible as separate dimensions instead of inflating the defect score. - 03 / Act
Move from score to worklist
Health maps, findings, hotspot context, and impact-for-effort refactoring plans point to the exact file and next inspection.
Honest limitations
Static analysis cannot observe production behavior.
The defect benchmark measures ranking under stated review budgets, not certainty for an individual file. Static performance checks are intentionally high precision and low recall, and they do not replace profiling or APM. Repowise ranks refactoring work but does not rewrite code automatically.
Questions, answered
The details behind the claim.
What does the code-health score actually measure?
Every file gets a single 1 to 10 score computed from 21 deterministic markers: McCabe complexity, deep nesting, brain methods, class cohesion (LCOM4), god classes, Rabin-Karp clone detection, change entropy, co-change scatter, ownership dispersion, prior-defect history, test-quality smells, and more. Lower scores mean the file is more likely to harbor defects.
How do you know the score actually predicts bugs?
It is defect-validated. On the same 2,770 files across 9 languages with real defect labels, ranking by repowise health surfaces 2.3x the defects of a leading commercial tool under the same review budget (recall 0.173 vs 0.074, effort-aware Popt 0.607 vs 0.462, ROC AUC 0.731 vs 0.705). Across 21 open-source repos the mean cross-project ROC AUC is 0.74 with a 95% confidence interval of 0.68 to 0.79, up to 0.90 on individual repos.
Does it use an LLM?
No. Scoring is fully deterministic: 21 markers with weights calibrated offline against a defect corpus. Only the learned constants ship, so the same code always produces the same score, in under 30 seconds on a 3,000-file repo. No cloud, no API calls, no drift.
How is this different from CodeScene?
Both score code health, but repowise is open source so every heuristic is inspectable and reproducible on your own repo, and the score ships inside a broader platform: an architecture-aware wiki, git intelligence, architectural decisions, agent provenance, and ten MCP tools for AI agents. repowise does not offer AI auto-refactoring.
Will it just flag big files?
No. The discrimination survives controlling for file size (partial Spearman rho of -0.16) and significantly out-discriminates both recent churn (+0.10 AUC) and prior-defect history (+0.12 AUC), with DeLong p below 1e-9.
Can it use my test coverage?
Yes. repowise ingests LCOV and Cobertura coverage to compute untested-hotspot risk (the intersection of low coverage and high hotspot score), alerts when a file's health starts declining, and ranks refactoring targets by impact for effort.
Can I prove these numbers on my own codebase?
Yes, that is the point. Every heuristic is open source under AGPL-3.0, and the validation runs on your own repo. On a typical project, 16 of the 20 lowest-health files had a bug fix in the last 6 months, 3.3x the 24% baseline.
Does repowise check performance?
Yes, as a static health pillar, not as an APM or profiler. repowise statically detects performance-risk shapes such as N+1 access and IO-in-loop patterns and scores them as a co-equal third pillar alongside defect risk and maintainability. It is high precision and low recall by design: it raises few findings, but the ones it raises are real. There is no runtime, no agent, and no tracing; it reads your source, like every other signal.
Does repowise refactor my code for me?
No, and that is deliberate. repowise ranks refactoring targets by impact for effort and alerts you when a file's health starts declining, but it hands you a human-readable, deterministic worklist; it does not open PRs or rewrite your code. The suggestions are template-based and inspectable, with no LLM editing your repo.
Last reviewed: September 2026
See whether the score finds the risky files in your repository.
Index a public repository free and inspect the score, its dimensions, and the exact findings that produced it.