Git intelligence
Your history already knows where the risk is.
Hotspots, hidden coupling and who really owns what, read straight from git. The signals a snapshot of the code cannot show.
Deterministic, from history alone. It reads commits; it does not watch people.
See hotspots on a real repo- hotspot threshold
- Top 25%
- bus-factor threshold
- >80%
- ownership source
- Blame
- LLM calls
- 0
Files in the top quarter of both churn and complexity.
Single-author ownership above this marks key-person risk.
Git blame only. No plugins, no instrumentation.
Every signal is deterministic from history and the graph.
In plain words
Your history knows which code costs you time.
Static analysis sees the code as it is. Git sees the code as it is worked on. Repowise joins the two: how often a file changes, how hard it is to change, who changes it, and which files move together even when nothing in the code connects them.
hotspot · payments/processor.py
41 commits in 90 days. One owner. Changes with routes.py 8 times in 10.
How to read it
How to read the signals
- Hotspot
- In the top quarter of both churn and complexity. Complex code you never touch is not a problem; this is.
- Hidden coupling
- Two files that change together in most commits with no import between them. Touch one, check the other.
- Key-person risk
- One author owns more than 80 percent of a file. If they leave, so does the knowledge.
- Cold
- Rarely changed, whatever its shape. Leave it alone.
Sound familiar?
The code is not the whole story.
- 01
“Two files always break together and nobody knows why.”
- 02
“One person understands the payments module.”
- 03
“Effort goes to the loudest code, not the riskiest.”
What you get
What the commits have been telling you all along.
- Hotspots
Files that change often and are hard to change.
The top quarter of both churn and complexity, where defects concentrate.
- Hidden coupling
Files that move together with no import between them.
The coupling the dependency graph cannot see, so you know what else to touch.
- Ownership
Who owns each file, and where one person owns too much.
Primary owners from blame, and the files at risk when someone leaves.
- Reviewers
The people who own the code in a change's path.
Suggested from the blast radius, not from a rota.
On a real repository
The files that change most and are hardest to change.
The hotspot view ranks files by churn and complexity together, with ownership beside each one, so the team sees where effort and risk actually concentrate rather than where the loudest linter fires.
Capture: hotspots for the Repowise repository.
How it works
History, joined to structure.
Git tells you how the code behaves over time. The graph tells you how it is built. The useful signals live where the two meet.
- 01 / Read
Walk the commit history
Churn, co-changes and blame for every file, with no instrumentation. - 02 / Join
Combine with the parsed structure
Churn meets complexity; co-change meets the import graph. - 03 / Rank
Surface what to look at first
Hotspots, coupling pairs and key-person risk, ordered by impact.
Where it shows up
What changes about your day.
Hotspots, co-change pairs, owners and bus factor for the repository, with the files at risk when one person leaves.
DashboardThe risk tool tells the agent a file is a hotspot, who owns it and what usually changes with it, before it edits.
Coding agentsA pull request that touches a hotspot names the owner as a reviewer and lists the co-change partner it left out.
Pull requests
Honest limitations
History reflects the team, not the truth.
Squashed commits, rewritten branches and shared accounts blur ownership and churn. The signals are strongest on repositories with honest history.
Common questions
Everything people ask before they try it.
What is a hotspot?
A hotspot is a file in the top 25 percent of both churn and complexity. Churn comes from your git history, complexity from the parsed code. Files that are both change a lot and are hard to reason about are where defects concentrate, so repowise ranks them first. The signal is fully deterministic, computed straight from history with no LLM.
What is hidden coupling, or co-change?
Hidden coupling is a pair of files that repeatedly change together in the same commits without an import edge between them. Your dependency graph never sees this relationship because there is no code link, but git history reveals it. repowise surfaces these co-change partners so you know which files you probably need to touch together, even when nothing in the code says so.
How is bus factor calculated?
Bus factor flags files owned more than 80 percent by a single author. Ownership is derived from git blame: repowise attributes lines to contributors per file, identifies the primary owner, and marks any file where one person holds over 80 percent of the code as key-person risk. It is the part of your codebase most exposed if that person leaves.
Where does ownership come from?
Ownership comes from git blame, nothing else. repowise reads your existing history to compute the primary owner and the top contributors for every file. There are no IDE plugins, no instrumentation, and no developer surveillance. It reads commits, it does not watch people.
Does it use an LLM?
No. Every git-intelligence signal is deterministic: hotspots, co-change coupling, ownership, bus factor, module health rollups, and reviewer suggestions are all computed directly from your git history and dependency graph. The same history always produces the same result, with no cloud calls and no drift.
How is this different from static analysis?
Static analysis sees a snapshot of the code as it is right now. repowise sees how the code actually evolves over time, which is where risk and knowledge concentration really live. A linter cannot tell you that two unrelated files always change together, who is the only person who understands a module, or which files defects keep landing in. History can.
What are reviewer suggestions based on?
When you change a set of files, repowise computes the blast radius, the dependents that change could affect, and suggests reviewers from the ownership of that file list. Instead of guessing who should look at a pull request, you get the people who actually own the code in its path, derived from git blame and the dependency graph.
Can I see this on a real repository?
Yes. Every signal is open source and runs on public repos in the Explore section, so you can inspect hotspots, ownership, co-change pairs, and module health on real codebases before pointing repowise at your own. The same numbers are reachable by AI agents through the get_risk and get_context MCP tools.
Last reviewed: September 2026
Ask your history where the risk is.
Index a public repository free and see its hotspots, hidden coupling and key-person risk in a few minutes.