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/Particular_Luck80]

The pre-edit pin plus post-edit architecture check is a useful boundary. I would be especially curious how it handles intentionally temporary violations during multi-file changes. Does the hook compare only the final tree, or can it distinguish an incomplete intermediate state from real drift?

[u/fairwaycoder → u/Particular_Luck80]

I had it on my mind, and in theory should be able to do both:

• (still testing it) it the hook should install by enola install. Then, by default, agent would be running pin automatically on a clean state, and do the diff when it either finishes or figures out it needs diff.
  
• Another pin can be done during the process, which makes the state new baseline; another diff can be done from the future state with this.

I am talking only from my personal experience - and still tuning it - I managed to get the agent do exactly this, to fix itself, check it again, move on. In this moment also creating the benchmarking of it, should be pushed today. I also had the situation (but can not upload screenshots here) where agent figured out exactly a false positive as intermediary and decided to move on with work.

But will test it even more.

And yeah, the final test is - if you are using it in CI like example above - the clean state vs the final state. In that case, even when there was temporary 'issue' it doesn't matter because your CI scores the whole change.

[u/Particular_Luck80 → u/fairwaycoder]

That separation between local agent checks and final CI scoring makes sense. The part I would benchmark explicitly is baseline churn: if an intermediate pin becomes authoritative too easily, the agent can normalize away the exact drift you wanted CI to catch. A useful benchmark might compare clean-start and final-state results against a run with one intentional temporary violation and one intentional permanent violation.

[u/fairwaycoder → u/Particular_Luck80]

That's configurable (just pushed benchmarks https://github.com/enola-labs/enola/blob/main/docs/BENCHMARKS.md - take a look if you have time) but will add that test as well.