

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.
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.
Three stages, all local — no external services required.
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.
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.
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.

No API keys, no cloud calls, no data leaving your machine. Model preferences can even be scoped to US-based-only models.
Built with Spring Boot, Spring AI, and Embabel. No Python required — a rare choice in the AI tooling landscape.
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.
Output quality is self-assessed before it reaches you. The system iterates internally until the response clears the quality bar.
Every component was chosen deliberately — prioritizing local execution, Java-native tooling, and agentic capability.
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.
Collaborate with AI to write a product brief — the what and why
Refine into architecture and approach
Generate granular, implementable specs
Build spec by spec — changes tracked, completed specs archived
Justin's candid takeaways from building Legacy Navigator with OpenSpec — what worked, what didn't, and when to go off-script.
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.
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.
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 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.
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.
Returns a layered summary: controllers, services, repositories — with file-level citations so you can trace every claim back to source.
Returns layer-by-layer change guidance covering model, controller, views, and persistence — a full vertical slice of what needs to change.
Diagrams are generated experimentally — they don't always render cleanly. This is itself a useful illustration of where LLM-generated structured output still struggles.
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.
AI Symposium · Chicago · 2026
Justin Montgomery
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