This is very cool. I think the primary innovation here is twofold:
1. Remote agent - it's a containerized environment where the agent can run loose and do whatever - it doesn't need approval for user tasks because it's in an isolated environment (though it could still accidentally do destructive actions like edit git history). I think this alone is a separate service that needs to be productionized. When I run claude code in my terminal, automatically spin up the agent in an isolated environment (locally or remotely) and have it go wild. Easy to run things in parallel
2. Deep integration with fly. Everyone will be trying to embed AI deep into their product. Instead of having to talk to chatgpt and copy paste output, I should be able to directly interact with whatever product I'm using and interact with my data in the product using tools. In this case, it's deploying my web app
look into Kasm workspaces.. great way to spin up remote docker-based linux desktops, and works great as an AI dev environment that you can use wherever you happen to be. There is homedir persistence, and package persistence can be achieved via some extra configuration that allows for Brew homedir-based package persistence.
Phoenix creator here. I'm happy to answer any questions about this! Also worth noting that phoenix.new is a global Elixir cluster that spans the planet. If you sign up in Australia, you get an IDE and agent placed in Sydney.
Just a clarifying question since I'm confused by the branding use of "Phoenix.new" (since I associate "Phoenix" as a web framework for Elixir apps but this seems to be a lot more than that).
- Is "Phoenix.new" an IDE?
- Is "Phoenix.new" ... AI to help you create an app using the Phoenix web framework for Elixir?
- Does "Phoenix.new" require the app to be hosted/deployed on Fly.io? If that's the case, maybe a naming like "phoenix.flyio.new" would be better and extensible for any type of service Fly.io helps in deployment - Phoenix/Elixir being one)
- Is it all 3 above?
And how does this compare to Tidewave.ai (created as presumably you know, by Elixir creator)
Apologies if I'm possibility conflating topics here.
Yes all 3. It has been weird trying to position/brand this as we started out just going for full-stack Elixir/Phoenix and it became very clear this is already much bigger than a single stack. That said, we wanted to nail a single stack super well to start and the agent is tailored for vibe'd apps atm. I want to introduce a pair mode next for more leveled assistance without having to nag it.
You could absolutely treat phoenix.new as your full dev IDE environment, but I think about it less an IDE, and more a remote runtime where agents get work done that you pop into as needed. Or another way to think about it, the agent doesn't care or need the vscode IDE or xterm. They are purely conveniences for us meaty humans.
For me, something like this is the future of programming. Agents fiddling away and we pop in to see what's going on or work on things they aren't well suited for.
Tidewave is focused on improving your local dev experience while we sit on the infra/remote agent/codex/devin/jules side of the fence. Tidewave also has a MCP server which Phoenix.new could integrate with that runs inside your app itself.
The Phoenix.new environment includes a headless Chrome browser that our agent knows how to drive. Prompt it to add a front-end feature to your application, and it won’t just sketch the code out and make sure it compiles and lints. It’ll pull the app up itself and poke at the UI, simultaneously looking at the page content, JavaScript state, and server-side logs.
Is it possible to get that headless Chrome browser + agent working locally? With something like Cursor?
Hi just to confirm as I cannot find anything related to security or your use of using submitted code for training purposes. Where is your security policies with regards to that.
We don't do any model training, and only use existing open source or hosted models. Code gets sent to those providers in context windows. They all promise not to train on it, so far.
1. What's your approach to accessibility? Do you test accessibility of the phoenix.new UI? Considering that many people effectively use Phoenix to write front-ends, have you conducted any evals on how accessible those frontends come out?
2. How do you handle 3rd party libraries? Can the agent access library docs somehow? Considering that Elixir is less popular than more mainstream languages, and hence has less training data available, this seems like an important problem to solve.
It seems like they're giving you lower level building building blocks here. It's up to the developer to address these things. Instruct the agent to build/test for accessibility, feed it docs via MCP or by other means.
Any takeaways on using Fly APIs for provisioning isolated environments? I'm looking into doing something similar to Phoenix.new but for a low-code server-less workflow system.
1 week of work to go from local-only to fly provisioned IDE machines with all the proxying. fly-replay is the unsung hero in this case, that's how we can route the *.phx.run urls to your running dev servers, how we proxy `git push` to phoenix.new to your IDE's git server, and how we frame your app preview within the IDE in a way that works with Safari (cross origin websocket iframes are a no go). We're also doing a bunch of other neat tricks involving object storage, which we'll write about at some point. Feel free to reach out in slack/email if you want to chat more.
Not using FLAME in this case. The agent runs entirely separately from your apps/IDE/compute. It communicates with and drives your runtime over phoenix channels
Do you have a package for calling LLM services we can use? This service is neat, but I don't need another LLM IDE built in Elixir but I COULD really use a way to call LLMs from Elixir.
Everything starts as a stock phx.new app which use sqlite by default. Nothing is specific to fly. You should be able to copy the git clone url, paste, cd && mix deps.get && mix phx.server locally and the app will just work.
Oh geez so sorry for the dumb question! I read a lot about the benefits of containerization in general for agents, but thought it might be enlightening/instructive to know what this specific project adds to that (other than the special Elixir-tuned prompting).
But either way I hear you, thanks so much for taking the time to set me straight. It seems like either way you have done some visionary things here and you should be content with your good work! This stuff does not work for me for just circumstantial reasons (too poor), but still always very curious about the stuff coming out!
Again, so sorry. Congrats on the release and hope your day is good.
I know it's early days, but here's a must-have wish list for me:
- ability to run locally somehow. I have my own IDE, tools etc. Browser IDEs are definitely not something I use willingly.
- ability to get all code, and deploy it myself, anywhere
---
Edit: forgot to add. I like that every video in Elixir/Phoenix space is the spiritual successor to "15-minute rails blog" from 20 year ago. No marketing bullshit, just people actually using the stuff they build.
You can push and pull code to and from local desktop already: hamburger menu => copy git clone/copy git push.
You could also have it use GitHub and do PRs for a codex/devin style workflows. Running phoenix.new itself locally isn't something we're planning, but opening the runtime for SSH access is high on our list. Then you could do remote ssh access with local vscode or whatever.
This is very neat, and right up my alley as both someone really into Elixir and who thinks agentic AI is the future.
I have a question about how you manage context, and what model you use. Gemini seems the best at working with give context windows right now, but even that has its limitations. Thinking about working with Claude Code, a fair bit of my strategizing is in breaking down work and managing project state to keep context size manageable.
I'm watching the linked video and it's amazing seeing it in action, but I'm imagining continuing to work on a project and wondering if it will start losing its way so to speak. Can you have it summarize stuff, and can you start a session clean with those summaries, and have it "forget" files it won't need to use for this next feature, etc?
Ah man I'm really happy to see this and excited to try it out.
As an Elixir enthusiast I've been worried that Elixir would fall behind because the LLMs don't write it as well as they write bigger languages like Python/JS. So I'm really glad to see such active effort to rectify this problem.
Selling point from a developer and career perspective for sure. Its also fun to program in and at least for me made me think about solutions differently.
Its a negative point for engineering leaders that are the decision makers on tech stacks as it relates to staffing needs. LLMs not writing it well, developers that know it typically needing higher compensation, a DIY approach to libraries when there aren't any or they were abandoned and haven't kept pace with deprecations/changes, etc.
In the problem space of needing a web framework to build a SaaS, to an engineering leader there are a lot of other better choices on tech stack that work organizationally better (i.e. not comparing tech itself or benchmarks, comparing staffing, ecosystem, etc.) to solve web SaaS business problems.
I don't know where I stand personally since I'm not at the decision maker level, just thought I'd point out the non-programmer thought process I've heard.
This last few weeks I've been going hard on LLMs to put together a new prototype project. I've exclusively been using Claude Sonnet 3.7 within Zed (via github copilot) and it' fantastic.
From time to time it tries to do something a little old-school, but nothing significant really. It's very capable at spitting out entire new features, even in liveview.
Over all the experience has very productive, and at least on-par with my recent work on similar sized python and nextjs applications.
I think because I'm using mostly common and well understood packages it has a big leg up. I also made sure to initialise the phoenix project myself to start with so it didn't try to go off on some weird direction.
Assuming you are on the $20 Zed plan? Has the 500 prompts/mo been sufficient for you? I'm debating between the Zed and Claude $20 plans-- no doubt I'd get better value from Zed's?
I'm on the free plan and have been using it via GitHub copilot instead, as the current project is a work one and they pay for that.
Before this I did a small project and I hit the 50 free tier limit through Zed by the time I was about 90% done. It was a small file drop app where internal users could create upload links, share them with people who could use them to upload a file. The internal user could then download that file. So it was very basic, but it churned out a reasonable UI and all the S3 compatible integration, etc.
I had to intervene a bit and obviously was reviewing everything and tweaking where needed. But I was surprised at how far I got on the 50 free prompts.
It's hard to know what you really get for that prompt limit though as I probably had a much higher number of actual prompts than they were registering. It's obviously using some token calculation under the hood and it's not clear what that is. All in all I probably had about 60-70 actual prompts I ran through it.
My gut says 500/mo would feel limited if I was going full "vibe" and having the LLM do basically everything for me every day. That said, this is the first LLM product I'm considering personally paying for. The integration with Zed is what wins for me over Claude, where you'd have to pay for API credits or use Claude Code. The way they highlight code changes and stuff really is nice.
Yeah – as someone who works in Common Lisp, I wish there was way to do complementary training for LLMs with existing corpora of codebases. Being able to read access documentation doesn't do much, unfortunately, to help with more general issues with correctness of output.
In my experience, it's the functional part, not immutability, where they fall short. Any LLM can write immutable C# because it's easy and there's incredible amounts of training data.
good news, "immutable" is pretty much the only way that elixir is "functional" except for lambdas being first class datatypes (which is almost every language now)
Worried it might fall behind… further? I love LiveView, Phoenix, Elixir, OTP. But the ecosystem is a wasteland of abandoned packages.
If Phoenix.new helps solve that problem, I’m all for the effort. But otherwise, the sole focus of the community leaders of Elixir should be squarely and exactly focused on creating the incentives and dynamics to grow the base.
Compare, for example, Mastra in TypeScript or PydanticAI in Python. Elixir? Nothing.
Not here to bash. It’s more just a disappointment because otherwise I think nothing comes close.
All languages are a wasteland of abandoned packages, i.e. there is a very long tail of stuff no one has maintained for years. It’s all relative to the mindshare. For its size, Elixir is doing quite well.
It's not the long tail. It's that the HEAD of packages in Elixir are also often poorly maintained or not maintained. The fundamental question for any developer: can I be productive quickly? Despite all that Elixir has going for it, the answer is often "no."
Want a first-party client library for the service you're using? Typically the answer is "too bad, Elixir developer." And writing your own Finch or Req wrapper for their REST endpoint simply isn't a valid answer.
>For its size, Elixir is doing quite well.
I'm actually arguing the opposite. Elixir is not doing well because of its size. So how can that be influenced and changed?
Some languages—Clojure is a good example—have packages from 10 years ago, entirely unmaintained, that still work great because no maintenance is needed.
In my experience, Elixir is very much on that end of the spectrum as well. I'm wondering if GGP just considers packages that don't have updates for 6 months as "unmaintained" or "dead" because they come from Javascript world where everything is, well... you know.
This is such a weird thing to say and I see it all of the time. It sucks people have been tricked into thinking a library must be updated every 2 weeks in order to still be relevant.
You think just because an author bumps the version number of a library it's somehow better than a library that is considered complete?
It boggles my mind that people actually think this way.
Same, I watched a video from Theo where he says Next.js and Python will be the best languages because LLMs know them well, but if the model can infer, it shouldn’t be a problem.
Folks on YouTube have used Claude Code and the new Tidewave.ai MCP (for Elixir and Rails) to vibe code a live polling app in Cursor without writing a line of code. The 2hr session is on YT.
since models can't reason, as you just pointed out, and need examples to do anything, and the LLM companies are abusing everyone's websites with crawlers, why aren't we generating plausible looking but non working code for the crawlers to gobble, in order to poison them?
I mean seriously, fuck everything about how the data is gathered for these things, and everything that your comment implies about them.
The models cannot infer.
The upside of my salty attitude is that hordes of vibe coders are actively doing what I just suggested -- unknowingly.
That seems like a feedback loop that’s unlikely to exist currently. I guess if intentionally plausible but bad data became a really serious problem, the loop could be created… maybe? Although it would be necessary to attribute a bit of code output back to the training data that lead to it.
I'm a little surprised by the sentiment here that LLMs don't do well with Elixir. I've had a pretty good experience using AI tools on Phoenix/Elixir side projects.
I've only used LLMs with Elixir, so I don't have any other experience for comparison, but I've found that although Claude frequently employs the wrong approaches in Elixir, I usually know when he'll have trouble and just ask him to read pertinent documentation first. So long as he's read the manual he seems to do just fine.
LLMs are definitely a lot better at Elixir than they used to be - the gap has closed somewhat. I still perceive a gap though, especially when trying to do more complicated things in Phoenix and LiveView (as opposed to just raw Elixir.)
Which LLMs do you use that you find are best with Elixir/Phoenix?
"Sign in with fly.io" takes me to a page asking me to pay $20 but the plan details are vague - what exactly is included in "$20/mo of Built-In AI Assistance
Builds, refactors, and debugs right in your IDE"?
This is a situation where we've been pushing on Chris to get this out into the world quickly, and there's a lot of packaging stuff like this that isn't fully put together yet. Thanks for calling it out! We'll get to it over the next week.
Any chance of open sourcing the model instructions for this? Do you feed it all the Phoenix/LiveView/Elixir docs, or have you written more specialised instructions?
I find Claude to have quite a bit of problems trying to navigate changesets + forms + streams in my codebase, just wondered if you had any tips of making it understand better :)
This looks really cool, but I gotta say I'm a bit uneasy with the apparent(?) closed-source + hosted + branding. "mix phx.new" is the way to generate a new Phoenix project, but "Phoenix.new" is closed source Fly.io product for building Phoenix projects?
Feels like we're getting into a weird situation if LLM providers are publishing open source agentic coding tools and OSS web app frameworks are publishing closed source/non-BYOK agentic coding tool. I realize this may not be an official "Phoenix" project but it seems analogous to DHH releasing a closed-source/hosted "Rails.new" service.
This is incredible. It does seem quite expensive compared to Zed or Claude Code now it's on Pro. But neat enough I've burned through the $20 subscription credit despite being a bit of an AI sceptic. This seems to have a much better handle on UI design (unless I'm missing something with the other agents), but as a solo dev I'm becoming quite convinced. It's also got me to try out fly again.
I couldn't get Tidewave working but I must try again to see if Tidewave with Claude Code would offer this level of awesome.
ps. @fly - please let me buy more credit, I just get an error!
The mental models of Elixir/OTP and AI Agents are very compatible. I’ve felt for a long time that it would be one of the best platforms for building AI agents.
Thanks! Everything is overly complicated in this space. It's probably far easier than you think. The open secret is it's just a loop that POST [provider]/chat/completions.
Elixir is particularly well suited here. In Elixir this is a genserver doing http posts and reacting to the token stream. The LiveView chat gets messages from the genserver agent regardless of where it is on the planet, and the agent also communicates with the phoenix channel websocket talking to the IDE machines with regular messages, again anywhere they are on the planet.
I'm building an agent right now (or rather, extending an agent I build a few weeks ago in a couple hours) and I would love to hear more about which scenarios get assigned to which models.
(I almost just asked you on company Slack but figured the answer would be more broadly interesting.)
This is really cool! And, that you did it in a few weeks is insane.
How did you get VS Code embedded in your app? I'm aware of projects like Monaco, and that vscode.dev exists - so it's clearly possible - but I didn't realize it was something others could build upon?
Integrating AI assistance directly into an Elixir IDE could boost productivity, especially for newcomers. Excited to see how remote SSH and local workflows develop!
This is great. I had to back out of a phoenix project and rewrite it in Django because I couldn't get good AI assistance. I'm pretty inexperienced with Elixir and Phoenix but understand the benefits enough to want to make projects in it. So this is really cool.
I had this experience too. Though most of my issues were with my model not necessarily with Elixir itself so much as understanding the Phoenix model, state, and CLI. Maybe even differences in versions? Wasn't always clear.
Not just baffling, but concerning. LLM's are great for learning new languages, but terrible for outputting code you don't understand yet hope to maintain.
Because of the amount of Python and JS in the wild is much more than the amount of Elixir code, so the LLMs have much more data to base their answers on.
I've wasted a lot of time and energy on stuff that doesn't matter, so I can hardly judge anyone else on what they focus on, but man does it feel bad to have community leaders actively focus on building out tooling that is anti-worker. I think the only way I'd feel more conflicted is if Fly.io started building weapons systems for the military. I guess that wouldn't be shocking considering some of their lead's beliefs.
It's safe to say that if either Chris or I believed this to be anti worker, we wouldn't be working on it. He's spent the last 10+ years working on Phoenix specifically to improve the lives of the people doing the work.
My experience with software development is maybe different than yours. There's a massive amount of not-yet-built software that can improve peoples' lives, even in teeny tiny ways. Like 99.999% of what should exist, doesn't.
Building things faster with LLMs makes me more capable. It (so far) has not taken work away from the people I work with. It has made them more capable. We can all build better tools, and faster than we did 12 months ago.
Automation is disruptive to peoples' lives. I get that. It decreases the value of some hard earned skills. Developer automation, in my life at least, has also increased the value of other peoples' skills. I don't believe it's anti worker to build more tools for builders.
> There's a massive amount of not-yet-built software that can improve peoples' lives, even in teeny tiny ways. Like 99.999% of what should exist, doesn't.
We agree on this completely, however you and I know there are plenty of people without jobs in the world who could be employed to do this work. You are spending your finite amount of time on earth working with services that are trying to squeeze the job market (they've said this openly) rather than spending it increasing the welfare of workers by giving them work.
> Automation is disruptive to peoples' lives.
You know the difference between automation and the goals of these companies. You know that they don't want to make looms that increase the productivity of workers, they want to replace the worker so they never have to pay wages again.
Most tech isn't "Anti worker". What determines pro/anti worker are laws and government policies that reciprocate with the cultural norms we adopt. At the moment, money in U.S. politics is the most anti-worker phenomena I can think of. The ultra wealthy have a monopoly on the incentives that create policy and how our lives are ordered. The only power working people seem to have is the ability to impose consequences via rogue guerilla acts of protest and violence (Luigi Mangion) . Hopefully, AI is a Frankenstein monster the public learns to wield to facilitate more of these "consequences" and upend the monopoly the super wealthy have on policy incentives and change the way politics is funded for good. It's a new world and a Hawaiian or New Zealand doomsday bunker isn't going make a difference.
Do you believe making things easier and more accessible is bad for workers? I don't think it inherently is or isn't, it just depends on who benefits from the increased efficiency. I think that's more of a problem with your economic system, or wealth distribution.
Overall I think we would all be happier if efficient machines take away the drudgery of our daily work and allow us to focus on things that really matter to us. . . as long as our basic needs are met.
You can think of it as just automating the boring tedious stuff so us humans can focus on the harder problems like strategy, direction, design, GTM, etc.
The days are numbered where humans are sitting typing out code themselves.
It's akin to the numbered days of type writer secretaries of the 20th century.
The argument you're responding to is effective enough, based solely on the fact that it has led me to second-guess whether I chose the right line of work, that it would be worth expounding on what you think is wrong with it.
I'm surprised they are investing into this. I checked Phoenix recently because I was interested in LiveView and there isn't even an official AWS SDK for Elixir.
Honestly doubt the AI stuff is going to move the needle much if you can't even have a dependable S3 client.
Meanwhile I am a happy user of :ex_aws or :req_s3 which has done everything I need it to do. Object ops, iam policies, etc. A dependable S3 client has been there for years. The elixir core team doesn't need to maintain it.
ReqS3 is one of my favorite things to use: https://hexdocs.pm/req_s3/readme.html
Maybe you can guarantee Phoenix will be maintained 5-10 years from now but that's really not the case for some random library on Github.
If you look around you'll see this kind of stuff is really one of the biggest blockers for Elxir and Phoenix. Especially for something as fundamental as cloud storage.
Considering the horror the official AWS CLI is this seems like a strange example. I’ve used both the non official libraries and they work fine. The one that is auto generated doesn’t feel very Elixir, but that’s to be expected.
What are you talking about, there has been a AWS client forever and I've never had a problem. It's not something you really need an official sdk for they are anyway often just reference because you might want different performance characteristics.
I've usually not seen more than 3 or so official SDK for most services and there are a lot more programming languages than that. For example Microsoft's Graph API doesn't have an official Ruby client, they have one that sort of works.
I still don't understand this. If you are big enough then you get Amazon to make an official sdk, if you aren't then what exactly are you looking for?
The official aws cli used to talk to the soap interface and used regex instead of actually doing correct error handling and that was used by so many tools. Even though it used to break horrible.
It's quite a niche you are talking about, not big enough to debug open source code but still big enough to require SLA for SDK and not being able to talk Amazon into creating it. It's generated code, it's not rocket science.
What I have experienced is that software licence, where you are sending data to, where you are hosting it and having access to audit the code has usually been a bigger concern.
But then again big organisations often have really specific concerns. So I'm not doubting your statement it's just that I have never heard it before.
1. Remote agent - it's a containerized environment where the agent can run loose and do whatever - it doesn't need approval for user tasks because it's in an isolated environment (though it could still accidentally do destructive actions like edit git history). I think this alone is a separate service that needs to be productionized. When I run claude code in my terminal, automatically spin up the agent in an isolated environment (locally or remotely) and have it go wild. Easy to run things in parallel
2. Deep integration with fly. Everyone will be trying to embed AI deep into their product. Instead of having to talk to chatgpt and copy paste output, I should be able to directly interact with whatever product I'm using and interact with my data in the product using tools. In this case, it's deploying my web app
https://hub.docker.com/r/linuxserver/kasm
https://www.reddit.com/r/kasmweb/comments/1l7k2o8/workaround...
Just a clarifying question since I'm confused by the branding use of "Phoenix.new" (since I associate "Phoenix" as a web framework for Elixir apps but this seems to be a lot more than that).
- Is "Phoenix.new" an IDE?
- Is "Phoenix.new" ... AI to help you create an app using the Phoenix web framework for Elixir?
- Does "Phoenix.new" require the app to be hosted/deployed on Fly.io? If that's the case, maybe a naming like "phoenix.flyio.new" would be better and extensible for any type of service Fly.io helps in deployment - Phoenix/Elixir being one)
- Is it all 3 above?
And how does this compare to Tidewave.ai (created as presumably you know, by Elixir creator)
Apologies if I'm possibility conflating topics here.
You could absolutely treat phoenix.new as your full dev IDE environment, but I think about it less an IDE, and more a remote runtime where agents get work done that you pop into as needed. Or another way to think about it, the agent doesn't care or need the vscode IDE or xterm. They are purely conveniences for us meaty humans.
For me, something like this is the future of programming. Agents fiddling away and we pop in to see what's going on or work on things they aren't well suited for.
Tidewave is focused on improving your local dev experience while we sit on the infra/remote agent/codex/devin/jules side of the fence. Tidewave also has a MCP server which Phoenix.new could integrate with that runs inside your app itself.
Is it possible to get that headless Chrome browser + agent working locally? With something like Cursor?
2. How do you handle 3rd party libraries? Can the agent access library docs somehow? Considering that Elixir is less popular than more mainstream languages, and hence has less training data available, this seems like an important problem to solve.
How do you protect the host Elixir app from the agent shell, runtime, etc
I was curious what the pricing for this is? Is it normal fly pricing for an instance, and is there any AI cost or environment cost?
And can it do multiple projects on different domains?
But either way I hear you, thanks so much for taking the time to set me straight. It seems like either way you have done some visionary things here and you should be content with your good work! This stuff does not work for me for just circumstantial reasons (too poor), but still always very curious about the stuff coming out!
Again, so sorry. Congrats on the release and hope your day is good.
- ability to run locally somehow. I have my own IDE, tools etc. Browser IDEs are definitely not something I use willingly.
- ability to get all code, and deploy it myself, anywhere
---
Edit: forgot to add. I like that every video in Elixir/Phoenix space is the spiritual successor to "15-minute rails blog" from 20 year ago. No marketing bullshit, just people actually using the stuff they build.
You could also have it use GitHub and do PRs for a codex/devin style workflows. Running phoenix.new itself locally isn't something we're planning, but opening the runtime for SSH access is high on our list. Then you could do remote ssh access with local vscode or whatever.
So no plans to open the source code?
I have a question about how you manage context, and what model you use. Gemini seems the best at working with give context windows right now, but even that has its limitations. Thinking about working with Claude Code, a fair bit of my strategizing is in breaking down work and managing project state to keep context size manageable.
I'm watching the linked video and it's amazing seeing it in action, but I'm imagining continuing to work on a project and wondering if it will start losing its way so to speak. Can you have it summarize stuff, and can you start a session clean with those summaries, and have it "forget" files it won't need to use for this next feature, etc?
As an Elixir enthusiast I've been worried that Elixir would fall behind because the LLMs don't write it as well as they write bigger languages like Python/JS. So I'm really glad to see such active effort to rectify this problem.
We're in safe hands.
Its a negative point for engineering leaders that are the decision makers on tech stacks as it relates to staffing needs. LLMs not writing it well, developers that know it typically needing higher compensation, a DIY approach to libraries when there aren't any or they were abandoned and haven't kept pace with deprecations/changes, etc.
In the problem space of needing a web framework to build a SaaS, to an engineering leader there are a lot of other better choices on tech stack that work organizationally better (i.e. not comparing tech itself or benchmarks, comparing staffing, ecosystem, etc.) to solve web SaaS business problems.
I don't know where I stand personally since I'm not at the decision maker level, just thought I'd point out the non-programmer thought process I've heard.
From time to time it tries to do something a little old-school, but nothing significant really. It's very capable at spitting out entire new features, even in liveview.
Over all the experience has very productive, and at least on-par with my recent work on similar sized python and nextjs applications.
I think because I'm using mostly common and well understood packages it has a big leg up. I also made sure to initialise the phoenix project myself to start with so it didn't try to go off on some weird direction.
Before this I did a small project and I hit the 50 free tier limit through Zed by the time I was about 90% done. It was a small file drop app where internal users could create upload links, share them with people who could use them to upload a file. The internal user could then download that file. So it was very basic, but it churned out a reasonable UI and all the S3 compatible integration, etc.
I had to intervene a bit and obviously was reviewing everything and tweaking where needed. But I was surprised at how far I got on the 50 free prompts.
It's hard to know what you really get for that prompt limit though as I probably had a much higher number of actual prompts than they were registering. It's obviously using some token calculation under the hood and it's not clear what that is. All in all I probably had about 60-70 actual prompts I ran through it.
My gut says 500/mo would feel limited if I was going full "vibe" and having the LLM do basically everything for me every day. That said, this is the first LLM product I'm considering personally paying for. The integration with Zed is what wins for me over Claude, where you'd have to pay for API credits or use Claude Code. The way they highlight code changes and stuff really is nice.
Bit of a brain dump, sorry about that!
If you want to take your website and business down, use ChatGPT-4o's code
If Phoenix.new helps solve that problem, I’m all for the effort. But otherwise, the sole focus of the community leaders of Elixir should be squarely and exactly focused on creating the incentives and dynamics to grow the base.
Compare, for example, Mastra in TypeScript or PydanticAI in Python. Elixir? Nothing.
Not here to bash. It’s more just a disappointment because otherwise I think nothing comes close.
Want a first-party client library for the service you're using? Typically the answer is "too bad, Elixir developer." And writing your own Finch or Req wrapper for their REST endpoint simply isn't a valid answer.
>For its size, Elixir is doing quite well.
I'm actually arguing the opposite. Elixir is not doing well because of its size. So how can that be influenced and changed?
Some languages—Clojure is a good example—have packages from 10 years ago, entirely unmaintained, that still work great because no maintenance is needed.
You think just because an author bumps the version number of a library it's somehow better than a library that is considered complete?
It boggles my mind that people actually think this way.
https://www.youtube.com/live/V2b6QCPgFTk
I mean seriously, fuck everything about how the data is gathered for these things, and everything that your comment implies about them.
The models cannot infer.
The upside of my salty attitude is that hordes of vibe coders are actively doing what I just suggested -- unknowingly.
I am not sure, but the cat is out of the box. I don't think we can do anything at this point.
Which LLMs do you use that you find are best with Elixir/Phoenix?
I guess I should also note that I haven't really used LiveView much.
I've been daydreaming of an agentic framework that maximally exploits BEAM. This isn't that, but maybe jido[0] is what I'm looking for.
0. https://github.com/agentjido/jido
I find Claude to have quite a bit of problems trying to navigate changesets + forms + streams in my codebase, just wondered if you had any tips of making it understand better :)
Feels like we're getting into a weird situation if LLM providers are publishing open source agentic coding tools and OSS web app frameworks are publishing closed source/non-BYOK agentic coding tool. I realize this may not be an official "Phoenix" project but it seems analogous to DHH releasing a closed-source/hosted "Rails.new" service.
I couldn't get Tidewave working but I must try again to see if Tidewave with Claude Code would offer this level of awesome.
ps. @fly - please let me buy more credit, I just get an error!
Does anyone know any great resources to learn how to design agents? Tool agnostic resources would be awesome.
Elixir is particularly well suited here. In Elixir this is a genserver doing http posts and reacting to the token stream. The LiveView chat gets messages from the genserver agent regardless of where it is on the planet, and the agent also communicates with the phoenix channel websocket talking to the IDE machines with regular messages, again anywhere they are on the planet.
I talk about this quite a bit in my ElixirConfEU talk and distill things down: https://youtu.be/ojL_VHc4gLk?si=MzQmz-vofWxWDrmo&t=1040
It's like helping LLMs use a computer; like building an interface for it.
Ok, this is enough to get me started.
(I almost just asked you on company Slack but figured the answer would be more broadly interesting.)
How did you get VS Code embedded in your app? I'm aware of projects like Monaco, and that vscode.dev exists - so it's clearly possible - but I didn't realize it was something others could build upon?
Again, kudos!
What usage limits do we get with the $20 monthly price?
Thank you!
My experience with software development is maybe different than yours. There's a massive amount of not-yet-built software that can improve peoples' lives, even in teeny tiny ways. Like 99.999% of what should exist, doesn't.
Building things faster with LLMs makes me more capable. It (so far) has not taken work away from the people I work with. It has made them more capable. We can all build better tools, and faster than we did 12 months ago.
Automation is disruptive to peoples' lives. I get that. It decreases the value of some hard earned skills. Developer automation, in my life at least, has also increased the value of other peoples' skills. I don't believe it's anti worker to build more tools for builders.
It's really a matter of positive sum/growth mindset vs scarcity/status quo mindset.
We agree on this completely, however you and I know there are plenty of people without jobs in the world who could be employed to do this work. You are spending your finite amount of time on earth working with services that are trying to squeeze the job market (they've said this openly) rather than spending it increasing the welfare of workers by giving them work.
> Automation is disruptive to peoples' lives.
You know the difference between automation and the goals of these companies. You know that they don't want to make looms that increase the productivity of workers, they want to replace the worker so they never have to pay wages again.
Saying the quiet part loud here.
Overall I think we would all be happier if efficient machines take away the drudgery of our daily work and allow us to focus on things that really matter to us. . . as long as our basic needs are met.
Nope, I've been doing it for 16 years.
The days are numbered where humans are sitting typing out code themselves.
It's akin to the numbered days of type writer secretaries of the 20th century.
I'm sure your poor understanding of the history of improved tooling, like "type writer secretaries", will be a soft comfort in the future.
Honestly doubt the AI stuff is going to move the needle much if you can't even have a dependable S3 client.
If you look around you'll see this kind of stuff is really one of the biggest blockers for Elxir and Phoenix. Especially for something as fundamental as cloud storage.
Maybe fine today but what about 5 years from now?
Can you say, with any degree of confidence, if these these libraries are going to be properly maintained in the future? No, you cannot.
https://hex.pm/packages/ex_aws https://hex.pm/packages/ex_aws_s3
I've usually not seen more than 3 or so official SDK for most services and there are a lot more programming languages than that. For example Microsoft's Graph API doesn't have an official Ruby client, they have one that sort of works.
The official aws cli used to talk to the soap interface and used regex instead of actually doing correct error handling and that was used by so many tools. Even though it used to break horrible.
It's quite a niche you are talking about, not big enough to debug open source code but still big enough to require SLA for SDK and not being able to talk Amazon into creating it. It's generated code, it's not rocket science.
What I have experienced is that software licence, where you are sending data to, where you are hosting it and having access to audit the code has usually been a bigger concern.
But then again big organisations often have really specific concerns. So I'm not doubting your statement it's just that I have never heard it before.