Core Analysis¶

Project Positioning: code-review-graph addresses the problem of AI assistants re-reading large irrelevant parts of a codebase. It builds a Tree-sitter based code graph and computes the change’s blast radius, providing only the minimal context to the LLM via MCP.

Technical Features¶

• Static code graph: functions, classes, imports, calls and test edges are modeled.
• Incremental + hash checks: only changed files are re-parsed (example: 2,900 files re-index <2s).
• MCP integration: injects configuration so the AI reads only computed snippets.

Recommendations¶

1. Run code-review-graph build on a small repo to inspect outputs.
2. Enable the local GitHub Action in CI in report-only mode to measure savings and false positives.

Note: Static analysis can miss dynamic/runtime-generated calls—augment with tests or runtime tracing when needed.

Summary: For statically analyzable codebases, the project reduces LLM context size, token cost, and speeds up review feedback.

Core Analysis¶

Core Issue: blast-radius computes the minimal context by tracing callers, dependents and tests in the code graph so the AI reads only necessary files.

Technical Analysis¶

• Method: Start from changed nodes and propagate reachability via call/inherit/import/test edges (BFS/DFS).
• Under-approximation risk: Reflection, string-built calls, or runtime-generated code are missed by static Tree-sitter parsing.
• Over-approximation risk: Conservative inclusion of shared utilities that aren’t on actual execution paths.

Practical Recommendations¶

1. Enable and incorporate test coverage edges to reduce false positives.
2. For dynamic-heavy files, use runtime tracing or manual annotations (languages.toml/ignore lists).
3. Run in report-only mode in CI initially to tune thresholds.

Note: Treat blast-radius as a powerful heuristic, not an absolute ground truth; combine with tests/runtime data.

Summary: Blast-radius is effective for static dependencies but needs complementary strategies for dynamic codebases.

Core Analysis¶

Rollout Strategy: Use a phased, data-driven approach: Pilot → Monitor → Tune → Gate → Rollout.

Steps¶

1. Pilot: Run code-review-graph build and the CI Action (report-only) on a small repo or branch.
2. Measure baseline: Collect metrics: LLM tokens, model latency, number of files the PR requires reading, CI duration, and false-positive rate.
3. Iterate: Adjust languages.toml, ignore rules, and risk thresholds; add test-coverage edges to reduce false positives.
4. Gate: Once stable, configure the Action as fail-on-risk with monitoring.
5. Scale: Enable watch mode, CI caching and artifact reporting for performance.

Note: Keep report-only and audit logs initially to trace false positives/negatives.

Summary: Quantifying tokens/latency/PR file counts is key to ROI; gradual rollout minimizes disruption while delivering measurable benefits.

Core Analysis¶

Project Positioning: The project combines Tree-sitter + code graph to merge syntactic parsing with dependency modeling, enabling efficient affected-range computation and incremental updates.

Technical Features & Advantages¶

• High-performance parsing: Tree-sitter supports incremental parsing and many languages—good for low-latency editor/CI use.
• Natural graph model: Functions/classes/imports/tests as nodes/edges facilitate BFS/DFS to find call chains and test coverage.
• Extensible: Add languages via languages.toml without changing core code.

Trade-offs¶

1. Pros: Fast, cross-language, well-suited for blast-radius propagation.
2. Cons: Static graph misses reflection/string-generated calls; non-built-in languages require mappings.

Note: For codebases relying heavily on dynamic features, combine static analysis with tests or runtime tracing.

Summary: The architecture balances precision and performance, making it practical for large, mostly statically analyzable repos.

Core Analysis¶

Core Issue: Low barrier to entry but moderate learning curve to fully utilize. pip install + install + build shows quick wins; deep integration (CI gating, custom languages) requires understanding Tree-sitter, MCP, and mappings.

Technical Analysis¶

• Learning curve: Moderate; basic commands are friendly, advanced config (languages.toml, MCP hooks) takes time.
• Common pitfalls: Missed edges in dynamic languages, misconfigured ignores, platform hook differences requiring manual tweaks.
• CI notes: Requires Python >=3.10, runner permissions, and caching for performance.

Practical Tips¶

1. Pilot on a branch or small repo: run build + watch and inspect outputs.
2. Start CI in report-only mode and enable cache/artifact reporting.
3. Add and validate languages.toml for nonstandard languages.

Note: Constrained containers or restricted runners may need extra setup for dependencies.

Summary: Fast to get value, and careful gradual rollout minimizes operational risk.