Analyzing GitInsight-AI: Irony in Static Analysis & Finding Unreachable Files

[Brijuval]

Hello Repowise Team!

I recently ran repowise on my personal project GitInsight-AI (an autonomous codebase graph explorer and agent platform). Since my project also focuses on AST parsing and dependency graphs, I was curious to see how Repowise’s graph engine would analyze it.

Here is what I found after running repowise init --index-only:

• Files/Symbols: 9 files, 91 symbols, 109 nodes, 193 edges.
• Average Health: 7.0/10
• Worst File Health: gitinsight/scanner.py (Score: 3.9/10)
• Dead Code: 1 unreachable file (scratch_scan.py with an in_degree of 0).

What Surprised Me & Key Reflections:

1. The Irony of Scanner Complexity:
   It was highly ironic that gitinsight/scanner.py—the very engine responsible for parsing AST imports in my project—was flagged as the least maintainable module in the repository with a health score of 3.9/10.
   Looking closer, the complexity makes sense: it contains custom AST node traversals mixed with JS-regex fallback patterns to support multiple languages. Repowise correctly surfaced this complexity, indicating it is a prime candidate for refactoring (e.g., decoupling the Python AST scanner from the JS regex compiler).

2. Dead Code Pinpointing (scratch_scan.py):
   repowise dead-code successfully pinpointed scratch_scan.py as an unreachable file due to in_degree=0. This was a scratch file left over from early prototyping.

3. Value for AI Coding Agents:
   For AI tools (like Cursor, Claude Code, or custom MCP servers), keeping dead code out of context windows is critical. Having a local indexer that flags scratch_scan.py as dead and warns about complex core modules (like scanner.py) allows agents to query code far more efficiently without wasting tokens reading orphan files.

Really impressed by the speed of the local PageRank/betweenness centrality calculations. Looking forward to diving deeper into the indexing architecture!