DEV Community

Cover image for From Code to Context to Decisions: Building GitLab Knowledge Navigator with GitLab Orbit
Surendra Kumar
Surendra Kumar

Posted on

From Code to Context to Decisions: Building GitLab Knowledge Navigator with GitLab Orbit

One of the hardest parts of software engineering isn't writing code—it's understanding code that already exists.

Every developer has experienced this:

  • You join an existing project.
  • You pick up an issue.
  • You search for a dependency.
  • You ask yourself:

Why does this exist?

Most tools can answer:

  • What does this class do?
  • Where is this function used?
  • Which files import this module?

Those are useful questions.

But the more valuable question is usually:

How did this get here?


The Real Problem

Repository knowledge isn't usually missing.

It's fragmented.

Some of it lives in:

  • Merge Requests
  • Issues
  • Commit history
  • Code relationships
  • Ownership
  • Architecture

Developers spend hours manually connecting these pieces together before they can safely make a change.

Traditional AI assistants explain code.

They rarely explain the decisions behind the code.


Why Repository History Matters

Imagine finding this line:

import httpx
Enter fullscreen mode Exit fullscreen mode

A normal AI assistant might explain:

"httpx is an asynchronous HTTP client for Python."

Technically correct.

But it doesn't answer the real engineering question.

The question is:

Why is this dependency here?

The useful answer is something like:

  • It was introduced to support asynchronous communication.
  • It replaced an older HTTP client.
  • It was added through a specific Merge Request.
  • Several components now depend on it.

That's repository intelligence—not just code explanation.

---Demo Video:- https://youtu.be/xLBaZ2sFMEI

Building GitLab Knowledge Navigator

To explore this idea, I built GitLab Knowledge Navigator for the GitLab AI Hackathon 2026.

The project uses GitLab Orbit as a knowledge layer instead of treating the repository as plain source code.

It combines:

  • Repository structure
  • Merge Requests
  • Issues
  • Ownership
  • Dependency relationships
  • Local code graph analysis

to answer questions grounded in repository history.

Some examples include:

  • Onboarding new contributors
  • Explaining architecture
  • Decision timelines
  • Change impact analysis
  • Architecture drift detection
  • Repository intelligence scoring
  • Executive engineering reports

The Hybrid Architecture

One lesson I learned during development was that repository intelligence benefits from combining different sources of truth.

The project uses:

Orbit Remote

  • Work Items
  • Merge Requests
  • Project members
  • Repository relationships

and

Orbit Local

  • Files
  • Definitions
  • Dependency graph
  • SQL queries through DuckDB

Together they provide both historical context and source-code structure.


One Feature I'm Particularly Proud Of

One workflow asks:

Why does this dependency exist?

Instead of producing a generic explanation, the tool reconstructs repository history using GitLab Orbit to explain the architectural decision behind the dependency.

That simple shift—from what to why—changes the conversation entirely.


Validation on a Larger Repository

To ensure the approach wasn't limited to its own codebase, I validated it on a fork of GitLab Runner.

The repository contains:

  • 1,366 files
  • 9,314 definitions
  • 58,340 indexed relationships

Running the same analysis demonstrated that the approach scales beyond a small demo project.


What I Learned

One observation stood out throughout the project.

The current state of a repository is only the final snapshot.

The real value lies in understanding the sequence of decisions that created it.

That applies to software architecture just as much as it does to any other complex system.

Code tells you what exists.

Repository history tells you why it exists.

Combining those two perspectives is where repository intelligence becomes genuinely useful.


Final Thoughts

AI is becoming very good at explaining code.

The next step is helping developers understand the decisions, history, and context behind that code.

That's the idea behind GitLab Knowledge Navigator.

Not just code analysis.

Repository intelligence.

From Code → Context → Decisions.


I'd love to hear how your team approaches repository onboarding and architectural knowledge sharing. Do you rely on documentation, tribal knowledge, AI assistants, or something else?

Top comments (0)