u/yellow-llama1

We added Svelte support to Enola, and we’d like to understand what we missed.

We built Enola because faster code generation creates a new problem: architecture can degrade just as quickly.

This meant that a simple change can introduce coupling, cycles, or rework that only becomes obvious much later. That gets more important as we allow coding agents to work more autonomously.

So we tackled it with enola - architectural regression testing for AI-assisted development.

To test the Svelte support, we ran it against Hugging Face Chat UI, Cobalt, and other well-known open-source repositories. But we surely missed something.

Chat-ui output:

Architecture
  Pattern:             (none detected)
  cyclic dependencies         1
  layer violations            0

Impact analysis (hotspots)
  coupled modules            59
    high criticality         37
    medium criticality       22
  Top hotspots (by coupling):
    module                            fan-in  fan-out crit     blast radius
    src/lib/server                       272       67 high     92
    src/lib/types                        215       35 high     92
    src/lib/utils                        156       62 high     90
    src/lib/components/chat               36      141 high     12

Code health
  god classes (high fan-in)     13
    src/lib/server.authCondition                 29 dependents
    src/lib/server/api/utils.superjsonResponse   20 dependents
    src/lib/utils.requireAuthUser                12 dependents
    src/lib/utils/scroll.StickToBottomControlle… 12 dependents
  call-graph hotspots        22
    src/lib/utils/scroll.StickToBottomControlle… fan-in 7 / out 7
    src/lib/utils/scroll.StickToBottomControlle… fan-in 8 / out 6
    src/lib/utils/scroll.StickToBottomControlle… fan-in 5 / out 9
    src/lib/utils.requireAuthUser                fan-in 12 / out 3
  deep dependency chains      9
    src/routes/settings/(nav)                    depth 10
    src/routes/conversation/[id]                 depth 9
    src/routes/models/[...model]                 depth 9
    src/routes/r/[id]                            depth 9
    src/routes/settings                          depth 9
  large public surfaces       1
    src/lib/types                                62/63 (98%)
  complexity outliers        15
    src/lib/server/textGeneration/mcp.runMcpFlow complexity 200
    src/routes/conversation/[id].POST            complexity 144

If you work with Svelte or SvelteKit, help us understand where it doesn’t work, and what we should support next. Or contribute yourself!

https://github.com/enola-labs/enola - Apache 2.0, fully local.

I came across a post from Mark Richards today that made a point I strongly agree with:

>One thing agentic code generation is missing is taking architectural concerns into account.

I’m curious how people here think we should actually approach this problem.

I doubt an .md file alone can solve this. It can describe architectural intent, but the agent also needs to understand what actually exists in the system: dependencies, boundaries, coupling, calls, data flows and other structural constraints.

So how should an agent know whether the change it is about to make improves or deteriorates the architecture?

Interested particularly in what people are already trying in real codebases.

Mark Richards' original post:
https://www.linkedin.com/posts/markrichards3_one-thing-agentic-code-generation-is-missing-share-7494404028122955776-Uf5v/

I asked moderators about whether I can post this. They said yes, but if you feel different let us know.

---

We just added Scala support to Enola (open-source). A tool to maintain codebase quality for any Scala project

Most architectural problems start with a PR. The mistakes may not be obvious at the time, but without knowing, it carries architectural debt.

By the time the codebase feels wrong, it usually already is. That's what my co-founder and I saw. So we tackled it.. As best as we could 😄 The problem has only exacerbated with agentic development.

Enola is an open-source architectural quality gate that checks developers or agents changes as they happen. What do we measure?

Example of an output:

Architecture
  Pattern:             go-standard (95% confidence)
  cyclic dependencies         0
  layer violations            0

Impact analysis (hotspots)
  coupled modules            36
    high criticality         20
    medium criticality       16
  Top hotspots (by coupling):
    module                            fan-in  fan-out crit     blast radius
    internal/facts                       152        0 high     68
    pkg/bootstrap                          8       49 high     4
    pkg/command                            1       42 high     1
    internal/engine                        7       27 high     7

Code health
  deep dependency chains      8
    cmd/enola                                    depth 10
    pkg/command                                  depth 9
  complexity outliers        15
    internal/server.Server.registerTools         complexity 177

Now we are looking for feedback and contributors to improve Scala performance. If you work with Scala, run it against something real. I’d like to know what it misses and is it useful. The more messy the better.

https://github.com/enola-labs/enola (Fully local, Apache 2.0, installation takes 2 minutes).

I was taken aback over the week about a phrase I heard mentioned in a conversation: "I ran out of tokens, I cannot work anymore."

This caused me to think a lot and long about, where are we heading. I thought to share my writing on Substack and start a discussion. Is this something that engineering leaders are seeing?

Hey r/GolfPH  community! 

Together with you, we launched our first App!

Why we started this

When we, together with a friend, started building Fairway, a Golf Journal & AI Coach, we knew what we did not see in other applications out on the market. Many of them felt a bit shallow or overly cluttered with ads and upsells. 

We felt most apps optimise for usage, not improvement. More rounds, more stats collected, more features, but very little helps you actually answer:

>

So we built something more focused on improvement, reflection, and understanding our own game over time.

Finally, we are proud to say, Fairway is LIVE!

The r/GolfPH community helped us shape the product, we got incredible feedback from so many of you, and that was inspiring.

What’s different in Fairway

• A journaling-first approach to golf
• Focus on mindset, decisions, and patterns
• AI coach that builds on your data
• Designed to feel calm, not cluttered

What we’re still figuring out

• How to combine AI Coach with a real coach
• How to adapt the experience for different skill levels
• How to make this part of a golfer’s normal routine

Download link(if you wish to test it out):

• App Store: https://apps.apple.com/ee/app/fairway-golf-journal-and-coach/id6761389666
• Android: https://play.google.com/store/apps/details?id=com.fairwayhub.mygolfjournal

Thank you for your support! If you wish to share more feedback, please feel free to DM!

Website: fairwayhub.club/journal

PS! If you cannot download it, let us know, could be some country limitations.