elixir is also niche but I believe it also saves tokens, as Jose made a blog post about on why that might be so. But abstracting the functional into declerative achives what you said - greater offload. this new nondeterministic tool couples well with any kind of deterministic tooling. I think in the coupling the real intelligence emerges, it’s relational.

And to your last point, with proper context (usage_rules) llm’s mistakes boil down to a minimum. For example I had an issue where it would write good ash code except for interfaces - it would write regular functions inside the domain. With two new lines in usage rules it started writing interfaces with no problem.

In any case, my emphesis is in the coupling; I think elixir (and ash) vibe well with ai.

I’m digging out old thread here, but I’d say that LLM coding is big win for Ash. In my mind anything that decreases ‘code surface’ is big win for AI. There’s a lot of ways to mess up transactions/logic/authorization (any cross cutting concern really is a burden for AI), but with declarative approach it’s much better.
In my experience mistakes that AI makes with Ash are trivial (things don’t work) but once it plugs thing in correctly it usually works fine.
I guess what I’m trying to say it helps that with Ash you offload more work to the framework so AI code has less surface. Also perhaps maybe there’s tiny chance that declarative code burns less tokens (but this would very likely be offset by the fact that Ash is more niche so LLMs can make mistakes and run additional cycles).

I haven’t done any serious side-projects in a while. But something I did try on some small things here & there that turned out well, was to spend a lot of time vibe-coding markdown files with mermaid diagrams, descriptions of what the MVP should do, entity relationship diagrams for how the database schema should look. I only review the rendered markdown & diagrams, not the raw markdown that generate them.

This allows my 2026 attention span to still carefully comb through the details that matter, and the database schema which is easier to just plan up front and get right the first time than iterate on after valuable data is entered.

And when I have all that in the state that I want, I just tell the LLM to build it in vanilla Phoenix.

That’s the long way of saying I’ve tried a bit of the same @johns10davenport and I can confirm that at least for small side projects, the agents of 2026 do very very well at building Phoenix/LiveView code that they can also maintain over time.