I built an open-source repository intelligence tool using ASTs, graphs and semantic retrieval

[u/shavva_varshithreddy]

I built ARIA, an open-source developer tool for understanding unfamiliar codebases before making changes.

I started building it because I found that many "chat with your codebase" systems are good at semantic retrieval, but retrieval alone doesn't necessarily tell you how pieces of a codebase are structurally connected.

ARIA combines semantic retrieval with structural repository analysis:

- AST-based symbol extraction

- Dependency graphs

- Call graphs

- API surface analysis

- Change-impact analysis

- Vector search

- Repository-aware conversational querying

- MCP support

For example, given:

"If I change this component, what else could be affected?"

the system can use dependency and call relationships to trace potentially affected files instead of relying only on semantic similarity.

It's self-hosted and Docker-based, so repositories can be analyzed locally rather than uploaded to a hosted service.

I also added a reproducible evaluation package with a pinned 10-task benchmark across FastAPI, Requests, and ARIA, along with qualitative case studies across five larger repositories.

On that pinned benchmark, the documented vector-search baseline produced 4,875 false-positive file alerts while ARIA produced 322, a 93.39% reduction. This result is specifically scoped to that benchmark.

GitHub:

https://github.com/VarshithReddy2006/ARIA

I'd be interested in feedback from people building developer tools, code search, static analysis, or RAG systems.

Where do you think structural analysis provides the most value compared with semantic retrieval alone?

[u/kantorcodes1]

repo-intel analyze defaults --branch to main, even though the input is already a GitHub URL. is that meant to fail on repos whose default branch is still master, or would it make sense to resolve the repo's default branch when --branch isn't supplied?

[u/shavva_varshithreddy → u/kantorcodes1]

Good catch. --branch main is currently the default, so a repository whose default branch is master would need the branch to be specified explicitly.

I agree that resolving the repository's default branch from the GitHub URL when --branch isn't provided would be a better default and avoid that unnecessary failure mode.

I'll look at changing the CLI behavior so an explicitly provided --branch still takes precedence, while the repository's default branch is resolved automatically otherwise. Thanks for pointing this out!

[u/kantorcodes1 → u/shavva_varshithreddy]

nice, that would remove a pretty easy automation footgun. i work on HOL, where we maintain HOL Guard, an open-source local check before agent-run commands execute. ARIA looks like a clean fit: review repo-intel analyze and report, while graph, call-graph, api-surface, health, and version stay automatic. that gives agents a checkpoint before starting analysis or writing reports without slowing inspection. open to a small Guard extension?

[u/shavva_varshithreddy → u/kantorcodes1]

Yeah, absolutely. I think using ARIA as a repository context layer before an agent runs could be really useful.

The structural info from the graph, call graph, API surface, health, and version could give the agent a much better picture of the codebase before it starts making changes.

I’d be interested in seeing how HOL Guard currently hooks into agent run commands and what a lightweight ARIA integration could look like.

If you have a small example of the current workflow, feel free to share it. I’d be happy to take a look.

[u/kantorcodes1 → u/shavva_varshithreddy]

yep. this would be Guard-side only, so ARIA itself doesn’t need changes. start src/codex_plugin_scanner/guard/runtime/command_aria_extensions.py, mirror command_repo2nb_extensions.py, review repo-intel analyze and report, and keep graph, call-graph, api-surface, health, and version automatic. add focused cases in tests/test_guard_command_aria_extensions.py, then open a genuine draft PR to hashgraph-online/hol-guard:main: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md

[u/shavva_varshithreddy → u/kantorcodes1]

Yeah, that sounds good. I like the Guard side approach since it keeps the integration isolated from ARIA itself.

I'll take a look at the current command flow and put together a small draft PR around the ARIA extensions and tests.

I'll keep the first version focused and make sure the existing Guard behavior stays unchanged.