Having used Elixir for multiple years on something other than a server application, I disagree with calling Elixir a general purpose programming language. It’s really good for writing servers, I’ll give it that, but for stuff that isn’t an always-on network application, I felt the OTP way of doing things was designed for something I wasn’t building. Elixir makes it very easy to build servers, but the language and community are very biased towards client/server use cases. It certainly can be used for things other than server, much like I could build a web app using QBasic or Excel. The focus of the language, its history and the community around Elixir has always been server apps. To me, that’s the biggest indicator that it’s a specialized language rather than a general purpose language.
Tried Pheonix framework / Elixir in Cursor out of curiosity last weekend and it was the best experience I’ve had so far with agentic coding. I don’t know either yet — purely an experiment. My instructions doc required TDD, a feature list, had links to pheonix/elixir/tailwind/postgres doc and sonnet 4 did a great job utilizing pheonix cli which reduces a lot of boilerplate generation. Proved changes worked with tests at each iteration. The key thing was it didn’t lose its bearings as the project got more complex. Other web app frameworks I’m familiar with invariably get lost adding npm packages left and right, fiddling with config files and wrapped in an “extension cord” needing rescuing. I think there is something to so many node world version changes and approaches in framework implementation in training data that pollute the decision making. Also I realized watching sonnet construct the project was actually a really compelling way of learning a new framework/language to me. I can stop and ask “why are you doing this? how does that work?’ and inspect the code. Made me interested in learning more about elixir.
I have been arguing for a while that very strict languages with a heavy type system are ideal for agent coding.
The stricter the language, the harder it is for the LLM to produce nonsense, at least if it can get compilation errors and run tests. And the easier it is to validate that the output is correct, because the types already tell a lot of the story.
A language with dependent types, linear types, etc... would be ideal, but alas...
At the moment Rust is the sweet spot. Fairly popular (and hence known to LLMs and with a fairly good ecosystem), great error messages to guide resolution of problems, stricter type system and more compile-time guarantess than almost all of the other semi-popular languages...
Now Rust isn't trivial to write, for both humans and LLMs, and the output was pretty bad for a long time.
But with the ability to run `cargo check` and execute tests, even the current first iteration of agents is really quite good at iterating until it gets a working result.
Windfall, for those who want it.
LLMs were fantastic for writing a project[0] in a new, niche language[1]. They help write any missing libraries. They help iterate when I get stuck on language aspects. They explain concepts as well as the median SO post, and much better than the posts that don't exist.
[0] https://github.com/TedSinger/chatfile/
[1] https://crystal-lang.org/ - quite pleasant
I think the core insight of this article, and it's something I haven't thought about before in this way, is that any successful programming language needs to "market itself" to LLMs and LLM developers.
We had the "first wave" of languages that were marketed to decision makers (Java), the second wave that was marketed to developers (Ruby on Rails, Rust), I think a third wave is coming, where the language will be designed to be LLM friendly from the ground up.
Ive seen some new tools use “docs for LLMs”, maybe Elixir / Phoenix can provide these if they haven’t already.
Functional programming works great on LLMs because there’s no hidden side effects. I let my LLM tools write functional style NodeJS but that’s only because Node is easiest to test with.
> any library can include a usage-rules.md file - essentially very terse documentation designed specifically for LLM context windows, explaining what to and what not to do when using the library.
This is useful for humans too, though personally i hope we go away with context window limitations in the future - perhaps context windows could be something like 'CPU registers' that the CPU likes to work with internally but there will also be an external "large" memory that LLMs can access and work with.
Claude is reasonably good at Elixir in my experience, but gets a bit carried away with logging. Gemini is quite shit. o3 is pretty great - but I mostly use it to review things when I get stuck with claude.
It definitely feels like Gemini has been fine-tuned to ace the react benchmarks.
With tidewave the LLM has access to iex, it can do its own repl loop debugging and investigations, its awesome - Elixir will thrive in the age of LLMs
It turns out that I don’t know Elixir at all, but I’m vibe coding an app in it.
I didn’t ask what language or framework to use. I “heard of Elixir on a blog post, or they saw this article topping the hacker news charts.”
I even asked an LLM what else I should consider besides Phoenix, but after considering, I stuck with it.
Gemini gets stuck sometimes, but I just ask ChatGPT to help and bust through.
It kind of reminds me of when I wrote code and couldn’t easily see the errors. Another pair of eyes can really help. Another LLM that didn’t write the code can really help, too.
My experience, even though rather limited, tells me that llm’s work well with languages like Elm and Rust, with powerful static analysis and great compiler ux.
The Claude models are so far ahead of the pack right now with Elixir and Erlang capabilities, comparing with o3, gemini2.5, grok3-think, and ds-r1.
Elixir is so good for workflows and pipelines, utilizing all available hardware resources. It makes sense why Elixir will be used more going forward for agentic workflows, but the greenfield engineers/architects are rushing to market with Python and here we are.
Good article as it gives advice on what to do proactively as a community to assure your relevance in these LLM times. The steps taken of small, compressed 'LLM docs' make me think of ideas of the semantic web. That one never gained traction but as search more and more gets replaced by AI (even by enterprises formerly primarily identified with search) strategies like this become more and more relevant.
I've been using Elixir with Gemini for the past couple days, and the LLM is less successful than it has been with other languages I use. It gets stuck sometimes - for example it couldn't figure out how to use a JWT encoding/decoding library so I needed to intervene. Have I already gotten this spoiled by uncanny performance with Go/Ruby and especially JS/TS?
I have been using LLMs to write Elixir full time at work for months now. AMA, if anyone is interested.
I sometimes have different thoughts of approach than Zach, but this post really resonates with me. I've been in Elixir full time for over 10 years and would love to see an evolution in its adoption fueled by this.
We will start to see the emergence of frameworks and libraries (and languages?) that are optimised for LLM coding rather than human coding. Maybe - overly verbose and repetitive, but easy to generate correctly and very flexible? Or maybe super obscure syntax that allows an LLM to output much more information per token emitted?
At lot of current paradigms are about things like abstraction and DRY that matter to humans creating and maintaining a code base. An agent driving some LLMs will have other priorities.
The bias towards frameworks and languages for which there is most abundant code is not only real, but self-reinforcing. As "vibe coding" (I hate that term) devs crank out AI-generated code and make it available to be trained on, LLMs will see more of that code and therefore be more likely to recommend those same code pathways.
This also makes it much more difficult for new, better, and innovative ideas to break through the noise floor.
Elixir and Phoenix is my tech stack of choice for many years, nearly a decade now.
The two thorns that remain:
1. The Phoenix Form <> changeset story is still quite tricky, even to me. It's very 'yappy'.
2. Elixir not having types hurts when a project grows. Even typespecs help very little. I wish we had proper types and let the computer flag stuff.
In his ElixirConf EU 2025 presentation [1], Chris McCord demonstrated Phoenix.new [2], an LLM-augmented VS Code in a browser that knows how to build Elixir/Phoenix apps.
McCord began by reviewing the current scripted and templated Phoenix code generator. He then showed how a tool-invoking LLM agent could be implemented in one screen of Elixir code. The bulk of his talk demonstrated generating apps with the Phoenix.new tool. It was interesting to see the tool generate development plan and begin coding to implement the plan.
I was fascinated to hear McCord explain and critique the LLM agent as it generated a Phoenix app.
"[It's] going to come up with a plan for our app and codify that into a Markdown file."
"Now it's going to take our high-level plan and make it into an expanded plan for us and itself."
"You can say, 'I changed the plan; execute the plan.'"
"We just recursed in the server and we did a req post. It's doing a req post right now and the tokens are coming back!"
"The agent just invoked a tool, which is 'I'm going to create a file.'"
"Hopefully it does a 'surgical modify tool,' which makes it not have to modify the whole file."
"A run-time error! Oh, no! Live coding is terrible. Oh, wait. It knows I need to add some missing functions here."
"You would be like, 'Oh, no, the page broke. What happened? I'm going to look at this error.' We just send that thing back to the chat completions endpoint and magic comes out and fixes the error."
"It didn't change a web file. We should fix that."
"This is an issue that humans hit; Steff and I need to fix that."
"It added the input at the bottom. That's not ideal."
"The agent decided to idle here. ... The way I implemented this is everything the agent responds with is a tool call and it has an idle tool and that's what it invokes when it is done."
As usual, AI is more reasonable than the humans utilizing it (see: Claude's comment on the blog post vs. human comments here on HN). Lol
the lengths people will do to not read the manual.
Very good article with actionable ideas and suggestions. Thanks for writing and sharing!
Another problem that Elixir community must address is to make it super-easy ("one-click") to deploy to hosting of choice (own VPS or cloud) with most things working auto-magically (configured): app, DB, admin-panel, observability (app, server, db), backups/restore, domain, emails (admin, transactional), even maybe CDN/caching and perhaps some integrations (payments, uptime, alerts, etc.)
Make it a no-brainer as much as possible, otherwise it's a choice to buy (and fight with) a ready SaaS-in-a-box solutions, or go with FREE: Astro+CF_Workers+Neon+any_JS_payment_and_email_packages vibe-coding today!
... PS: Minor edits, love Elixir!
Why did you "scroll past" the Go solutions? Types, man, types. Elixir has no types. Ergo, I can't use it.
beep boop
My conclusion from this is: ChatGPT is the new Google, so LLM hints is the new SEO.
If you're worried about people who literally have no opinion or preference about the tech stack they use taking your job... actually, I don't have anything witty to say beyond those people are not going to take your job.
Those people will go back to selling real estate or whatever it was they were doing before someone convinced them to take a nine week bootcamp.
> If LLMs turn out to be a fad and you’re reading this after they jump the shark, please accept this article as a historical artifact from a time when we entertained the idea that fancy autocomplete might eat the world.
> Aside, for those who don’t know what Elixir is: it’s the best general purpose language in the world and if you haven’t heard of it wake up and smell the bacon.
I find a certain humor in this, as elixir is more likely to be a fad than LLM's. I like and use elixir, but their lightweight processes are too restrictive for a lot of use cases. It's great for scaling web apps, however, and I think it's worth recommending over nodejs or other javascript based backends for a lot of people.
It's a windfall. Having written the same project in Phoenix and FastAPI/Expo, I assumed LLMs would be better at writing Python and React. But the amount of boilerplate and opportunities for harmful side effects in the code means I quickly generate large amounts of code that I then need to go back and manually grok to align my understanding. With Elixir this loop is much smaller. I generate a small amount of code, check for validity (much easier to verify in a functional language), and repeat this loop.
Until we get superhuman autonomous coding agents the human in the loop grokking the generated code is still the limiting factor. LLMs are marginally better at generating mainstream languages than Elixir, but the generated Elixir code is much easier to understand and modify, and because of the runtime, will practically never crash your system.