Building with Ash, Before & After 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).

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 working on an elixir specific coding harness, and I’ve looked at this from a lot of different angles.

• Magic: raw phoenix has less, ash has more, llms don’t like magic
• Code: raw phoenix has more, ash has less. Llms like less, and humans too (to the op’s point)
• Resources: there’s more raw phoenix than ash to train models on, but that seems to be changing rapidly
• Derivation: you can derive loads of features from very little code in ash, which seems beneficial but I could also see it falling down

Thus far I’ve chosen to generate raw phoenix, but if I ever get space for a moon shot I’d love to harness ash generation

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.

I’ve done significant large scale/long horizon development tasks. I’ve experimented with a lot of different techniques. The most effective thing I’ve found to do is refine and generate bdd specs that define what the application needs to do, design your phoenix context architecture and let the model write code in that structure till the tests pass. Llms are extremely effective at writing phoenix apps in this context.