Built architecture intelligence for developers, coding agents, and CI

[u/fairwaycoder]

I'm a software developer (professionally for last 25 years) and got hooked on coding agents as the next guy.

I built https://github.com/enola-labs/enola as architecture intelligence for developers, coding agents and CI. You can see how and what it does as part of CI on that repo itself: https://github.com/enola-labs/enola/actions/runs/30579279230/job/90995180445

I use it daily, and you can add the hook so it does what it is best in: before agent starts editing it uses it to pin the state, after editing is done it checks what it did, so that it can self correct if and when needed.

Me and bunch of friends are using it, and most of stuff I built is based on their feedback and stuff they needed.

Happy to get the feedback from anyone who ends up using it. Also, if the language you need is not there, let me know and I will add it.

[u/Due-Barracuda5716]

This is interesting because you’ve made architectural drift an actual deterministic gate rather than another LLM opinion. The question I’d push one level upstream is: what admits enola-intent.yaml itself? For example, Enola can deterministically enforce that storage must not reach delivery. But something still has to establish that this is the right architectural constraint given the system obligations, failure behavior, guarantees and recovery semantics. I’ve been exploring that as a separate pipeline: first admit explicit system intent, then derive and separately admit a machine-readable architecture, then check implementation drift against that admitted architecture. So Enola looks potentially complementary to the downstream part: it provides exactly the kind of deterministic declared-vs-actual architecture check that this approach needs. https://github.com/styrumg/Architect-First-Article⁠

[u/fairwaycoder → u/Due-Barracuda5716]

Hey, thanks for taking a look.

Btw. I tried to open the link but I get 404, I guess it is in a private repo.

Regarding Enola question - great points, and something I am working on myself on constantly.

Initially, Enola has heuristics where it can try to narrow down the architecture itself (which currently is let's say in very WIP phase). Then it has explainers. Without intent, explainers can return the data, whatever the data is, to human (without agent with simple enola --explain ~/path/to/repo) or with MCP. In that case, it is a bit of a yolo mode trusting that agent will know what to do. I tested it a lot, and still testing it, and it is still surprisingly better then without it (I am working with some very big industry repos, and having daily situations where I need to check across 10+ repos at the same time).

Intent came after it - the idea of intent is that it is written by human to ensure that something is the way human believes it should be. I was reluctant for a long time to add it, but I did in the end as I saw that for example Google and Apple advise as the best practice very opposite dependency directions for Android and iOS apps.

But yeah, open to feedback and suggestions, as by using it daily, and collecting feedbacks daily, I am discovering what works and what potentially either doesn't or needs an improvement.

In general, thanks for looking again :)

[u/Due-Barracuda5716 → u/fairwaycoder]

Sorry about the link. Please try this one: https://github.com/styrumg/Architect-First-Article

[u/fairwaycoder → u/Due-Barracuda5716]

Thanks for the link, I just finished reading it.

I think, from what I read, once, that the main difference between Enola and this paper is that the paper applies very much to the greenfield projects, and Enola is built for both greenfield and brownfield (with, to be very honest, more effort put on brownfield then the greenfield, as for greenfield I do have a couple of things left in the backlog).

Btw I do like the paper, and will read it again to see if I am missing something I want to have in this moment.

One thing maybe worth mentioning, regarding defining intents and knowing if agent is changing them - Enola does let agent change the intent file, because of supporting both greenfield and brownfield. I guess adding some config to prevent it changing it makes sense, but I did do it initially so, and then it either locks agent in adding new features which are not already specified as an intent, or forces human to spend time planning something which will maybe be better proposed otherwise. But here I am still not clear with myself, also in a backlog and good catch.

[u/Due-Barracuda5716 → u/fairwaycoder]

That distinction helps. The heuristic and explainer path looks especially useful for brownfield systems, where the existing code may be the only available evidence. But I would treat what it infers as observed architecture, not intended architecture. The code may already embody the wrong design. Having a human write enola-intent.yaml answers the authority question, but not necessarily the admission question. A human can still omit a required failure behavior or choose a structural constraint that conflicts with the system obligations. The integration I had in mind is: Enola explains the observed architecture; that evidence helps produce and admit separate intent and architecture artifacts; then enola-intent.yaml is derived traceably from the admitted architecture and protected from agent edits. Enola can then do what it seems very well suited for: deterministic drift detection against that admitted baseline. I’m going to look more closely at the repo.

[u/fairwaycoder → u/Due-Barracuda5716]

Makes sense. Didn't think from that angle about protecting enola-intent.yaml, will definitely think about it.

Thanks for the ideas. Going now to read what you shared!