Repowise: Teaching AI Agents to Think Like Senior Engineers

Hook

Your AI coding assistant is burning through tokens reading entire files to answer simple questions. A tool that indexes your codebase once can cut those costs by 36% while actually improving context quality.

Context

AI coding agents like Claude Code and GitHub Copilot have a fundamental problem: they're context-blind. Ask them "where is authentication handled?" and they'll scan dozens of files, burning thousands of tokens on boilerplate code and outdated comments. Ask about cross-service dependencies in a microservices architecture, and they'll miss contracts defined three repositories away.

The naive solution—cramming more files into context windows—hits economic and cognitive limits fast. A typical "find all dependencies of this module" query on a medium-sized codebase might consume 50,000 tokens just reading files, costing real money on every interaction. Worse, the signal-to-noise ratio plummets as context windows fill with irrelevant code. Repowise takes a different approach: build structured intelligence layers once during indexing, then serve AI agents only the specific nodes, edges, and decisions they need through the Model Context Protocol (MCP). It's the difference between handing someone a filing cabinet versus a librarian who knows exactly which drawer contains the answer.

Technical Insight

Repowise's architecture rests on four intelligence layers, each solving a distinct class of context problem. The graph intelligence layer uses tree-sitter parsers to build multi-tier dependency graphs with symbol-level resolution across 14 languages. Unlike simple AST dumps, this layer tracks three relationship types: structural (class-to-method), semantic (function calls, imports), and cross-file (module dependencies). When an AI agent asks "what depends on this authentication function?", repowise returns a subgraph showing exactly which modules, classes, and functions reference it—no file-reading required.

The git intelligence layer mines commit history for behavioral patterns that static analysis misses. It identifies hotspots (files changed frequently, signaling instability), co-change patterns (files that always change together, revealing hidden coupling), and contributor profiles (who owns which subsystems). This temporal dimension answers questions like "which services are most fragile?" or "who should review changes to the payment pipeline?" The system runs entirely on local git history—no external API calls, no LLM invocations, completing in under 30 seconds even on 3,000-file repositories.

Here's where it gets interesting: the decision intelligence layer captures architectural rationale through inline markers and git history mining. Developers annotate code with WHY:, DECISION:, or TRADEOFF: comments that repowise extracts and links to specific code nodes. Combined with commit message analysis, this creates a queryable knowledge base of why the code looks the way it does:

# In your codebase
class PaymentProcessor:
    # DECISION: Use saga pattern instead of 2PC
    # TRADEOFF: Eventual consistency vs. distributed locks
    # WHY: 2PC deadlocks caused 3 outages in Q2 2023
    def process_payment(self, order_id: str) -> None:
        self._start_saga(order_id)
        # ... implementation

When indexed, repowise creates a decision node linked to PaymentProcessor.process_payment. An AI agent querying "why do we use sagas for payments?" gets the exact rationale without reading implementation details. This addresses the context-free problem that plagues AI coding agents—they see what the code does but rarely understand why it was architected that way.

The documentation intelligence layer generates LLM-powered wikis with RAG-based semantic search, but here's the twist: it uses the graph and git layers as grounding data. Instead of hallucinating docs from raw code, it combines symbol relationships, change history, and decision markers to generate context-aware explanations. The semantic search runs locally using embeddings stored in the SQLite intelligence database.

All four layers expose through nine MCP tools that AI agents query like API endpoints. The get_symbol_dependencies tool returns graph subsets, find_hotspots surfaces fragile files, query_decisions retrieves architectural rationale. Here's what an MCP query looks like from Claude Code's perspective:

{
  "tool": "get_symbol_dependencies",
  "arguments": {
    "symbol": "PaymentProcessor.process_payment",
    "depth": 2,
    "direction": "downstream"
  }
}

Repowise responds with a structured graph showing what depends on this method, two levels deep—maybe 200 tokens instead of 50,000 tokens of raw source code. That 27× token reduction translates directly to cost savings and faster response times. The research backing repowise showed 36% cost reduction and 19% faster wall-time on SWE-QA benchmark tasks while maintaining answer quality parity.

The workspace-level federation deserves special attention. In multi-repo mode, repowise indexes multiple repositories and enables cross-repo co-change detection. When Service A changes a gRPC contract, repowise detects that Service B always changes in lockstep and surfaces that dependency through MCP queries. This solves the microservices blindness problem where monolithic AI context windows can't span organizational boundaries.

Under the hood, repowise stores everything in a SQLite database with full-text search indexes and graph tables. The schema supports incremental updates via git hooks—after initial indexing, only changed files trigger re-analysis. Tree-sitter parsers handle the heavy lifting for symbol extraction, maintaining language-specific rules for Python, TypeScript, Rust, Go, and 10 other languages. The deterministic code health scoring uses 12 biomarkers (McCabe complexity, duplication detection via suffix trees, hotspot frequency) without any LLM calls, making it fast and cost-free to run in CI pipelines.

Gotcha

Initial indexing is repowise's Achilles heel. A medium-sized repository takes ~25 minutes to fully index all four intelligence layers, creating significant onboarding friction. You can't query anything until indexing completes, and for teams evaluating the tool, that wait time kills momentum. The documentation layer compounds this by making LLM API calls during generation—if you're indexing a large codebase, expect to burn through API quota and wait longer. There's no incremental "index what you need" mode; it's all or nothing.

The Python-only distribution creates adoption barriers. You need Python 3.11+ installed even if your primary codebase is TypeScript or Rust. While repowise analyzes 14 languages, it runs only as a Python package, forcing teams to manage Python environments alongside their development stack. For organizations with locked-down toolchains or Python-averse cultures, this is a non-starter. The lack of pre-built binaries or Docker images means every developer needs a working Python setup.

Documentation and decision intelligence layers depend on external LLM APIs (OpenAI, Anthropic) for generation, introducing ongoing costs and potential vendor lock-in. While the graph and git layers run entirely locally and deterministically, unlocking the full value requires paying per-token for wiki generation and semantic embeddings. If your LLM provider changes pricing or deprecates models, your intelligence pipeline breaks.

Verdict

Use if: You're building with MCP-compatible AI coding agents (Claude Code, Continue, or custom tools) on medium-to-large codebases where token costs are material, you have microservices or multi-repo architectures where cross-service dependencies are poorly documented, or you want to capture architectural decisions as first-class queryable artifacts rather than Confluence pages nobody reads. The 36% cost reduction alone justifies adoption for teams spending $500+/month on AI-assisted development. Skip if: Your codebase is small (<10,000 LOC) where naive file-reading works fine, you're not using AI coding agents at all and just want static analysis, the 25-minute indexing time breaks your rapid onboarding workflow, or you can't run Python 3.11+ in your environment. Also skip if you need real-time updates—the git hook sync works for typical dev workflows but won't catch changes until after commits.