> ## Content Index > Fetch the complete content index at: https://fomo.observer/llms.txt > Use this file to discover other available public pages before exploring further. # GERT LÕHMUS: From a coffee in Vilnius to a developer infrastructure tool - URL: https://fomo.observer/gert-lohmus-from-a-coffee-in-vilnius-to-a-developer-infrastructure-tool/ - Published: 2026-08-14T08:31:41.000Z - Updated: 2026-08-14T11:44:14.000Z - Author: Gert Lõhmus - Tags: Dispatches, Founders, software, AI [Enola](https://enola.tech/?ref=fomo.observer)’s story started with a shared coffee in Vilnius, continued in Berlin, and eventually became a company founded in Estonia. Dejan and I met on a September day in Vilnius. We had coffee at Brew (a lovely cafe), talked about work and life, and, at some point, Dejan showed me one of his side projects, called Mulligan. It was a management system for golf clubs. I saw quite a lot of potential in it! Golf is an underserved market for software, and, more importantly, Dejan had already built something real. By the end of that conversation, we agreed on a simple next step: let’s work on it together for two weeks and see what happens. That soon became FairwayHub. We started with software for golf clubs and later built mobile applications for golfers. Around the same time, I moved to Berlin, where Dejan lives, so our Vilnius coffee turned into many more coffees in Berlin. A lot of our product development happened that way: meet, discuss an idea, build it, see if it works, repeat. We also both liked using the latest development tools. Claude and Codex quickly became part of how we worked. They helped us move faster, but as FairwayHub grew, the limitations also became more obvious. Our codebase was getting more complex. A change in the backend could affect the mobile application. A new module could introduce a dependency we did not want. Understanding how everything connected started taking more time. AI agents had the same problem, only more visibly. Every time they started working on something, they had to inspect the repository again, search through files, follow imports and calls, and rebuild an understanding of the codebase before they could do useful work. That did not make much sense to us. Codebase relationships are static until the code itself changes. If one module imports another, that is a fact. If one service calls another service, that is a fact. If a mobile application calls a particular backend endpoint, that relationship can be extracted from the source code. We were spending tokens and time asking AI to rediscover things that could simply be computed once and reused. For Dejan, this became a technical problem to solve. In early 2026, he built a small tool called archmcp. It was a local MCP server that extracted deterministic facts and relationships from the repository and made them available to coding agents. Initially, it was just something we used ourselves as we continued to build FairwayHub. But we kept using it. It became useful when we wanted to understand what depended on a particular part of the system, what could be affected by a change, or how different repositories connected. It also meant our coding agents could start with structural context rather than rediscovering the same repository each time. For a few months, archmcp remained a side project next to the golf products. We knew it was useful, but we had not yet worked out how far the idea could go. Is it a product? Eventually that part became clearer. The graph itself was not really the product. It was the underlying data that allowed us to answer a more important question: what happens to software architecture when more and more code is written by agents? Today we have tests for behaviour, linters for code quality, and CI pipelines to verify that software builds. But when an agent changes several modules, introduces a new dependency or modifies something across repositories, there is still a harder question to answer: what did that change do to the architecture? That became Enola. Enola is now an architectural quality gate for AI-assisted software development. It takes the existing codebase and builds a deterministic architectural model of the system: modules, symbols, dependencies, routes, services and the relationships between them. Developers and coding agents can use that model before making a change to understand the impact of the change they are about to make. After the change, Enola compares the new structure against the previous architectural state and identifies what changed. That can include new dependencies, dependency cycles, architectural boundary violations, coupling between parts of the system or structural changes across repositories. The same information is available to coding agents through MCP, to developers through the command line and inside CI pipelines. Teams can decide which findings they simply want to see and which ones should actually block a change. Enola also works across repositories. A client in one repository can be connected to an API route in another. Producers and consumers can be linked. Services can be analysed as part of the same architectural system instead of as isolated codebases. Importantly for us, the analysis remains deterministic. We do not use an LLM to guess the architecture. Enola extracts facts from source code and builds the graph from those facts. The AI layer can reason on top of that structure, but the underlying architectural model does not depend on probabilistic interpretation. It also runs locally, so source code does not need to leave the developer’s environment for Enola to build that model. We describe Enola as developer infrastructure for the agentic era. As coding agents become capable of writing more code and working for longer periods without direct supervision, we think teams will need a stronger layer around them that understands the architecture and can tell both the developer and the agent when a change is taking the system in the wrong direction. While developers sleep, you still keep building. We did not arrive at that idea by sitting down to invent a developer-tooling company. We arrived there while building another product and running into the problem ourselves. It started with FairwayHub, a few weeks of experimentation and a coffee in Vilnius. Then came many more coffees in Berlin, a small internal tool called archmcp and eventually Enola. We are still building together in Berlin. The coffee part has not changed much. \-- *Gert is building dev infrastructure for the agentic era as Enola's co-founder. A Senior Engineering Manager at N26, he has scaled data systems at tech companies like Vinted and Luminor.*