EXPLORE
Let's Connect
Legacy Navigator
What if you could ask a legacy codebase anything — and actually trust the answer?
Legacy Navigator is a locally-run CLI tool that ingests an existing codebase, builds a semantic understanding of it using vector embeddings, and lets developers ask natural language questions about how the code works — surfacing architecture, dependencies, and entry points that even experienced teams struggle to articulate. Built as a spec-driven development experiment using Java, Spring AI, and the Embabel agentic framework, it's as much about the process of building it as the tool itself.
Prototype by Justin Montgomery
nvisia AI Lab
The Problem It Solves
When you join a brownfield project, you're handed a codebase that evolved over years. You need to understand it before you can change it — but there's no map.
The Old Way
  • IDEs give you syntax, not meaning
  • Senior devs become bottlenecks
  • Slow, error-prone exploration
  • No answers to plain-English questions
With Legacy Navigator
Ask questions like:
"What would I need to change to add a new billing type?"
"Where does the checkout flow start?"
Get a conversational interface into that codebase — backed by actual code, not hallucination.
How It Works
Three stages, all local — no external services required.
1
Ingest
Point Legacy Navigator at a repository. It reads source files, chunks them, generates vector embeddings using a locally-hosted model via LM Studio, and stores everything in a JVector database — a flat file with no external services required.
2
Query
Ask it anything. The orchestrator routes your question to the appropriate agent — a code analysis agent powered by a locally-running Qwen Coder model. Responses include relevant file and class references.
3
Judge
A second lightweight local model acts as a quality judge. If the response doesn't meet a quality threshold, feedback is sent back to the analysis agent for another pass — up to 3 iterations.
What Makes This Different
Fully Local
No API keys, no cloud calls, no data leaving your machine. Model preferences can even be scoped to US-based-only models.
Java All the Way Down
Built with Spring Boot, Spring AI, and Embabel. No Python required — a rare choice in the AI tooling landscape.
GOAP Planning
Embabel uses Goal-Oriented Action Planning — an algorithm borrowed from game AI NPC behavior — applied to agent orchestration. Agents pursue goals through multi-step reasoning.
Model-as-Judge Loop
Output quality is self-assessed before it reaches you. The system iterates internally until the response clears the quality bar.
Tech Stack
Every component was chosen deliberately — prioritizing local execution, Java-native tooling, and agentic capability.
Java
Spring Boot
Spring AI
Embabel
JVector (Datastax)
LM Studio
Local Models
Docker
OpenSpec

All models run locally — zero cloud dependencies, zero data exposure.
Built Using Spec-Driven Development
This prototype was Justin's first hands-on experiment with OpenSpec — a spec-driven development methodology that treats AI coding sessions like a structured engineering process.
1
Proposal
Collaborate with AI to write a product brief — the what and why
2
Technical Design
Refine into architecture and approach
3
Task Specs
Generate granular, implementable specs
4
Implement & Verify
Build spec by spec — changes tracked, completed specs archived
Lessons Learned
Justin's candid takeaways from building Legacy Navigator with OpenSpec — what worked, what didn't, and when to go off-script.
Know What You're Building First
OpenSpec works best when the problem is well-defined. When you're still discovering the shape of the problem, you can generate more specs than working code — and you have to stop and steer.
Applicable for Brownfield Work
Spec-driven development is most valuable when maintaining consistency across a large, complex surface area. The structure pays dividends when the codebase is already sprawling.
Know When to Go Off-Spec
For simple tasks, going "off-spec" and asking an agent to just plan is often faster. The methodology is a tool, not a religion.
OpenSpec vs. GitHub Spec Kit
OpenSpec has less friction and suits greenfield exploration. Spec Kit has more process structure and is better suited for complex brownfield work where rigor matters more than speed.
Demo Snapshot
The CLI lets you select a codebase — multiple repos can be ingested — then ask questions in plain English. Here's what that looks like in practice.
"Give me an overview of the architecture."
Returns a layered summary: controllers, services, repositories — with file-level citations so you can trace every claim back to source.
"How would I add hairstyle support to this pet clinic app?"
Returns layer-by-layer change guidance covering model, controller, views, and persistence — a full vertical slice of what needs to change.
Mermaid Diagrams (Experimental)
Diagrams are generated experimentally — they don't always render cleanly. This is itself a useful illustration of where LLM-generated structured output still struggles.
What This Is (and Isn't)
Honest Assessment
Justin is candid: this tool is an experiment, not a polished product. GitHub Copilot with a local model would outperform it for most day-to-day code navigation.
What it demonstrates is the approach — not the artifact.
What It Actually Demonstrates
  • How to build a RAG pipeline for code
  • How to wire agentic evaluation loops
  • How spec-driven development shapes the process from idea to working software

The real value isn't the navigator. It's the methodology and the lessons learned building it.
🏛️ Part of the nvisia AI Lab Prototype Series
AI Symposium · Chicago · 2026
🎤 Presenter
Justin Montgomery
Let's Build Something Intelligent.
Whether you're exploring AI for your organization or want to learn more about the nvisia AI Lab prototype series — we'd love to hear from you.
nvisia AI Lab · AI Symposium · Chicago · 2026