Show HN: Enola-A deterministic architecture graph for developers and AI agents
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?
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. D
本文内容来源于互联网,版权归原作者所有
查看原文