Live data from Hacker News

Phoenix.new – Remote AI Runtime for Phoenix

fly.io

191–200 of 283 posts

Re: Phoenix.new – Remote AI Runtime for Phoenix

#191

Earlier quoted context omitted.

>> Remote agent - it's a containerized environment where the agent can run loose and do whatever How is this innovation?

Many people have not experienced the async agent workflow yet and fairly the major providers didn’t have offerings for them until a month or two ago. It’s in fact one of my predictors for if they are going to be enthusiastic about agents or not. And you wouldn’t think containerization would be a big leap but this stuff is so new and moving so fast that combining them with existing tech can surprise people.

It's less innovative and more trendy. A lot of the fly integration can be achieved by simply asking claude code to look up the docs for the fly cli tool.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#192
I am probably doing something wrong but I hate agents for coding. I like the autocomplete and the prompt to generate snippets but when it starts modifying code in many files so fast all at once, tries a bunch of stuff and never know when to stop it pisses me off more than anything else. Because most the time if it had stopped and let me do the 10% last part it would have been actual legit code.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#194

Earlier quoted context omitted.

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…

> 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. Honestly, this is depressing. Pop in from what? Our factory jobs?

I understand that we are slowly taking away our own jobs but I do not find it depressing. I do find it concerning since most people do not talk about this openly. We are not sure how we are restructure so many jobs. If we cannot find jobs, what is the financial future for a large number of people across the world. This needs more thinking, honest acceptance of the situation. It will happen, we should take a positive approach to finding a new future.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#195

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…

I have recently been working with Google Jules and it has a similar approach. It spins up VMs and goes through tasks given.

It does not handle any infrastructure, so no hosting. It allows me to set multiple small tasks, come back and check, confirm and move forward to see a new branch on GitHub. I open a PR, do my checks (locally if I need to) and merge.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#196

Earlier quoted context omitted.

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 traini…

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.

They use the Daisy UI component library in 1.8+ Phoenix versions which should have basic accessibility baked in.

Re: Phoenix.new – Remote AI Runtime for Phoenix

#197

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 tried it out, but it's unclear what the different buttons at the bottom of the chat history does. The rightmost one (cloud with an upwards arrow) seems to do the same as the first?

Re: Phoenix.new – Remote AI Runtime for Phoenix

#198

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 tried it out, but it's unclear what the different buttons at the bottom of the chat history does. The rightmost one (cloud with an upwards arrow) seems to do the same as the first?

I'm also having trouble with getting it to read PDFs from URLs. I got this error:

web https://example.com/file.pdf Error: page.goto: net::ERR_ABORTED at https://example.com/file.pdf Call log: - navigating to "https://example.com/file.odf", waiting until "load" at main (/usr/local/lib/web2md/web2md.js:313:18) { name: 'Error' }

/workspace#

Re: Phoenix.new – Remote AI Runtime for Phoenix

#199

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.

Is there something comparable that works similarly but completely offline with appropriate hardware? Not everywhere has internet or trusts remote execution and data storage.

PS: Why can't I get IEx to have working command-line history and editing? ;-P

Re: Phoenix.new – Remote AI Runtime for Phoenix

#200
This makes me very uneasy. Not in what it is per se, but in what it shows about the direction of Phoenix.

I've been working with Phoenix a lot the last few months, and I like it a lot. But I do get the sense that the project suffers from wanting to perpetually chase the next new thing, even when that comes at the expense of the functional elegance and conceptual cohesiveness that I think is Phoenix' main strength.

LiveView is a great example. It's a very neat bit of tech, but it's shoe-horned surprisingly awkwardly into Phoenix. There's now a live view and non-live view way to do almost everything in Phoenix, and each has their own different foibles and edge cases. A lot of code needs to work with both (e.g. auth needs to happen at both levels, basically), meaning a surprising amount of code needs to have two, nearly identical variants: one with traditional Plug idioms, and then another using LiveView equivalents. Quick little view helpers end up with either convoluted 'what mode am I in?' branching, or (more likely) in view-mode-dependent wrappers around view-mode-independent abstractions. This touches even the simplest helpers (what is the current path?) and becomes more cumbersome from there. (And given the lack of static analysis for views, it can be non-trivial to even find out what is and isn't actually working where.)

Not every website should be a live view (e.g. hiking directions, for example), but that is clearly the direction of travel in Phoenix. Non-live views get the disparaging moniker 'dead views', and the old Phoenix.HTML helpers have been depreciated in favour of -style live components. The generators depend on those, plus Tailwind, Hero Icons and (soon) DaisyUI, all fetched live from various places on the Internet on build. This tight coupling to trendy dependencies will age poorly, and it makes for bumpy on-boarding (opinionated and tightly coupled isn't necessarily a smoother experience, just a more inflexible one).

So with all of that in mind, while I'm not shocked to see Phoenix jump on the vibe coding hype train, I guess I am disappointed.

The revelation that AI is now writing PRs for Phoenix itself is not confidence inspiring. I rely on frameworks like Phoenix because I don't want to have to think about the core abstractions around getting a website to my users; I want to focus on my business logic. But implicit in that choice is the assumption that someone is thinking about those things. If it's AI pushing out Phoenix updates now, my trust level and willingness to rely on this code drops dramatically. I also do not expect Phoenix' fraying conceptual cohesiveness to get any better if that's the way we're headed.

Phoenix is still an amazing piece of tech, but I wish I felt more at ease about its future trajectory.

Post reply on HN