Inspiration
Every one of us has had the same bad week: you join a team, clone a repo with a few hundred files, and you have no idea where anything lives. You need to add a header to the API gateway, so you spend the morning grepping through middleware/, gateway/, and proxy/, you ask in Slack, you get three different answers, and you still end up guessing. The guess gets reverted.
When GitLab shipped Orbit (the Knowledge Graph), we realized the data to fix this already exists. Orbit indexes a repo into a real code graph. Nobody had put that intelligence directly in front of a developer who is just trying to figure out where to start. So we built RepoCompass.
What it does
RepoCompass answers the three questions you actually ask when you touch unfamiliar code:
- Onboard me to this component. It ranks the key files by how much they define, lists the languages in play, the recent merge requests, and the owners.
- What is the blast radius if I change this file? It traverses the real IMPORTS and CALLS edges in the Orbit graph to find every downstream consumer, then gives you a risk level instead of a guess.
- Who owns this and who should review my change?
It runs as one slash command inside GitLab Duo and replies with a short Markdown report. No dashboard, no context switching.
How we built it
The core is a Python agent with three data sources behind a clean adapter layer: the real GitLab Orbit graph (queried over its DuckDB store and the orbit CLI), the GitLab API for merge requests and CODEOWNERS, and a local code graph as a fallback so the agent still works offline. Everything returns typed Pydantic models, and the renderers turn those into the Markdown you see in Duo.
We took the production parts seriously: a circuit breaker, retry with backoff, and a rate limiter on every external call, structured logging and metrics with zero extra dependencies, 128 tests including property-based ones, and a green CI pipeline with lint, strict type checking, coverage, and a dependency audit.
Challenges we ran into
The honest one: our first Orbit integration was a guess. We wrote against REST endpoints we assumed existed. When we found the real Orbit, which is a CLI that indexes a repo into a DuckDB graph, we had to throw that away and rebuild the adapter against the actual gl_file, gl_definition, gl_imported_symbol, and gl_edge tables. The adapter pattern is the only reason that swap did not ripple through the whole project.
The second one was making blast radius mean something. Fuzzy string matching is easy and useless. Doing it properly meant resolving the change description to real graph entities and then walking the dependency edges.
Accomplishments we are proud of
It is genuinely grounded. When RepoCompass says src/models.py has 11 downstream consumers and the change is high risk, that came from the real graph, not from a language model making something up. And it ships: the agent is published and public in the AI Catalog, and the repo is MIT licensed with a green pipeline.
What we learned
The mock mode we almost skipped turned out to be the most important feature. Anyone can clone the repo and see exactly what the agent does with no API keys and no setup. For a hackathon, that is the difference between "looks cool" and "I tried it and it works."
What's next
Symbol-level call-graph ranking on top of Orbit's CALLS edges, multi-project blast radius across service boundaries, and iterating on the published agent from real user feedback.
Log in or sign up for Devpost to join the conversation.