Together with a friend, we were developing a golf application. Our codebase grew rapidly and became split between multiple repositories: the iOS app, Android app, backend, front-end, and extra tooling. Both of us also work in larger scale-ups, and we saw the same problem: understanding large distributed codebases becomes progressively harder. Yay for microservices.

It takes time to understand and answer questions like: - What calls this function? - What is the impact of changing this interface? - Is this code actually reachable and used?

Not a secret that both of us embrace the leverage AI coding agents bring. But … AI agents spend a surprising amount of time understanding and rediscovering architecture. For them, architecture is a result of greps and, at times, assuming dependencies. With a new session, they rediscover the architecture again. Yet, architecture is deterministic. To introduce any changes, you need to understand the architecture.

Over months, we optimised and built Enola to manage that hurdle.

Enola is an open-source architecture engine that exposes an MCP server. Index any codebase into a persistent knowledge graph. If needed, combine multiple repositories into a graph of graphs. While constructing the graph, Enola parses the repository without using an LLM. The graph is built deterministically from source code. Outcome: A structured, deterministic architectural model of your system (a collection of multiple repositories).

Why open-source? Our goal is to provide engineering tools to manage the “code inflation”. There is a lot more code being produced, and codebases grow faster and faster. But the architectural integrity is still needed. Enola exists because software engineering still begins with understanding a system before changing it.

Key Features* (subset):

1. Impact Analysis: Determine the "blast radius" of a change by querying the graph of relationships between symbols, modules, and API routes. Simply ask: “If I change this, what breaks?” 2. Dead Code Discovery: Identify unused code paths and orphaned components that aren't reachable through your defined entry points. 3. Dependency Analysis (We called it traverse, because why not): Trace the dependencies, both downstream and upstream. You can simply ask Enola: “What depends on X?” 4. Multi-Repo Context: Enola supports a "graph of graphs," allowing you to index and query relationships across as many repositories as your architecture requires. So stack them up! 5. Performance: Enola runs fast, given its architecture, naturally depending on your codebase. Give it a try! Curious.

We are open-source, building in public. You can find the documentation and source in the link above.

If you have a complex codebase and would be willing to test Enola, I’d appreciate the feedback. Tell us what works, what is missing.