Simon Willison’s Weblog

Phoenix.new is Fly’s entry into the prompt-driven app development space

23rd June 2025

Here’s a fascinating new entrant into the AI-assisted-programming / coding-agents space by Fly.io, introduced on their blog in Phoenix.new – The Remote AI Runtime for Phoenix: describe an app in a prompt, get a full Phoenix application, backed by SQLite and running on Fly’s hosting platform. The official Phoenix.new YouTube launch video is a good way to get a sense for what this does.

Background on Phoenix and Elixir and Fly

First, some background. Phoenix is an open source web framework for Elixir, the Ruby-like language that compiles to Erlang’s BEAM bytecode and runs on top of the highly concurrent Erlang runtime. The signature feature of the framework is Phoenix LiveView, a toolkit for building realtime interfaces through streaming diffs to server-side HTML over a WebSocket connection.

Phoenix was created by Chris McCord 11 years ago, and Chris joined Fly nearly four years ago. Phoenix.new is his latest project.

Phoenix LiveView is a really great fit for Fly’s geographically distributed application serving infrastructure. Fly co-founder Kurt Mackey wrote about that in April 2021, before they had hired Chris, describing how LiveView benefits from low latency by “moving app processes close to users”—something Fly has been designed to help with from the start.

There’s one major challenge though: Elixir is still a niche programming language, which means the number of people out there who are ready to spin up a new Phoenix app has always been artificially limited.

Fly’s solution? Get LLMs to shave that learning curve down to almost nothing.

Prompt-driven application development with Phoenix.new

Phoenix.new is a prompt-driven application development platform. You describe what you want to build, then watch as an LLM-powered coding agent writes, tests and iterates on code to help achieve that goal. It’s in the same broad category as Lovable, v0.dev and and Val Town’s Townie.

One of the most important problems to solve with coding agents is to give them a robust sandbox where they can run code without breaking things outside of that space. Fly, at their heart, are a sandboxing company—their Fly Machines product makes it trivial to spin up a new sandboxed VM in just a few seconds. I’m building Datasette Cloud on Fly for exactly that reason.

I tried out Phoenix.new with the following starter prompt:

A notebook application. Notes are rich text, using a nice visual markdown editors. The first line of a note becomes the title. Notes have a URL that is a 6 character random text string - thise can be used to link notes to each other by dropping in an @ sign and that text string. A hash and then text becomes a tag, clicking a tag goes to a page with that tag on. Notes are all in SQLite FTS so they can be searched with a search tool.

Watching it work was fascinating. It provides a full IDE-style environment in the browser, running a dedicated container and with a forwarded port to allow you to interact with the running application while it is being built.

It spun up a plan.md, planned out the approach and started working through the code. Most interestingly, it constantly tested the application it was building using a testing tool that looked similar to my own shot-scraper. Here’s an example of the output from that:

I can see the issue! The page is still showing the “Welcome to your Notebook” message instead of the form. Let me wait a moment for the JavaScript to execute and then check if the form appeared.

$ web http://localhost:4000 --js "setTimeout(() => { document.querySelector('button[phx-click=\"start_creating\"]').click(); }, 500); setTimeout(() => { console.log('Form visible?', !!document.querySelector('textarea')); console.log('Creating note state:', document.body.innerHTML.includes('Create New Note')); }, 2000);"

I’m used to coding agents that write and execute their own tests, but this is the most impressive example I’ve seen of a coding agent that actively interacts with and tests the live application while it is iterating on the code.

Most interestingly of all, since LiveView is a realtime framework, I could interact directly with the application at the same time as the machine was writing and testing it, seeing any changes it made instantly in my browser!

How did it do? It got there in the end, but with hindsight my initial prompt was a little too complex: I had to rescue it after it got stuck in an error loop trying to implement SQLite full-text search. Just like a project you build yourself it turns out to work much better if you start with the simplest possible version of the application and then iterate on it to add additional features.

One of my favorite details is how Git integration works. Phoenix.new commits constantly as it works, and a menu option for “Clone X to your local computer” then gives you a command that looks like this:

git clone "https://phoenix.new/git/WENQLj...big-random-string...VHFW/$RANDOM/notebook"

Run that locally to get a full copy of the repo! I ran the following to push it to a new repository in my GitHub account:

git remote add github https://github.com/simonw/phoenix-new-notebook.git
git push -u github main

You can see the code (and the commit history) in my simonw/phoenix-new-notebook repo.

How much did I learn?

My initial experiments with Phoenix.new were very much vibe coding—I interacted with the resulting application but didn’t pay a great deal of attention to the code that was being written, despite it being presented to me in an IDE that made it very easy to review what was going on.

As a result, I didn’t learn much about the low-level syntax details of how Phoenix and Elixir work. I did however get a strong feel for the shape of Elixir and Phoenix at a high level as the code danced past my eye.

It turns out having an LLM write an application in front of you is a great way to start building understanding of what a framework can do.

It’s almost like watching a YouTube livestream of an experienced developer speed running building an application, except that app is exactly what you asked them to build and you can interject and send them in a new direction at any moment.

Expanding beyond Elixir and Phoenix

Chris’s announcement included this note:

At this point you might be wondering – can I just ask it to build a Rails app? Or an Expo React Native app? Or Svelte? Or Go?

Yes, you can.

Our system prompt is tuned for Phoenix today, but all languages you care about are already installed. We’re still figuring out where to take this, but adding new languages and frameworks definitely ranks highly in my plans.

The browser-based IDE includes a terminal, and I checked and python3 and python3 -m pip install datasette work there already.

If Fly do evolve this into a framework-agnostic tool for building web apps they’ll probably need to rebrand it from Phoenix.new to something a bit more generic!

Phoenix.new is currently priced as a $20/month subscription. Val Town recently switched the pricing for their similar Townie assistant from a subscription to to pay per use, presumably because for many users this kind of tool is something they would only use intermittently, although given the capabilities of Phoenix.new it’s possible it could become a monthly driver for people, especially as it expands out to cover more frameworks.

Fly sponsor some of our work on Datasette Cloud (see disclosures), but this article is not sponsored content and Fly did not request or review this post.