Most AI code reviewers only see the diff. They miss the real risks: a function rename that breaks 5 other files, a dependency change that shifts your architecture, a "small" PR that actually rewrites your auth logic.
We built a context retrieval engine that pulls in related code from across the repo before analysis. On complex PRs, it auto-generates Mermaid diagrams showing cross-file impacts.
Technical challenges:
1. Deciding which files are "related" without analyzing the entire repo every time (we use code graphs + call chains + git history)
2. Fitting it into LLM context limits (we rank by relevance and truncate aggressively)
3. Auto-detecting when to trigger deep analysis vs fast review (~35% of PRs end up needing it)
It's live now, free for all public repos. For private repos, we're trying to figure out a sustainable model: first 3 PRs get deep analysis free, then you choose between our always-free basic tier or a paid tier with persistent code knowledge graphs.
The controversial part: to do deep analysis well, we need to build a knowledge graph of your codebase (classes, methods, call chains). For private repos, this means storing structural metadata. Some teams are fine with this. Others want zero-knowledge architecture where even metadata is encrypted client-side.
Questions for HN:
1. What signals would YOU use to detect "this PR is complex enough to need deep analysis"?
2. Would you pay for code review tooling, and if so, what's your threshold?
3. Is storing structural metadata (no code content) acceptable, or is Zero-knowledge Storage the only way?
Most AI code reviewers only see the diff. They miss the real risks: a function rename that breaks 5 other files, a dependency change that shifts your architecture, a "small" PR that actually rewrites your auth logic.
We built a context retrieval engine that pulls in related code from across the repo before analysis. On complex PRs, it auto-generates Mermaid diagrams showing cross-file impacts.
Technical challenges: 1. Deciding which files are "related" without analyzing the entire repo every time (we use code graphs + call chains + git history) 2. Fitting it into LLM context limits (we rank by relevance and truncate aggressively) 3. Auto-detecting when to trigger deep analysis vs fast review (~35% of PRs end up needing it)
It's live now, free for all public repos. For private repos, we're trying to figure out a sustainable model: first 3 PRs get deep analysis free, then you choose between our always-free basic tier or a paid tier with persistent code knowledge graphs.
The controversial part: to do deep analysis well, we need to build a knowledge graph of your codebase (classes, methods, call chains). For private repos, this means storing structural metadata. Some teams are fine with this. Others want zero-knowledge architecture where even metadata is encrypted client-side.
Questions for HN: 1. What signals would YOU use to detect "this PR is complex enough to need deep analysis"? 2. Would you pay for code review tooling, and if so, what's your threshold? 3. Is storing structural metadata (no code content) acceptable, or is Zero-knowledge Storage the only way?
Site: https://jetxu-llm.github.io/LlamaPReview-site/
I'm here for the next few hours to answer technical questions or get roasted for my monetization strategy.